433Mhz transmitters deciphering and teardown

I've been doing yet more digging around with these little 433Mhz transmitters. These are the ones found in a lot of home automation hardware now, as well as wireless alarm system, remote garage door and shutter controllers and a lot more.
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:

That's both sides of the small board inside. Difficult to see, but on the top photo is the battery source (2x3v) and to the right of it is the 433Mhz transmitter 'can' with 433 printed onto it, so I know it's a 433mhz transmission type. Looking on the back was interesting though, it didn't have one of the 'standard' chips used for 433Mhz transmission, and actually had a custom 14-pin chip in it with no markings at all on it. My guess is this is a custom mini microcontroller with custom firmare burnt onto it. There were very few other components, a diode, resistors and an LED. So not much to go on. I started my 433Mhz sniffer application (Using an arduino with a 433Mhz receiver chip connected) and got no signal at all on any mode. This makes me think they are doing custom modulation with the 433Mhz signal and no much chance of decoding it.

The second one I tried was another X11 remote, this time just used for lighting control:

On this one there was the transmitter can in the middle (With the red insulating foam around it) but no mention of 433Mhz. I assumed it would be. I then looked into the chip in the middle, which was a EM78P153AN. Looking this up, I found it to be an 8-bit microcontroller with OTP ROM, so again a chip with custom firmware burnt onto it. Again not many other components on either side of the board, a few resistors, diodes and that was about it. Running my 433Mhz sniffer I didn't get anything I could decode, so again assuming this is using similar coding to the previous X11 remote and can't get into what it was sending.

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:

This one was for a commercial shutter. Any to my surprise when opened up, the 'can' said it all! 13,560Mhz! Now this was supplied by a shutter company for use here in the UK, I'm not 100% sure but I don't believe these are legal to use in the UK due to licensing.
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:

And can take a voltage range from 3v to 12v. And by setting K0-3 to either 1 or 0 it will change the data output (D0-3). In this units case it only appears to have two of these linked to the dip switches but I'd assume you could connect the rest up if you wished. Looking at a close-up of the circuit I can see where the traces are missing:

So the common row of 4 pins along the top of the DIP switches go to a connection pad (see below, this is the reed switch connection). Then only one line is brought down from the chip (pin5 K0) so this is the only one that will be affected by changing the DIP switches. So effectively this version allows two values to be chosen.
However, this is almost unrequired, as the chip itself has a burnt-in at factory value as part of the output code:

So the C0~C19 is burnt into the chip and forms part of the initial code, followed by the user-defined 4 character selection. This should therefore mean that no two chips are identical (assuming we don't hit the same code from the choice of 1 million!) in their transmitted codes, so should be safe from colliding with another unit.
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.

Here is the circuit itself, you can see the BXR433A can to the top middle, the 12v battery sits in the middle.
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!