# Reverse-engineering RF packets

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)

• note that the PowerCost Monitor is identical to the Black & Decker unit mentioned. – scruss Nov 17 '12 at 20:08

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.

This is a partial answer, as I still haven't yet decoded the packets, but have learned a lot about how simple RF boards work in the last year.

While Kit Scuzz's comment about logic analyzers is helpful, they might be less so here:

1. The 433.92 MHz receivers apply AGC to the input signal, amplifying it so that the board will output a high every few milliseconds. This would make setting a trigger on a logic analyzer very difficult.
2. The packets come in about every 32 seconds. No logic analyzer I can afford can capture such long gaps between packets.

The tool I've found most useful is Protocol Analyzer. It uses your soundcard as a single channel, slow(ish) data capture device. It has some limitations (accuracy is limited by the soundcard's roughly 22 µs minimum sample width) and some annoying bugs, but it's usable as is.

I wish I'd known more about Manchester encoding when I was starting out. The Atmel Application Note “Manchester Coding Basics” is quite helpful. It was also really instructive to be able to buy another power meter and take it apart, as then I could take signals directly from the transmitter's µc pins.

• If the packets are 4800bps, you absolutely can afford a logic analyser that can capture continuously basically forever: An Arduino! It should be possible to sample the pin state at > 10 Khz and stream it over the serial link without even having to do too much optimization. Alternatively, the \$150 Saleae logic can basically sample forever at 24 MSPS (or until your PC runs out of ram, in any event). – Connor Wolf Aug 20 '14 at 2:19
• If you 1. just read the pins directly (e.g. no digitalRead() crap), and 2. pack 8 samples into each serial byte, sampling at 10 khz shouldn't be hard. You might want to trigger your sampling off an interupt, to get deterministic timing, though. – Connor Wolf Aug 20 '14 at 2:20