Radio Remote Decoding

This article is about decoding radio remote controls using Arduino or similar hardware and a cheap 433Mhz radio receiver (£2 on Ebay) and was written to serve a purpose: NONE of the existing libraries I could find out there managed to detect all of my radio remote controls.

Cheap radio remotesI’m interested in adding radio remote for mains control to my house control system which is basically an Atmel 1284 chip with Ethernet and radio network.  Although it is easy to make a remote switching unit that will be part of a network and control mains lights, it is overkill and it is also quite difficult to find dirt cheap mains to 5v supplies to go into one of the limited range of plug-in-the-wall project boxes along with a controller and a relay.

With that in mind I started to look at the many mains switch remotes available out there. These generally work using simple 433Mhz radio receivers and accepting a code which could be almost any length but is normally somewhere between 10 bits and 50 bits.. the encoding techniques vary. Generally speaking these do not use any kind of “rotating” encoding for security and simply use a block of data, repeated as long as you hold the remote button.

BUYER BEWARE: If you want to control lighting using plug-in-the-wall 433Mhz controllers you should be aware of two things…

[a] the cheap controllers you find in the likes of B&Q use a single frequency which is EASILY blocked by other, similar transmitters.  I found when experimenting with a radio link at 433Mhz that it was easily blocked just by holding a button down on a mains remote controller.

[b] I found a nice cheap set of these plug-in-the-wall mains switches at ALDI recently, 3 remotes and a handset for £10 – what a bargain – but then looking at the fine print – you “train” them by turning them on and pressing a handset button within a few seconds – and that’s fine.. but, I thought, what about power cuts? Sure enough – you have to re-train them every time. What idiot came up with that brilliant idea? Going around the house re-training remotes every time the power fails? Surely not?  But I tested them and that is how they work. They are boxed up ready to be returned – not “fit for purpose”. That is, to be fair, the first time I’ve come across this but if you order online – beware!

ReceiverOk, so what could be difficult the handset lets out a 433Mhz modulated signal when a button is pressed – and the mains blocks pick up this signal, decode it and turn the plug on or off – so all you have to do is read the signal coming off the handset and use Arduino (or PIC etc) existing libraries to record and play back, right? Wrong – I had at least two handsets that use a code which was so long the existing learning libraries could not handle them AT ALL.

Eventually after much reading and learning I decided to do my own thing.

Scope with noise from radio receiverSo, easy enough, (both the transmitter and receiver which I’ve linked to below have ground, power and signal leads – nothing else – the receiver appears to have two signal leads but they are connected together – you need only use either one) assuming the output of the simple receiver is LOW on standby, press the remote and look for the start bit – capture the length of each change of state until the end?  Right?

Well, no… the package is sent over and over – so you have to look for gaps between packages. Easy? Well yes except for AGC – automatic gain control. When the receivers are receiving “nothing” they get more sensitive and in my office the spikes coming out of the output were horrendous. I tried ignoring narrow pulses with limited results then I twigged.. if you run the remote control near the receiver – the noise goes away as the AGC (automatic gain control) kicks in…

433Mhz transmitterSo – press the remote control button – THEN start scanning – and store the gaps between pulses – say, 300 of them.  I did this with some REALLY simple code looking for high and low using the micros() function in Arduino (millis() is way too course) and keeping the code tight by simply storing the actual value of MICROS() in a long array.. ok not efficient but for temporary storage it works and I can get consistent results.

I discovered that all the controls send repeated packages with a short absence of signal in-between. Given the noise issue, the first package often gets scrambled – the breakthrough came when analysing the stored values and realising the solution is to search for the first repeat – i.e. after the first BREAK –hence ignoring the first package – previous attempts to use that had yielded varying results at the start of the package. By the time the second package kicks in the AGC has adjusted and the noise has all but gone.

So this would give me an output like this typical one from a handset.


They vary of course in length (not from key to key in that case just the order of bits varies) but from handset manufacture to another model or manufacturer).

What I did notice were pairs of zeros… ie pulses twice the width of others. On reading up this is called Manchester coding (or a variation) – I chose to ignore this – but knowing there will never be more than TWO different pulse widths helps a lot… in reality I realise that there is only one period in this type of encoding.. see this for pictures and explanation if you are interested.

