Reverse-Engineering an unknown signal (BIOS Weather temperature sensor)

Introduction

I have recently come across this fun little radio device that shows the temperature inside and outside the house using an outside sensor that communicates with the indoors monitor. Apart from reading the temperature, the obvious thing to do was tearing it apart to play with its guts!

A BIOS Weather temperature sensor with its monitor unit

Tools

Any software-defined radio. I'll use my HackRF

Getting the signal

Using the trusty HackRF, we fire up GQRX to find our signal. Intuitively, the 433MHz ISM band is a favorite for those kinds of gadgets so lets start there...

 As soon as we hit the TX button on the sensor, a huge spike at 433.878 tells us we were right. The single-spike stuttering signal also gives us a good hint that this may be ASK modulation. Demodulating through GnuRadio (a simple Complex to Mag block) to get a WAV file and looking at it in Audacity confirms our intuition that the bits are encoded inside the pulses:

Nicely defined binary signal after AM demodulation

Zooming out in our Audacity file, we can learn a few things: there seems to be a start bit at the beginning of the transmission, and each transmission is made of 7 data packets

Packet bursts

Figuring out the encoding

Now that we have successfully retrieved a workable signal, we can start to examine packets. By zooming into a single packet in Audacity, we can glean more information on the modulation type used to encode the data. Pulses are always equal in length so we can immediately reject PWM as a potential encoding scheme. Furthermore, there appears to be only 2 lengths of gaps between pulses, and that's the key to figuring out the decoding scheme: the information is encoded in the relative timing of the pulses, a technique called Pulse-Position Modulation (PPM). It is commonly used in household electronics such a IR remote controls, RC toys, and most notoriously, for Mode-S aircraft identification signals at 1090MHz.

Pulse-position modulation (PPM)

Decoding the signal

With the signal and the modulation technique in hand, it's now straightforward to recover the information from the signal and start playing with bits. Now, we don't know yet which gap length is ZERO and which one is ONE, but we can proceed to decode and flip values if we don't get anywhere. The last bit might not be a zero since the receiver needs a final pulse to decode the last bit.

Two potential decodings

Breaking the code

We now have a bit string that contains the information going from the weather sensor to the monitor.
 

0110101111111011111100010001001100111(0)

or

1001010000000100000011101110110011000(1)

But how do we figure out how the device uses this information? There's a ton of ways...but before we hit it with complex methods, let's try to see if we can grab some low hanging fruit with some basic hypotheses:

1) Devices would need some sort of serial/device ID to be transmitted in order to sort out where the signal is coming from, otherwise similar devices might interfere with one another. Therefore we can assume that somewhere in there is a device ID that the monitor is looking for in order to exclude spurious/third-party signals.

2) The sensor sends temperature data, which is a floating-point value, with the monitor displaying 22.6 at the time of the signal capture. Since there are not enough bits in a radio packet to carry an IEEE 754 standard floating-point value (32bits and up) in addition to a device ID, it may be that our sensor is simple sending the 3 temperature digits as binary-coded decimal (BCD).

To try out the second hypothesis, lets's translate our value to hexadecimal, dropping the last bit:

0110101111111011111100010001001100111 = 0xD7F7E2267

And there we have it. Our temperature value is simply 3 BCD-coded characters in the last 4 nibbles of the packet. The last nibble (7) may be an extra digit that is not displayed, or a CRC, or anything...we don't know yet...The point is, even without resorting to more complex analysis methods such as correlation analysis or others, we can sometimes find the data that we need with simple methods. For example, if we simply wanted to intercept the sensor signal to feed a webpage with the current temperature online, this would be enough. 

But for our curious minds, it is definitely not....in a latter article, we'll dig deeper in order to get this device to bend to our will...Stay tuned for part 2 !