Decoding 433MHz RF data from wireless switches. The data

[UPDATE 2013-03-01] I have added links to the encoder chips these two remote use and removed some miss-assumptions for the Noru remotes. The explanation now is simpler, but the main questions about the Noru codes remain.

In my previous post I explained how I decoded the data from two wireless outlet remotes using a couple of libraries for Arduino and a Bus Pirate in logic analyser mode. Now I want to go more in-depth, showing the captures from OLS and the data I obtained.

A bit of theory

Just a little bit. These remotes send the information using a common type of modulation called Amplitude-Shift Keying (ASK). This is the digital equivalent to the Amplitude Modulation (AM) used in long distance radio broadcast. The information is encoded as an increase or decrease in the amplitude of a carrier wave of (in this case) 433.92MHz. The information itself is sent at lower frequencies (some tens of KHz).

Since ASK is meant for digital communications, the information itself is encoded as a stream of 0’s and 1’s. A pattern of 0’s and 1’s define a “state”. The remotes like the Avidsen I have use 3 different states, code bits or tribits. They all begin with a high pulse (a 1) and end with a low pulse (a 0). The next image shows the pattern for these 3 states:


Note that you can speak these patterns in different ways: as a succession of pulse lengths, like “short long short long” or “1313” (the long pulses are three times longer that the short ones) for the tri-bit 0, or as a tuple of bits like “00” (1 for a long high, 0 for a short high).

Now, the full signal is a series of code bits, a code word. 12 for the two remotes I have checked. These 12 code bits can be writen down as “11111FF0FFF0” (this is the ON command for outlet C in channel 31 for the Avidsen remotes).

Since the tribits are, well, 3-state bits, you can think of the previous code as a base-3 number, where the ‘F’ is a ‘2’: 111112202220. the RemoteSwitch library has a method that accepts the decimal equivalent for this base-3 number, with in this case is (read back-wards, the least significative bit is the rightmost one):

0*3^0 + 2*3^1 + 2*3^2 + 2*3^3 +
0*3^4 + 2*3^5 + 2*3^6 + 1*3^7 +
1*3^8 + 1*3^9 + 1*3^10 + 1*3^11 = 266649

But this number is just a convenience and we are moving away from the actual signal representation.

Avidsen remote

These remotes use the PT2262 parallel to serial encoder (datasheet). These chips have 12 parallel input lines you can individually set to HIGH, LOW o leave them floating for the three different states or tri-bits. When the input lines are set you assert low the TE pin and the data is encoded and output through the DOUT pin. They are supported by existing Arduino libraries (more or less, see the patch for the RCSwitch library in my previous post). The code word is a stream of 12 tribits arranged this way:

  • The first set of 5 are the channel (the one you configure in the dip switch of the remotes and the outlets). This is a value from 0 to 31 which is actually encoded in binary where the tribit 1 represents a 1 and the tribit F represents a 0.
  • The second set of 5 tribits is the outlet identification you configure in the second set of 5 dip switches of each outlet. All the tribits in this set must be set to F except for one, which represents the outlet selection in the remote from A to E.
  • The last set of 2 tribits represent the action, and it can be “F0” for ON, or “0F” for OFF.

Now, some captures.

Channel 00, Outlet A ON - FFFFF0FFFFF0

Channel 00, Outlet A, ON – FFFFF0FFFFF0

Channel 31, Outlet C ON - 11111FF0FFF0

Channel 31, Outlet C ON – 11111FF0FFF0

Channel 31, Outlet A OFF - 111110FFFF0F

Channel 31, Outlet A OFF – 111110FFFF0F

With these information you can actually control up to 32*5=160 different outlets from your favourite microcontroller.

Noru remote

This remote uses the HS1527 programmable encoder (datasheet). These chips have a hardcoded preamble of 20 bits (normal 0/1 bits) and 4 data lines to set 4 data bits. The total length of the message is the 24 bits. Mind these are normal bits: 0 is encoded as a short high pulse followed by a long low one whilst 1 is encoded as a long high pulse followed by a short low one.

The message length is thus the same as in the previous remote but it is not 100% compatible with the Arduino libraries since you can encode a forth combination of highs and lows, a fourth state or tetra-bit mimicking the naming convention:


The codes for the 14 buttons of the Noru remote are (in binary format and tetra-bit format):

Button Binary Tetrabits
ON1 110100000000001101011000 1F000001FFX0
OFF1 110100000000001101010110 1F000001FFFX
SET1 110100000000001101011101 1F000001FF1F
ON2 110100000000001101011100 1F000001FF10
OFF2 110100000000001101010100 1F000001FFF0
SET2 110100000000001101011011 1F000001FFX1
ON3 110100000000001101011010 1F000001FFXX
OFF3 110100000000001101010010 1F000001FF0X
SET3 110100000000001101011110 1F000001FF1X
1H 110100000000001101011001 1F000001FFXF
2H 110100000000001101010111 1F000001FFF1
4H 110100000000001101010011 1F000001FF01
8H 110100000000001101010001 1F000001FF0F
ALL OFF 110100000000001101010101 1F000001FFFF

As you can see the first 20 bits are always de same. It’s the identification hardcoded in the HS1527. Only the four rightmost bits change. There are 16 possible combinations and 14 are being used by the 14 buttons (only the 00 and 11 endings are missing from the table). But, is there any pattern in this 4 bits?

