Last year I wrote about my plans with the RF Link Transmitter, Receiver, and Everflourish home automation system seen in the pictures below. The idea was to replace the remote with my own system, and control the switches using the RF transmitter and an Arduino. However, the problem was to first decode the bespoke message sent from the remote so I could reproduce it. Initially, I was concerned that the RF receiver was giving a too noisy signal; only reading its value from the Arduino and printing to Serial.out did not yield anything useful. It was not before I took the Arduino out of the loop, and connected the receiver directly to a oscilloscope that things started to look more promising.

On the oscilloscope, I could see the message very clearly. Now I just had to write it down, and analyse the code for all different buttons and remotes. Here the problem was that each button sends a rather long message, 52 bits in total, and the old oscilloscope I tried did not have much memory to store recordings to. Also, it wasn't mine, so was not so convenient to access and work with. Enter the real break-through of this story: Dave Houston brilliant idea and post about a poor man's oscilloscope - your sound card! He works with various X10 systems himself, and has more interesting information on his site. For the sound-card hook-up, any audio-wire will do; if using a stereo wire and mono recording, figure out which side is which, add some resistors (39k and 10k was suggested; I ended up with one 1 k Ohm and another at 100 Ohm, which worked just as well). David also points out that the line-in should be used, rather than the microphone plug.

The next bright idea came from Ray, who has done exactly the same project as I wanted to do, but with a different remote control system. He shows how the open source audio tool Audacity can be used to record and analyse the message. I found that Audacity also had a neat feature in that you could add a Label Track, that made it easy to write down the code, and later export it, as seen below.

The screenshots below show a recorded signal in Audacity, first at an overview, then zoomed in, labelled, and finally marking the length of each segment. Notice in the first picture how there is a lot of noise before the remote button is pushed, but that it is very clear where a signal comes in (repeating four times). Also, as seen from the second picture, the signal is strong and clear, without much noise as all, which speaks for the quality of the RF receiver, I guess. In the third picture, the segments has been labelled; see below for how to extract that, and further details about the code.

Click on the pictures for larger versions.

Each of the remote control systems have their own proprietary encoding for the messages sent, and the Everflourish system I have has a very different code from Ray's Stanley equipment. Each bit in the message is expressed by a high with varying length followed by a low of common length. In the last picture above, these segments have been labelled, and as can be seen, the long high is twice the length of the short (50 vs. 25 samples) while the low space is at 30 samples. That's using a sample rate of 44100 Hz. Ray points out that you can zoom all the way in, and count the individual samples. Another way is to use the unit selection in Audacity (at the bottom of the window), and select the highest precision unit "hh:mm:ss + samples", and then select the area of one segment. The start and end timing is then shown at the bottom of the window, and it's a matter of simple subtraction to find the length. Much easier than counting 50 samples.

For the Everflourish code, only the highs matter then, so I recorded one button, cut out the relevant message, copy/pasted it to a new Audacity project, added a Label Track as seen from the menu above (Tracks -> Add New -> Label Track) and went through and labelled the highs with 0 for short and 1 for long. That was just an arbitrary choice. Once done, the new project was saved with a descriptive name of the remote and button, and the labels could be extracted from the XML project file with something like this. (As a bonus, the digits are split into 4-bit nibbles.)

cat remote1_button2_off.aup | grep label.*title | cut -d '"' -f 6 | tr -d '\n' | sed "s/\([01]\{4\}\)/\1 /g"

Below, the messages from three different remotes (with 4 + 4 + 8 = 16 buttons) are listed, but in the interest of space and simplicity, only some are shown. From this I conclude that only a few parts of the message are consistent between the different remotes. First, it always starts with a 0-nibble. The ON and OFF buttons are consistent and reversed across all buttons. Beyond that, it's hard to tell what is encoded. There is possibly a marker in the middle, at the seventh nibble, marked in gray, but it could be a coincidence. The third nibble is also the same for all three remotes. As can be seen, the two first remotes share data in the first part, and one could be led to believe that this was a common preamble, but this must be rejected when looking at the third advanced remote.

That seems to go against what is assumed in the the source code from TellDus. There they assume a "house" and "unit" (button) key on the last nibbles before the on/off code, but that does not match what I see across my remotes. There seems to be nothing identifying a specific remote, but rather all buttons are unique, and there is possibly some kind of general batch (as opposed to unique serial) number at the beginning of the message.

Simple 4 button remote

1 - OFF : 0000 0110 0101 1010 1001 0110 0110 1001 0101 1010 1010 0101 0101
1 - ON  : 0000 0110 0101 1010 1001 0110 0110 1001 0101 1010 1010 1010 1010

2 - OFF : 0000 0110 0101 1010 1001 0110 0110 1001 0110 0101 0101 0101 0101
2 - ON  : 0000 0110 0101 1010 1001 0110 0110 1001 0110 0101 0101 1010 1010

3 - OFF : 0000 0110 0101 1010 1001 0110 0110 1001 1001 0110 0110 0101 0101
3 - ON  : 0000 0110 0101 1010 1001 0110 0110 1001 1001 0110 0110 1010 1010

Simple 4 button remote

1 - OFF : 0000 0110 0101 1010 1001 0101 0110 1001 0101 0110 1001 0101 0101
1 - ON  : 0000 0110 0101 1010 1001 0101 0110 1001 0101 0110 1001 1010 1010

2 - OFF : 0000 0110 0101 1010 1001 0101 0110 1001 0110 1000 1000 0101 0101
2 - ON  : 0000 0110 0101 1010 1001 0101 0110 1001 0110 1000 1000 1010 1010

3 - OFF : 0000 0110 0101 1010 1001 0101 0110 1001 1001 1010 0101 0101 0101
3 - ON  : 0000 0110 0101 1010 1001 0101 0110 1001 1001 1010 0101 1010 1010

Advanced 8 channel remote

1 - OFF : 0000 1010 0101 0101 0101 1010 0110 0101 0101 0110 0110 0101 0101
1 - ON  : 0000 1010 0101 0101 0101 1010 0110 0101 0101 0110 0110 1010 1010

2 - OFF : 0000 1010 0101 0101 0101 1010 0110 0101 0110 1001 1001 0101 0101
2 - ON  : 0000 1010 0101 0101 0101 1010 0110 0101 0110 1001 1001 1010 1010

Determining the length of each segment to be sent is done by looking at the sample rate. I used 44100 Hz, so the duration in micro seconds for the 30 sample space segment is 30 / 44100 * 1000000 = 680 µs. For the short 25 sample high, it is 567 µs, and double or 1134 µs for the long. When sending the message, I did not need to subtract anything from that, as Ray mentioned in his post. It is worth noting the initial high before the start of the message, and also at the end. Furthermore, it both starts and finishes with a low space, so whatever for-loop you create, one of these will be before or after. However, what is intriguing, is that all this can be reversed. That is, switch HIGH and LOW in the code, and the switches will still react. I'm guessing this is a robustness measure designed into the Everflourish system, but I have to admit that goes beyond my RF knowledge.

Finally, it's worth mentioning the All On or All Off buttons. They simply send a series of messages for each of the buttons, repeating each button message four times before moving on to the next. When using the single on/off buttons, the message is also repeated four times for a short click.

And that's all for now. I expect to round this project up with a post on the complete system, including communication from the computer, and some kind of Android application as a remote. Other ideas include auto-triggering the lights when detecting a pre-defined Bluetooth device, and possibly switching off in the absence of any device. Possibly some programmed behaviour during holidays, and pre-set configuration for certain situations, e.g. "movie setting", "dinner time", etc.