RF signal decoding

Dear all,

I’m just posting this new message to have some help and tips in my new project.

I’m currently working on an alarm system, my house is equiped with wireless detector, and I succeeded to “read” and “understand” the 433 MHz signal send by the detector. As it can be show on the picture attached to this message, the transmission start with a high value of 420 µSec; then it a sequence of 1 (low value of 420 µSec followed by a high value of 840 µSec) and 0 (low value of 840 µSec and high value of 420 µSec), the signal is repeated three times, and the last numbers change according to the “value” send by the detector (low voltage, opening detected,…)

I tried to use library like RCswitch, which one is working perfectly with other wireless device, but not with those ones, and the code is very complex to be understood (at least for me).

So this is my question : which function can I use to “listen” the 433 Mhz, and start an action when the signal send by the detector is received ?
I think the function attachinterrupt can be used, but I don’t succeed to decode the 1 and 0 received by the receptor … If you have some ideas, it can be very nice to give me some precious tips !

thanks again !

I think that your wireless detector use the HT6026 encoder.


Revealing RF Remote control : http://labdegaragem.com/forum/topics/desvendando-controle-remoto-rf (only in portuguese)

I think you can decode this using delays.
If you loop until you get a negative going edge eg “a” and then so many micro seconds delay, until point “b” and sample input, then if still 0 then probably OK, then add another delay until “c” and sample, this will indicate the value of the bit, high = 1 and low=0, and then sample again at d, if bit is 1 then it should have swapped (0->1), if bit is a 0 it should be the same, then loop for the next falling edge “e” and start all over again. The sampling points at “b” and “d” should make sense otherwise it is probably noise and should be rejected.

Use that to build up the bits into bytes etc.
Make sure you allow for the lead in of a few bits (sometimes up to 80 of them) , like a series of ones terminated by the first zero. These first bits set the AGC on the receiver and can usually be discarded from the signal. The first change bit may or may not be included in any byte boundaries.

Cheers rob


I got a similar problem :~
In the library of RCswitch, the coding of “1” and “0” start with “pulse high”. And it can not send the code start with “pulse low”.

First of all iambenq, let me congratulate you on the clarity of your oscilloscope images, Excellent!!!

However you do not say what your signal is about? Your comment of "send" makes me think it is a sample of your transmitted code/packet? What have you sampled there?

One thing that does stand out though - there is not a standard header of 1's preceding the packet's data. The line is at 0 until the packet begins with one long pulse. One of the practicalities of Manchester encoding is that the Rx'er must be stabilized at a good AGC level and its level detector be midway between the high and low signal to discriminate the pulses. Sending 20 or 30 bit wave forms of 1's is usually done to get the Rx working properly before the data in the packet begins. This header of 1's also allows easy early discrimination between potentially good data packets and noise.

I have not used the package you used, RCswitch, but is is much easier to write code for transmission of Manchester protocol than receiving it.

https://github.com/robwlakes/ArduinoWeatherOS has a copy of my program to receive Oregon Scientific weather station plus an explanation of how the program works. Unfortunately I have not finished the explanation just yet. I am about half way :~ I hope to soon publish a program that will transmit OS style data that my Arduino+433Mhz OS receiver can easily receive as well, so I can incorporate other sensors onto my site eg Solar Energy and hot water tank temperature.

So a few more details would be handy to be able to help you further.

Cheers, Rob

It's the code transmitted from the remote control. When the button is pressed, the code will be sent and repeated 128 times. Obviously, the device is not in the list of RCswitch.

What I want to do is a universal remote control. It can learn the codes from other remote controls, store the codes and send them to remote switches.

I am a newbie coder and looking forward to your help.

Ok the idea of a universal remote sounds good to me, however I am still unclear where this signal on the scope is coming from. Is it tapped from the output of the remote before it hits the RF Transmitter. Could you photograph your set up with an explanation of what's what?? Or is it the 433MHz receiver's output?? ie is it listening to the remote's transmission??

