Saturday, 28 June 2014

Hacking 433MHz Remote Controllers

With the introduction this week of the Energenie Pi-Mote control board, my first reaction was to reach for my credit card and place an order.

I don't know just yet what I'm going to do with it, but it seemed like a relatively cheap toy to play with.

While waiting for this starter kit to arrive, I remembered that I was given a 433MHz control kit earlier this year, but had not got around to doing anything with it.

So it was time to get the Velleman VM130 out of the cupboard and have a play.

What's in the box?

The VM130 consists of a 2 channel receiver module and a small key-fob type transmitter with 2 buttons. The receiver module requires 9 to 13Volts a.c. or d.c. to power it, and has 2 relay outputs with contacts good for 240V at 5A (for a pure resistive load).

I guess the reason I haven't used it up to now is because its operated by a key fob. It would be more interesting to control it via a computer. So maybe I could write a program and operate it via the RaspberryPi.

The first problem is working out the codes used and the signaling method. This would be fairly simple if I had a circuit diagram and an oscilloscope. I have neither. But I do have a computer, and the voltages on the receiver are low (12V).

A Poor Man's Oscilloscpe

Computers can be used as simple, low frequency, low voltage oscilloscopes by feeding the signal into the audio input and running an oscilloscope application, such an xoscope for Linux. There are many limitations using this approach, but for undemanding tasks, this is a great low cost solution.

But if you already have Audacity loaded on your computer, that will do for this little experiment.

The lack of a circuit is not a huge problem either. By running the receiver from 8 AA batteries (12Volts) it is fairly safe to poke about a bit looking for the right point to connect to. First of all I attached the screen connection of my audio lead to the receiver pcb fixing point, which I could see was 0V just by inspection.

The main board of the receiver module has a small 433MHz rf board attached via 8 soldered pins. I took a capacitor and attached it to my audio lead and used this to probe each of the 8 pins in turn. The capacitor was a precaution to stop direct current flowing into my laptop sound/mic input.

Initially I used a 0.1uF (brown) but later changed to a 10uF electrolytic

I checked each pin in turn while pressing the key-fob buttons. Pin 3 gave me a nice looking pulse train.

Each one of the 7blobs is a complete message, its just repeated while the button is held down

By highlighting one of the "blobs" on the display, and zooming in to stretch it out, we can see the full serial data stream for the command to turn on a relay.

This highlights one of the limitations of using a computer sound card, rather than a real oscilloscope. On a real scope set to dc input coupling, the trace would start at 2.3Volts, rise sharply, level off, then drop back to 2.3V. But because we using ac input coupling (via capacitors) the sound card is not influenced by the offset voltage when the input is in a steady (non-changing) state.

The input capacitor rounds-off the pulses, and is slow to return the sound card to "zero" because of the capacitors charge/discharge time. So you see an apparent drift downwards, and at the end of the data stream, a very slow return back to the 0.0 line. Initially I used a 0.1uF capacitor, but later switched to a 10uF as this gave a much better response.

Anyway, the trace quality is not that important. When we further magnify the tops of the pulses we get a better idea of how the system works.

You will notice two different pulse widths. The narrower pulses represent logical "0" and they are always followed by a space of the same ("0") width. The wider pulses are twice as wide as the "0" pulses, and these represent logical "1". They are always followed by a space the same width as "1".

Once you realise this, it is easy to read the code, which in this case is:-

0100 1010 1010 1100 1101 1000 1000 0100 1

I've put a space between each group of 4 bits simply to make it easier to read and to count the number of bits. The code used is 32bit, but there is a 33rd bit which I think is part of the protocol to indicate end of data stream (its value is always the opposite of the 32nd bit).

Now there is a little more information needed, which concerns the width of the pulses. Once again, Audacity has a useful time scale which we can use to approximate pulse width. By highlighting just a single pulse and selecting the "Fit Selection" magnifying glass, we can zoom in and take a measurement.

I've measured several "0" and "1" pulses and think it safe to assume that a "0" pulse is supposed to be 300us wide, while the "1" pulse is 600us wide.

So in order to use this module with the RaspberryPi I'd need a 433MHz transmitter module, and a program to pulse data though it, where:-

  • each command consists of 32bits
  • logic "0" is a 300us pulse followed by a 300us space
  • logic "1" is a 600us pulse followed by a 600us space
  • and a 33rd bit is added, equal to the 32nd bit inverted

An Application?

I'm still not sure I have an application for this particular unit. As I understand it, this module has 3 modes:-

  • ON/OFF toggle: unfortunately the RaspberryPi would not know whether the modules output was on or off. This toggle mode only really works when you manually press a button and can see if the equipment is now on or off (the Energenie has separate codes for On and Off, so it doesn't suffer this problem).
  • 0.5s Pulse: if you send a continuous command stream while in this mode, the output will stay on. But this means the RaspberryPi would be banging away all the time you wanted something on!
  • x-time Timer: in this mode the output stays on for a selected duration from 5 seconds up to 1 hour. So this mode may have possibilities in a home automation system (e.g. central heating boost, random lights on/off when the house is empty, random pond pump operation & so on)
EDIT 29-Jun-2014
Thinking about this overnight, it occurred to me that I could add an external relay to create a new mode.

  • Code 1 ON, Code 2 OFF: With the basic toggle mode selected, but with the addition of the external relay circuit above, the channel 1 code will power the relay, which will latch itself on via contact x-a, and the channel 2 code will turn the relay off. Contacts x-b can be used to control external devices. Now I can use this with the RaspberryPi.

Other Fun Things To Do

I couldn't resist using this test configuration to check the un-lock code of our Ford Fusion.

Yep, it uses the same 433MHz frequency and the same basic idea, but with a 6bit pre-amble, followed by a 56+1bit code.

There is only one thing stopping you from acquiring a new car by sitting in a car park with a laptop & 433MHz receiver, collecting unlock codes.

I'll leave you to Google the reason why this won't help you!


  1. Do you know how to make only one relay operate at a time?

    1. I can't find my original notes, but I think you use the code above for the first channel, and the next code for the second channel. The second channel code probably ends with: 0101 0

      I hope this helps.

  2. OK thanks I'll take a look at it again. .

  3. Hello! I love your post, but I had a quick question regarding the Sound Card Oscilloscope: Since most audio cards record from 20Hz to 20kHz, how does your SoundCard pickup the 433MHz signal? Wouldn't 433MHz be 433000kHz, well over the limit of the soundcard?

    Thanks for the awesome resources!

    1. Hi Chris, I was using a Velleman receiver to pick up the 433MHz radio waves from the PiMote transmitter, which then demodulates (or filters) the signal to retrieve the much lower frequency data stream that contains the on/off series of pulses. It's just like your car radio tuning into the FM band (around 100MHz) and recovering the low frequency audio stream (e.g. music) transmitted by the radio station.
      If you type "amplitude modulation" into Wikipedia, there is an animated illustration of AM & FM that may help you visualise how this works.
      Fortunately the data stream from the demodulated PiMote signal is a low enough frequency to allow my sound card to amplify and display it.
      I hope this helps, but let me know if you need further clarification.