There are some clues to start working with:

  • Some codes are common for all the outlets (the timeouts and the ALL OFF button)
  • Some codes are specific for a certain outlet (ON, OFF and SET)
  • When you start using an outlet you first have to set it in learning mode and press the ON button in the remote for the number you want to assign to it. From then on the outlet will start responding to that button, but also to the OFF and SET buttons for the same number. So there has to be some pattern that links ON, OFF and SET buttons for the same outlet.
  • According to the documentation an outlet can learn more than one code. The same code can be linked to more than one outlet and one outlet can respond to more than one code. I don’t know if this is somewhat useful to figure out the pattern but it’s cool!

Some captures for a couple of Nero remote signals and enough for now.

Outlet 1 ON - 1F000001FFX0

Outlet 1 ON – 1F000001FFX0

Outlet 2 SET - 1F000001FFX1

Outlet 2 SET – 1F000001FFX1

CC BY-SA 4.0 Decoding 433MHz RF data from wireless switches. The data by Tinkerman is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

14 thoughts on “Decoding 433MHz RF data from wireless switches. The data

  1. Pingback: Decoding 433MHz RF data from wireless switches | Tinkerman

  2. icebear


    I have a weird problem with some new remotes I bought.
    I already can control my RC-710 outlets using the code I found here (and also via RC switch):

    from the same page I used the instructions to decode the signals from my new ‘Flamingo’ outlets remote control
    (the Flamingo outlets more or less seem to be the same a the ELRO 440, but dont have DIP switches).

    I had no problem to decode the signal (mis-)using an audio editor and my soundcard as ‘poor mans osciloscope’.

    this is the remotes signal for ‘ch a off’ as captured with audacity:

    I also could rebuild the signal manually as described here
    (basically only had to tweak the ‘wait’ function to wait 324 microseconds instead of 350).

    And I also could send an identical signal via RC switch, it detected a PulseLength of 331 microseconds.
    However, in order to have identical signals in my poor-osci I had to use 324 microseconds also for RC switch.

    but now both signals match (top is original remote, on bottom the arduino generated signal):

    what RC switch captures from the orig remote:

    Decimal: 5243156 (24Bit) Binary: 010100000000000100010100 Tri-State: FF00000F0FF0 PulseLength: 331 microseconds Protocol: 1
    Raw data: 10280,352,964,956,372,352,956,944,388,340,976,344,976,352,956,352,972,356,956,360,968,360,964,320,992,348,968,332,996,332,976,964,352,360,968,344,976,348,964,956,376,344,972,952,368,348,972,340,980,

    watchin this in Sui’s oszi:

    so it all seems to match, but the damn outlets only switch with the remote, but not from the arduino.

    its not a problem in my transmitter setup, I can still switch the RC-710 outlets, and can capture the sent signals as well.

    Any ideas why the problem could be?

    1. xose Post author

      It certainly looks like you’ve put a lot of time and effort on this… As you say everything seems to match and I don’t have a clear advice to give you…
      I don’t think the timing is an issue (331 or 324 microseconds), these remotes have to work on very noisy wave-space so they have to be somehow tolerant to small changes in the timing. But, maybe, you might need to send the same code several times for the remote to check it right… (just guessing, have you test it?).
      Anyway, you know what they say: devil is in the details.
      Take a rest from the project and come back in a day or two and you might find yourself the answer…

  3. icebear

    thnx for the advise and sorry for the late reply.

    it’s more or less what I did, esp. as I only bought those nasty flamingo things as the euro models where sold out at my local store.

    but those friendly dudes replaced the flamingos with the elros a few days later without any arguing or so.

    I now drive 14 switches/dimmers without any issues and don’t regret I got rid of the flamingo switches.

    best regards

  4. Ronn

    Dear Tinkerman,
    How do you Analyze the wireless 433 MHz / 868 MHz Wireless Signals, what Analyzer Tool do you use?
    I’m Interested in capturing Weather Station signals, Wireless PIR sensor signals for Alarm Systems.
    Best Regards

    1. xose Post author

      Hi Ronn

      This post is the second part of a previous one where I explain the tools I used to analyse the signals from the wall outlets, check it out here: Decoding 433MHz RF data from wireless switches. If you are lucky you might just need and Arduino and one of the two libraries I mention in the post: RCSwitch or RemoteSwitch. I had to go a little further and used a BusPirate and OLS Logic Analyser to get a graph of the pulses and understand what was going on (there was a slight modification on the encoding that prevented the libraries to decode the signal).

      Just one more thing, there are a bunch of things that will vary from device to device: frequency, encoding, protocol,… try to focus on each one of these separately, otherwise things might get really messy.

      Good luck!

  5. Pingback: » came code finder

  6. Pingback: New firmware for the Slampher | Tinkerman

  7. Arduino

    The original RemoteSwitch library is indeed old but it has been completely rewritten and is updated here
    The nice thing about that library is that you (usually) do not need to ‘sniff’ the remote sender. If you know what brand remote you have the library ‘knows’ what codes to send. This ofcourse is only partly true for learning remotes but even then it is often possible to use a random base code

    1. Xose Pérez Post author

      You are right. The problem is that these remotes are not normally in the database, because they are often rebranded remotes from already very little known manufacturers.

  8. Pingback: 逆向分析智能窗帘频射协议 - 莹莹之色

  9. Pingback: 逆向分析智能窗帘频射协议 - FreeBuf.COM | 关注黑客与极客

  10. Pingback: 逆向分析智能窗帘频射协议 – s3xy's Blog

  11. Pingback: 逆向分析智能窗帘频射协议-物联网安全实验室

Leave a Reply (all comments are moderated, be patient)