Electronic – arduino – Reverse-engineering RF packets

arduinoradioreverse-engineeringRF

I have a Blue Line Innovations PowerCost Monitor. It sends packets to a display unit over a 433.92 MHz RF link. There is code (Power Monitor, incomplete) to detect these packets with a RF Link 4800bps Receiver and an Arduino.

I'm definitely getting something from the transmitter, but the packets don't seem to make sense. How might one go about systematically decoding data from a device like this?

(Update/Aside 2014-07: A github user has completely decoded the protocol, and forked the rtl_433 package for SDR dongles to read it: radredgreen/rtl_433.)

(Update/Aside 2014-08: Another github user has implemented this on Arduino: CapnBry/Powermon433)

Best Answer

So the issue you're probably running into there is that unlicensed radio spectrum is noisy. There's lots of stuff which transmits there, especially cheap wireless electronics like wireless doorbell ringers, wireless LED controllers, and this "power cost" monitor you're looking at. Are you sure you're not just swamped in noise? The receiver you linked to automatically scales so that noise will look like a signal. What comes out when the power monitor isn't connected? If it still looks like the same gibberish you've been getting, there's your problem.

You'll notice the massive number of complaints under that receiver from people who say "I can't get it to connect!" or "it gives garbage data!" and a whole bunch more giving advice on how to fix it. Likely the device you're trying to read has devised a similar scheme to properly encode its data.


For actually trying to "reverse engineer" the protocol, this is normally boring and slow but methodical and logical.

Start by simply taking the receiver you have and hooking it up to something like an oscilloscope in one shot mode and then hook up the receiver that came with your monitor. Then when the encoded packet comes from the cost monitor, save the waveform from your oscilloscope and what it corresponded to from the software output. Then when the next packet comes through, compare what changed in the waveform to what data you received. Slowly, you should be able to figure out what's going on.

In general, the reason you don't see too many amateur reverse engineering jobs is because there's a lot of intuition involved with reverse engineering these things. For example: you'll probably see that even with a single change in data (i.e. a new packet comes with only a change in temperature by 1 degree) there may be multiple changes in the packet. This could be from a checksum packet, but how was it formed? Is it a CRC16? Or simply a sum of all the bits in the packet?

A tool which might help would be a cheap logic analyzer.

Good luck! I hope that helps.