This page is about reverse engineering protocols used in simple AM RF modules at 433 MHz.
This frequency is very popular for various inexpensive RF wireless things, like:

wireless thermometers
remote controlled appliances
remote camera flash and shutter triggers
door bells

Knowledge of the protocol for these kinds of applications could be used to add RF capabilities to hobby projects.

Hama remote shutter trigger CA-1

Protocol:

A pulse sequence encodes 8 bits (each encoded as a short or long pulse) and an epilogue
The elementary time-unit T seems to be about 120 microseconds
A 0-bit is encoded as 1100 in the air and a 1-bit is encoded as 11000000 in the air, where each bit in the air has duration T
The epilogue following the encoded bits is 1001111
The interval between pulse sequences is 16 T
For a half-press, the first four bits contain 0000 and the last four bits contain the channel code (inverted)
For a full-press, the first four bits and the last four bits both contain the channel code (inverted). In case channel 15 is used, there is an exception: the first four bits are 1111.

When receiving about 250 full-press codes in a row, the receiver unit goes into 'bulb' mode. The example on the right shows the codes for a half-press and a full-press (dip switch 4 was on, rest off)

Haehnel remote shutter trigger HW 433 N80

This device can be used for remote control of the autofocus/shutter of a photo camera. Protocol:

The transmitted pulse sequence consists of 17 bits sent at 1200 bps, with about 19 ms silence between pulse sequences
A 0 is encoded as a pulse with low duty cycle (about 25%) and a 1 as a pulse with high duty cycle (about 75%)
The encoding is as follows: 000000mm.pp00cccc.0, where mm = mode (01=normal/bulb mode, 10=timer mode), pp = press (00=half press, 11=full press), cccc = channel (inverted and reversed).

The example on the right shows the codes 00000001.00001110.0 and 00000001.11001110.0, which encode for a half-press and a full press respectively in normal/bulb mode on with channel code 1000.

Cactus v2 remote flash

Gadgetinfinity sells the Cactus V2, a remote RF flash trigger with 4 'channels', configured by 2 dip switches. This thing sends a code to a remote flash by turning a 433 MHz SAW oscillator on and off in a certain pattern. Out of curiosity I tried to reverse engineer the protocol.

RF recording

At first I simply used a 433 MHz receiver module, connected the output to my sound card and recorded the signal shown at the right

We see 20 pulses of about 2 ms each (on the left you see some noise that these 433 MHz receivers typically output in absence of data). However the pulses on the left don't look the same as the pulses on the right, there seem to be some kind of dips in it. I thought this is because my RF receiver module is not really fast enough, so I decided to measure directly in the Cactus transmitter itself.

Recording at the transmitter

The picture on the left shows the signals I recorded directly inside the Cactus V2 transmitter for the four different channels (1st = OFF-OFF, 2nd = ON-OFF, 3rd = ON-ON, 4th = OFF-ON). What we see is the following:

Each of the 20 pulse sequences has a pattern of 7 pulses of varying width.
The channel set at the transmitters determines the pulse pattern:
- pattern 11001100110011001100110011 when dipswitch is OFF-OFF
- pattern 10110010110010110011 when dipswitch is ON-OFF
- pattern 10101010101011 when dipswitch is ON-ON
- pattern 11001011001011001011 when dipswitch is OFF-ON
Basically, the 1st dip switch determines the length of the three even pulses and the 2nd dip switch determines the length of the three odd pulses, followed by a final pulse that is always long.
Each 'bit' in the sequence takes about 70 us (microseconds).
The pulse sequences are separated by about 0.6 ms of silence.
A funny thing is that apparently not all codes result in an RF signal of the same length. Could this have impact on the speed or reliability at which the remote flash is triggered?

Remote controlled wall socket

There's a lot of relatively inexpensive remote controlled wall socket adapters available, also working on 433 MHz. They are based on the PT2262 encoder (in the transmitter) and PT2272 decoder chips (in the receiver). A well-known implementation of this is the KaKu (klik-aan klik-uit) system.

The one that I have uses the following protocol (I didn't fully reverse engineer this myself):

A specific pulse pattern is sent 4 times with 8 ms silence in between.
The pattern encodes a 12-bit number, HHHHH.UUUU.1.sS, where H = house code, U = unit code and S = on/off (s is the inverse of S).
Each of the 12 bits is encoded as bits in the air as: 0 -> 10001000 and 1 -> 10001110. At the end, a final bit pattern of 1000 is sent. Each bit in the air takes about 320 us.

It seems the receiver has to receive at least two pulses to switch the socket on or off. The image on the right shows an example of this kind of signal (this signal was actually made by a microcontroller and not the actual transmitter unit).

Wireless thermometer

I also have a wireless thermometer, with an outdoor unit that transmits the temperature to an indoor unit. The protocol seems quite simple.

First a kind of pre-amble is sent, presumably to allow the receiver to synchronise on the bit pattern or adjust its gain. The pre-amble consists of alternating 1's and 0's. Each bit period takes about 2.4 ms.
Next the transmitter remains on for 16 periods
Next a 21-bit code is sent in a Manchester coded format, where 01 encodes a 0 and 10 encodes a 1.
The code looks like this: 0.cc.01.aaaa.bbbb.cccc.dddd, where cc = channel, aaaabbbbcccc = temperature coded in BCD in tenth's of degrees C. dddd = some kind of parity code

The example on the right shows a code of 0.01.01.0010.0100.1001.1010, or a temperature of 24.9 degrees on channel 1. I haven't figured out the parity code yet.

Unknown 433 MHz signal

Here's a recording of some unknown signal appearing at the output of my 433 MHz RF receiver module every 30 seconds or so, probably a weather station. Analysis:

The encoding seems to be Manchester coding. This kind of code has exactly the same number of 0's and 1's in the air, so it's nicely balanced.
Each bit in the message is encoded as either a 01 or 10 in the air signal.
There seem to be 88 bits encoded like this in the message.

Gratis teller

This page was last updated May 23, 2009