I need a few more clues to be able figure out why there is no obvious header bits.

A 128 times seems rather excessive? Or is that bits in the packet?

Cheers, Rob

As your can see from the attachment, it’s the 433MHz receiver’s output. When the button of the remote control is pressed, Arduino will sniff the transmission and get the codes.

It’s really difficult to figure out the sync word and the line coding. :frowning:

2014-5-17 8-14-32.jpg

Thank you has made things clearer.

I am guessing that this protocol does not have a header as it repeats so many times the preceding data becomes the “header” ie the receiver has so many repeats by the end it will be stabilized and decoding OK.

I have got your graphic and tried to illustrate the way I would decode it bu I am having huge problems just having transferred from XP to XUbuntu, which I am enjoying greatly (but that is another story), but I am just not up to speed to get your graphic (the second One) annotated so I can explain my line of thinking.

My sequences of data would be 0000100000000100001111, which does differ significantly from your interpretation so I need to explain it with a diagram. To this end I have printed it and drawn on it and scanned it. (grrrrr)

Here goes…

A is a once off start of transmission detection ( I am assuming random noise before then). However if this is actually a One then all my following logic will be inverted!!! This is 3 times the Bit Pattern

B is a preamble of some sort as it occurs with every packet? And is 1.5 times the Bit Pattern

How do I guess the bit pattern? That comes from the gap at E, however more of that later.

At C we have the standard Bit Pattern with a duration of 1.0 Equal Off to On.
At D we have half a bit pattern in this case a high.Assuming standard Manchester concepts then the transition from a 1->0 level in the middle of a Bit Pattern == 0 logic data bit, and a 0->1 transition in the middle of a Bit Pattern indicates == 1 logic data bit.

How do we know what is the middle of that data bit? Well I think it is E that tells us because that longer gap indicates a change from a 0->1 or a 1->0, either way the two edges of this transition are in the middle of a Bit Pattern, and the middle of the low is the point between two data bits. If that is traced back to the end of the B gap you will see that this is where the series of four 0’s data bits turns into a series of three 1’s data bits (As opposed to the hi-lo pulses inside a Bit Pattern).

Underneath there is the inverse logic that turns that data stream to opposites 0->1 and 1->0, either could be right unless you have some way of validating the settings externally (eg a DIP switch inside the transmitter??)

I am happy to answer any questions as this by necessity has to be brief or I will kill you of boredom,

So have a look and get back to me,


Hi robwlakes,

I really appreciate your explanation.

I think this protocol is simple because it just repeat the code for 128 time. And I made some modification on the data decoding according to your comments. It’s a little bit different from yours.

I am guessing the protocol is a sequence of " ‘START’ + 23 bits data". I upload a new decoding diagram.

The sequence would be “11110001111111101111000” or “00001110000000010000111”.

Hi IamBenQ,

I was trying to keep it brief (at the risk of being confusing) and I am very pleased you have found it useful. I think you must be close to understanding the protocol pattern.

Does the waveform stay constant between key presses? If the key values "rolls" then it will be well out of my league.

However to be able to extract the binary from the waveform is one thing, the next thing is to work out what the binary means. Somehow the hunches used in interpreting the waveform need to be validated if a general understanding of the protocol is desired. ie What you need to do now is find a range of "key" values that indicate the values conveyed in the signal. For example what happens when the keys on the fob are pressed? Are there dip switches to select a new "key" pattern? Or ways to do a reset to a new random key value and then sync the Rx and Tx again? ie can you gather other examples of the waveform with new data in it? What happens to what they control different things?

For example the first four data 1 bits could be a short header, ie a constant on all key combinations, or it could be a system identifier, or it could be a fob identification number, or part of the number that identifies the device being controlled.

