I've got a few different ones here at home, so I thought I'd go through each one and work out how they work and what different functions they leverage for their operation. The main goal behind this was to determine reliability (Which I'll get onto later).
Here are the 5 different models I have:
X11 alarm remote
X11 light control
Garage door/Shutter remote
Alarm door sensor
Alarm remote control
All five of these have remote control capabilities and operate in a similar way, so the first thing was to take a look at how they all operated.
The first was the X11 alarm remote:
The second one I tried was another X11 remote, this time just used for lighting control:
The above two isn't entirely surprising, X11 protocols for their remotes are 'encrypted' or at least made to not be easy to hack or replicate using standard duplication techniques. Whether they use rolling codes or not I'm unsure, but they certainly have the ability to do this since they have the custom microcontroller on board which could run all sorts of interesting code.
I then turned my attention to the more 'basic' 433Mhz transmitters. Firstly the one for the garage door/shutters:
Looking at the rest of the board, there is a 430G2332 chip which is a mixed signal microcontroller, and beside it the 7110FE which is either a second microcontroller or a voltage regulator chip. Either way this remote wasn't much use since it wasn't 433Mhz so I didn't investigate any further.
This then takes me onto the alarm sensor unit:
On the front of the board (Bottom photo) you can see the multicolour LED top left (Red and Green), then the top right is the can for the 433Mhz crystal. To the left is the reed switch (for the door) a capacitor and then to the bottom (above the battery slot) are 4 dip switches. These vary the code transmitted (well, the first two, the 3rd and 4th don't seem to make a difference).
On the back of the board we can see the main chip (towards the bottom of the board). It's covered in resin gunk but I could still make out the chip which was EV1527 OTP encoder which is on most of the 433Mhz boards. The 8-pin schematic shows:
However, this is almost unrequired, as the chip itself has a burnt-in at factory value as part of the output code:
The reed switch lower solder joint goes to the top row of pins on the DIP switches (and so ultimately to pin 5 K0). The other side of the reed switch goes to capacitor C1 (tiny smd) and to J3Y which is a switching transistor, which will be to handle the switching voltage for the chip.
Pin 6 is pulled to ground constantly (as it the ground pin for the chip).
The positive pin (2) for the chip is only energised when the transmitter needs to be powered up, and so is therefore controlled by the rest of the circuits switching transistors and trigger with a timed value. This therefore allows the circuit to detect when the reed switch is broken it will trigger a timed burst of voltage to the chip and transmit it's signal. This only works because this is a one-way circuit, it only transmits, so has no method of testing battery voltage and letting the alarm know, nor does it know the state of the alarm or any other state. It simply gets woken up by voltage being sent to the chip which immediately starts transmitting it's value and then gets power removed.
This method is good for low power consumption as when not transmitting it'll use very little idle power (Just a transistor switch, remember we want to trigger the signal when the circuit is broken, so it's known as a NC normally closed circuit).
However this also highlights the weakness in this system. Firstly the system only has one go at sending data, if that fails then there are no retries. In practice I've tested this with my 433Mhz receiver and I do only see a single transmitted value from the unit when the reed switch is removed. So the alarm receiver has to get the signal the first time, otherwise it would be missed. This is where an improvement should be made and setup so the signal repeats several times.
Another unknown for now is the multi-colour LED. It has both red and green in the package, and will trigger both colours. When the reed switch is triggered the red LED will come on then flicker red and green (and off) until completely off. This seems to be a capacitor discharge timer/reduction of power, so I think the circuit must charge the capacitor (47uF 16v on the front of the board?) and then use the capacitor discharge to supply power to the transmitter circuit. I'm therefore unsure what the different colours indicate. There is also the push button on the front of the board. This forces the transmission of the code. I'd expected this to simply bridge the reed switch, but upon learning about the circuit (and realising it's NC) then this couldn't be possible. Therefore it seems to force a power 'jolt' to the circuitry and forcibly power up the chip. This keeps repeating the code so it is powered direct from the battery I think. This causes the LED to flicker red and green constantly until I release the button, at which point the LED stays lit up GREEN! It won't go off until I remove the battery, so is almost like a power indicator showing that power is being supplied by the battery (but not supplied to the chip).
UPDATE: I did a bit more testing and worked out the LED colour conditions! They indicate battery state. The battery I was testing with was an older one (These are 23A/MN21 12v batteries) and actually on testing with the meter showed only a 6v output without load. Therefore this shows that I believe the green/orange light indicates low battery/poor output state. I think it was keeping the green LED on to show that voltage was low and needed replacing! (Would be better the other way round, red instead of green!) Putting a full battery in (showing 12v) when moving the reed switch away the LED lit bright RED and transmitted it's code twice before the LED flickered and went off. (No green shown on the LED at all) So this appears to be a basic indicator for battery state, when low it will show yellow/orange/green to tell you to replace!
The transmitted code can be read by my 433Mhz receiver and I can see it's a simple code being sent at 24-bit, an example of a code would be 3528277. This I can see repeated at each trigger, so they aren't rolling codes or anything sophisticated.
I can therefore transmit this code and 'emulate' the sensor if for whatever reason I needed to.
The alarm remote control was the last unit I took a look at.
It contains four buttons for 'SET', 'UNSET', 'HOME-SET' and 'PANIC'. These four seem to send different codes, so I suspect they simply set the different K0-3 pins on the same chip.
At the bottom middle you can see the SCT2260 (Also known as the PT2260) chip which does the RF encoding. This uses a similar technique to the other 433Mhz transmitter chips and the pin-out along with an example 4-button transmitter is on the datasheet:
So that looks like how this unit is being used.
Finally, I wanted to find out a constant bug that was appearing on my setup. On the remote transmitters, these seemed to sometimes fail and not set or unset the units. This is strange as the LED on the transmitter always lit up and it always appeared to send a code. Sniffing the codes I can see a code transmitted at every press of the buttons. HOWEVER the code sometimes changed (and not just once. When it happened the transmitter would send 3 or 4 of this incorrect code, not changing). Initially I dismissed this as just because of poor antenna or receivers or similar, so this is something to investigate further.
That's for the next part of debugging I think!