HomeEasy/Byron 433MHz RF decoding with a Picaxe?

[Jeremy Harris]

I've tried searching the forum and can't find a mention of this, so before I go delving into trying to decode the bit stream sequence that these units use I thought I'd ask here first.

A bit of background:

There are quite a few RF encoded power switch/dimmer devices on the market. All seem to use 433MHz RF links, with at least a couple of encoding methods. I have an application where I need to switch a dozen or so low voltage circuits remotely and the HomeEasy range of switch transmitters seem ideal for the job (see here: http://www.homeeasy.eu/Transmitters/). I've purchased an HE308 dual wall switch transmitter to play around with and can get a bit stream out of a 433MHz receiver OK. The unit sends a repeating sequence that looks like this when a switch is made:


Each high pulse in the above bit sequence is about 280 to 290µS long, the short "zero" gaps are about 230µS, the long "zero" gaps are about 1.24mS and the initial very long "zero" gap is about 2.6mS long (I think this is probably the "start of data" marker). The time between repeated data bursts seems to be 10mS and the whole data burst seems to be about 69.42mS long.

My aim is to make a receiver that can output a simple serial code that corresponds to each switch and its condition, whenever a switch is pressed. I'll then feed that serial data into another Picaxe that can control 12V power switches on or off, as required (or even maybe PWM dim some of them). The ultimate aim is to be able to control LED lighting in a house, without needing to run 12V wiring to light switches. Each bank of 12V LED lights will be radially wired from the main control box, which may be some distance from the 433MHz receiver, hence the serial data link.

Try as I might I can't seem to find much out about the way these units encode data, so I'm going to have to try a brute force method to look at the pulse widths of the incoming stream and try and reverse engineer the format. Before I do this, I thought it worth asking here if anyone has tried something similar. If so some pointers as to any pitfalls found would be useful.

 

[geoff07]

I tried to decode a weather station bit sequence, with little luck I may say. However the code I used might be useful to you to get started. The key things to note:

- a Picaxe isn't fast enough to decode sequences with timing such as yours on the fly, so I stored into eeprom and then analyzed later, but you may have more bits than my setup had to cope with
- the code has the bit/byte structure built in, you will need to adjust for what your bit-stream does
- it writes to the sertxd window in PE so you can see what is going on
- it uses count to measure the pulses and a threshold to determine whether it is a 1 or 0. That may or may not be the right way for you to discriminate.

There is a pdf and a .bas file of the same attached but you will have to rewrite anyway.

 

[Jeremy Harris]

Many thanks. I have a suspicion that decoding this may be somewhat of an uphill struggle!

From what I can tell, the encoding system used seems to use Manchester encoding. Each bit value is determined by two transmitted bits, with the initial "bit plus 2.6mS zero" being the start of the sequence. There seems to be 32 bits in total, (so 64 transmitted bits) and I need to do a bit more work to see how I can decode this.

My initial thoughts are that the Picaxe might just be fast enough to measure the input pulses, determine whether a two bit sequence is a "1" or a "0" and store the received bit. There is around 1.5mS available to do this. I've managed to find a reference (buried in some undecipherable Arduino code) that says that the format is:

- bits 0-25: the group code - a 26 bit number assigned to controllers.
- bit 26: group flag
- bit 27: on/off flag
- bits 28-31: the device code - a 4bit number.

If I can get the initial received RF decoded to this 32 bit sequence then the rest should be fairly easy to do (I hope!).

 

[hippy]

The RF itself doesn't seem to be Manchester encoded as the pulse highs all seem roughly the same length. Manchester usually ends up with highs and lows of different length and there appearing to be a different number of pulses in different packets. I'd say it was standard(ish) pulse-width.

Best way to approach this is to get as many traces as possible - turn 1 on, turn 1 off, turn 2 on, turn 2 off - for each convert the gaps between pulse highs to 0/short 1/long and see if there's any pattern emerging. Repeat the same traces multiple times to make sure they are the same every time and try to spot what is consistent and what isn't.

It's laborious but it's the best way.

 

[Jeremy Harris]

I may well end up doing just that, comparing strings of bits, but as you say it is a bit laborious.

I've managed to find a reference that refers to the code format used for these devices as being:

275µS on followed by 2,675µS off = start of data packet
275µS on followed by 275µS off = 1
275µS on followed by 1225µS 0ff = 0

So, looking at the example above this seems to decode as:
10 10 10 01 10 01 10 10 10 10 01 10 01 01 10 10 10 01 01 10 01 10 01 10 01 10 10 01 01 10 01 10 for the 64 bit raw sequence (ignoring the final end-of-data-packet high bit)

As it's Manchester encoded, a 01 in the above sequence is really a 0 and a 10 is really a 1. Translating from Manchester to binary (LSB to the right) this then becomes:

11101011110100111001010101100101

Breaking this down it then looks like:

11101011110100111001010101 = group code
0 = group flag
1 = "on" code
0101 = device code

This fits, as the switch in question was being turned "on" for this test.

Now all I need to do is write the code.................................

 

[Jeremy Harris]

I think I've cracked it, but the code needs a lot of tidying up.

The approach I've taken is to run the Picaxe at 32MHz to get the instruction execution time down as low as I can, then use a for-next loop that collects a big bunch of negative going pulsin readings and stuffs the most significant bytes of each into storage variables. Decoding takes place after the big linear array has been stored, by examining each byte to find the long (~10mS) "start of data packet" location. The next 32 bytes represent the decoded data.

The decoding can be simplified because a true "1" ends up as a MS byte value of 3, a true "0" ends up as an MS byte value of 0 and the "start of data packet" byte is 8. All told it's probably only a dozen or so lines of code, with the really fast bit being just 6 lines.

I'll post the code when I've finally got it tidied up, as it might be useful to others. It seems that there are a lot of home automation sensors that use the same coding system, could be handy for any number of Picaxe projects.

 

[Hemi345]

Did you make any progress on this? I'm tossing around the idea of trying this for my humdistat project.

 

[Jeremy Harris]

Sorry, I should have come back here and posted the code. You can find it on a friends Sourceforge project site, here: http://sourceforge.net/p/opentrv/code-0/205/

The code works fine for receiving HomeEasy data and outputting a simple ASCII hex code that can pretty easily be used to control another Picaxe doing power switching etc.

 

[Hemi345]

Thanks Jeremy.