As you can see from that link, the clock and data are encoded into the one signal.

But for my purposes it’s really NOT important to either understand or use this knowledge. All that is necessary is to send that stream out – fixed width per pulse as per the original and if there are two identical adjascent values (ie 00 or 11, detected by longer and shorter pulses compared to a fixed value indicated by the first pulse) then obviously you simply send the status quo to the output bit for twice the length of time.

But this uses up a lot of storage.  Looking at various handsets I discovered the largest signal seems to be around 40 or so bits… I made up a 12-byte array and wrote a routine to bit-shift the entire array by one bit – hence allowing me to convert the string above to a more sensible set of bytes.


In addition I added a byte at the start which represents the width of the basic pulse – as this could be as high as 1200us, I divided this by 10 to fit into a byte. In the example below you see 33 added to the start – ie 330us pulse width. On experimenting, that slight loss of accuracy seems unimportant and it saves a byte.


And so for any given button – we now have 11 bytes (in this case) to encode it. I decided that was GOOD ENOUGH.  A little routine to read from the end backwards, sending out pulses (or no pulse) for the duration specified in the first byte – VOILA I was accurately switching mains lamps on and off via my cheap transmitter.

Most of the code is unique, some bits are variations on stuff I found on the web (thanks to all who’ve taken the time to put their ideas up on the web) – and is provided here UTTERLY without support – no comments on styling please – if you’re having trouble reading radio remotes for your purpose – I hope this is useful.

The transmitter and receiver are here

Change input and output pins to suit your project – any pin will do, if you get nothing having pressed your remote then sent A to the board via the Arduino serial monitor, then try messing with INTER_CMS-MS and MIN_POS_WIDTH but I suggest not before you do that, you check with a scope that something is actually coming in.

Clearly in any end gadget you make for your use, you’d not include the learning part or it’s huge TBUFF array. When I get a minute I plan to come up with a means to simply store the data in EEPROM and read from that…  mind you – if you use a 1284 chip instead of the old 328, memory isn’t quite the problem.

If you need more range, you could consider putting the transmitter (NOT the receiver) on a higher voltage up to 12v. I tested mine at 12v and the signal from the 5v logic still worked perfectly. The increase in range is noticeable – I’d say 50% better coverage.  If you blow up your board however, that’s your responsibility – don’t come back to me…

This is all suitable for short bursts to control stuff – don’t get any ideas about continuous home control signalling unless you can guarantee there are no other 433Mhz transmitters in use! I went down this route before realising it’s a non-starter and am now looking at the slightly more expensive frequency hopping chips for more sophisticated use – but if all you want to do is turn something on and off – this could be for you.


// I used a simple 433Mhz tx and RX pair - 1 pin each needed. Output of radio assumed 1 when something there ie active high
// No interrupts or clever tricks used
// Using F() in strings merely to keep RAM down, and PROGMEM for arrays - that's the data you see on the serial display for one particular button press... 
// Could store this in EEPROM or whatever... for now could get a lot of these for a particular application into ROM without using up precious RAM
// None of the PROGMEM stuff is essential - just there to minimise RAM use
// Coding Peter Scargill June 2014.

#define PIN_DATA_IN 2
#define PIN_DATA_OUT 11
#define SERIAL_SPEED 115200
#define INTER_CMD_MS 100
#define CMD_REPEATS 5
#define COMPRESSED_ARRAY 12 // assume that's enough
#define MIN_POS_WIDTH 200 // used before we have the period - assumed minimum acceptable PERIOD less than which we ignore - in Microseconds
#define MAX_NEG_WIDTH 2000 // assumed maximum acceptable ZERO state in uS above which is assumed a gap between blocks of data
#define READINGS 300 // For temporary storage while learning, need 4 bytes per reading... so WATCH OUT - 328 only has 2k of RAM
#define TIMEOUT_VALUE 3000000 // Number of microseconds before we give up the ghost - ie 3 seconds - likely won't happen due to noise

// Byron reports 39us*10 for period - didn't work - so I put in 59 - works a treat.

const byte g0[]PROGMEM={59,77,211,36,73,146,52,73,210,52,1}; // Byron D2on
const byte g1[]PROGMEM={59,217,150,109,217,178,45,91,18};
const byte g2[]PROGMEM={59,219,182,109,217,178,45,91,18};