I would like to know what is the same, and what is different, especially before and after the place you have marked "Start", other wise you won't know what is the consistent waveform pattern to synch the Arduino to. In other words- where doe the RF preamble stop and the data payload begin?

Do you have access to documents that spell out these functions? What are the model numbers?

Cheers, Rob

Yes, the waveform stay constant between the key presses. It's a Livolo switch: http://livolo.en.alibaba.com/product/869752907-220294473/Crystal_Glass_Panel_Touch_Light_Switch_with_Red_Blue_darkness_indicator.html

I sniffed the four buttons on the remote control and decoded them:

11110001111111101111000 button A 11110001111111101110000 button B 11110001111111101101000 button C 11110001111111101100110 button D

It seems like a sequence of "16 bits ID + 7 bits data" or"18 bits ID + 5 bits data"

Hi IamBenQ,

Good progress, the pattern seems to building and becoming clearer. Very nice work.... :)

Your Info so far would suggest no rolling code, and the buttons are identifiable.

I am going to suggest that there is no checksum to discover, as the multiple transmissions of the same sequence so many times could allow many copies in sequence for the "ID code" to be collected such that one could be pretty certain a valid sequence has been detected. (However I may be wrong!) Similarly I think the large number of repetitions also means a dedicated header is not required to stabilize the 433Rx as the data packets would be sufficiently numerous that to use a few up at the beginning would not be a problem as there would still be plenty left over to validate a particular button press.

However it does mean that your intercepting Arduino code should probably try to decode the pattern [u]after the very first long signal 3mS?[/u] and try to work on the pattern that repeats over and over after that longer burst, this way, if the RX picks up a signal, and loses the first five or so stabilizing the RX, it won't matter. This would make the Rx+Arduino much more robust. The Livolo lighting/switch people have a number of products, so the next questions come back to what you want your project to ultimately do? Do you want to be able to intercept the remote transmitter with an Arduino+433Rx and so use the remote to also control the Arduino project (eg switch things off and on or reveal status of the system elsewhere etc) or do you want to use an Arduino+433Tx so that you can produce a 433Mhz signal to control the Livolo products (eg detect environmental light conditions and send a remote style 433Mhx signal to control the house lights? Or use a single Arduino to control multiple Livolo products etc). Or let's get ambitious and do it all :) But one thing at a time is a good policy, so where do you want to begin?

111100011111111011.11000          button A
111100011111111011.10000          button B
111100011111111011.01000          button C
111100011111111011.00110          button D

Finally the initial 111100011111111011 part could also contain patterns for other functions that we possibly cannot determine unless other people share what is found in same, or different, Livolo products. eg How does the system avoid the neighbour's controller effecting your system's operation?

Cheers, Rob

Hi robwlakes,

Thanks for your help and analysis. I have tested the code with Arduino+433TX to control the Livolo switch and it works well.

Yes, I want to intercept the codes from the 433Mhz remote control with Arduino+433RX and reproduce them with Arduino+433TX. So I can control the switches or something else with one Arduino board instead of all kinds of remote control. What we do now is recording the codes by audio interface of a PC, decoding them and sending the codes with Arduino. It’s not convenient. I think the ideal solution is self learning. You press one button on a remote control and another one on Arduino board, Arduino will record the codes by self learning and store them in the memory. just like a self learning IR remote control.

Hi IamBenQ,

I can see where you are coming from now, to produce a universal remote at home with this Livolo function, but maybe also emulate other remotes for other devices, so it sounds like the holy grail of remote emulation!!! Go for it!! And maybe build your own receivers to do other functions. Sounds excellent.

In my investigations of the Oregon Scientific Weather stations, I have tried to dig as deep as I can in one product to extract the maximum information, whereas you sound as though you are trying to quickly emulate as many transmitters (ie remotes) across products as possible, and throw in a few ideas of your own.

I like it, but I have probably come to end of my usefulness, so I wish you well with your projects, stay in touch and let me know what you have achieved.