byte tbuf;

byte arr[12];

// Used to set a timeout
unsigned long start_time;
unsigned long timeout;
unsigned long current_time;

unsigned long calc;

// Stores all the values read here
unsigned long readings[READINGS];
int current_reading = 0;

// Collect serial data into an array - or timeout as you prefer
void readRadioPulses()
    for (int a=0;a<COMPRESSED_ARRAY;a++) arr[a]=0; // wipe the eventual storage array
    for ( current_reading = 0;  current_reading <READINGS; current_reading++) // store enough values for 2 or more packages - as long values for speed
        // Waits until the input goes HIGH 
            while (!digitalRead(PIN_DATA_IN))
                if (micros() > timeout) return;
        // When the first value comes, save that period
        readings[current_reading] = micros();
        digitalWrite(13, HIGH);
        // Wait until the input goes low

            while (digitalRead(PIN_DATA_IN))
                if (micros() > timeout) return;
        readings[current_reading] = micros();

void shiftArray(int x) // move the entire array toward the highest offset by 1 bit and add least new significant bit to offset 0
  for (int a=sizeof(arr)-1; a>0;a--)
      arr[a]<<=1; arr[a]|=(arr[a-1]&128)>>7; 
  arr[0]<<=1; arr[0]|=x;

// Sends the data to the serial port
void displayRadioPulses()
  int speed;
  byte pickone=0;
  for ( current_reading = 0;  current_reading < (sizeof(readings)-1); current_reading++)
      if (((current_reading&1)==0)&&(calc<MIN_POS_WIDTH)) { current_reading++; continue; }      
      if ((calc>MAX_NEG_WIDTH) &&((current_reading&1)==1)) { pickone++; if (pickone==1) speed=readings[current_reading+2]-readings[current_reading+1]; }
      if (pickone==1) // extract string here
          if ((current_reading&1)==0) 
              if (calc>(speed+(speed/2))) 
                    Serial.print("1"); shiftArray(1);
                Serial.print("1"); shiftArray(1);
                if (calc>(speed+(speed/2))) 
                    Serial.print("0"); shiftArray(0);
                  Serial.print("0");  shiftArray(0);              
  Serial.print(speed/10); Serial.print(",");
  for (int a=0;a<sizeof(arr);a++) { if (arr[a]) { Serial.print(arr[a]); if (a<(sizeof(arr)-3)) Serial.print(",");  } }  Serial.println("");

void sendRadio(const byte *m, int sz) // can't do sizeof a PROGMEM array so just pass the size
   int scount;
   int offs;
   int period;
   byte tmp;
   period=(int)pgm_read_byte(m)*10; // get the first value, multiply by 10 and that is your period
   for (scount=0;scount<CMD_REPEATS;scount++)
       for (offs=sz-1;offs>0;offs--) // start at the end and work backwards not including offset zero which is the (period/10)
          tmp=pgm_read_byte(m+offs); Serial.print(".");
           for (int r=0;r<8;r++) { if (tmp&128) digitalWrite(PIN_DATA_OUT,HIGH); else digitalWrite(PIN_DATA_OUT,LOW); start_time=micros()+period; while (start_time>micros()); tmp<<=1; }
        digitalWrite(PIN_DATA_OUT,LOW); delay(INTER_CMD_MS);

// Listens to SERIAL for inputs A=read, B=write demo - when reading press and hold handset FIRST
void SerialRequest()
   char c;
   while (Serial.available()==0);;
    if (c=='A')
        start_time = micros();
        timeout = start_time+TIMEOUT_VALUE;
      if (c=='B') // try the example compressed code which includes (period/10) as first byte - can be any length

     if (c=='C') // toggle 2 codes back and forth for range testing
       Serial.print(F("Test toggling..."));
       for (int a=0;a<200;a++)

void setup() // set serial speed, set output for the radio output - and put something on screen to show it's working - use built-in F() to save RAM
    pinMode(PIN_DATA_OUT, OUTPUT);    
    digitalWrite(PIN_DATA_OUT, LOW);
    Serial.println(F("Send A to check or B to send example in PROGMEM"));

void loop() 
    SerialRequest(); // I could have just put the lot in here really

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s