Help with decoding 433 MHz temperature sensor data

[0-8-15 User]

I'm currently trying to decode the radio signal of a 23 year old outdoor temperature sensor. The RF signal looks like this:



My current guess for the line code used is Biphase Mark Code (BMC), could that be correct?

Any help would be appreciated.

[floobydust]

The easy way is to take an RTL-SDR and add on rtl_433 decoder software which supports 152 protocols. It's open-source.
The extra money for the SDR pays for itself in time saved decoding the protocol, which may have already been conquered.
You could take a snapshot of your signal, save the datastream and then load into rtl_433 to try decode.

[0-8-15 User]

I have already searched the various device definitions of the rtl_433 program for a matching protocol, but so far without success.

In the appendix you will find some successively recorded data frames (presumably containing ascending temperature values). The bits in the blue shaded areas never seem to change.

Here are the raw bit strings from those recordings:

Code: [Select]

11010 00111001 00111111 11001110
11010 11111001 00111111 01011110
11010 01011001 00111111 10101110
11010 11001001 00111111 01101110
11010 00001001 00111111 11100110

[cdev]

There seem to be some newish tools to help decode unknown sensors at https://triq.org/

HTH
 

[RoGeorge]

tools to help decode unknown sensors at https://triq.org/

"The server at triq.org is taking too long to respond."   



Might help guessing the encoding:  Improvise a thermal chamber and slowly raise or decrease the temperature in order to get consecutive codes. 

If you have both the transmitter and the receiver, you can try faking the sensor and read the temperature indicated by the receiver.  In case you didn't find the encoding, at least you'll have a lookup table with al the codes.

I did something similar for a sports wrist watch that was displaying the heart beat rate:  simulated the heart electrical signal, then vary it, then build a fake transmitter, then receive the codes, then take an automated picture and process it with OpenCV in order to tell if the received signal was a valid combination of bits, or not.

Had a lot of fun with that project, in the end got a full lookup table with all the codes, many people chipped in, even found some bugs in the decoder, but I still don't know what encoding scheme was that!   
https://rogeorge.wordpress.com/2016/08/13/the-wireless-protocol-of-a-sports-wrist-watch/
https://rogeorge.wordpress.com/2017/02/16/the-wireless-protocol-of-a-sports-wrist-watch-part-2/
https://rogeorge.wordpress.com/2017/03/29/the-wireless-protocol-of-a-sports-wrist-watch-part-3/

[radioactive]

I have already searched the various device definitions of the rtl_433 program for a matching protocol, but so far without success.

In the appendix you will find some successively recorded data frames (presumably containing ascending temperature values). The bits in the blue shaded areas never seem to change.

Here are the raw bit strings from those recordings:

Code: [Select]

11010 00111001 00111111 11001110
11010 11111001 00111111 01011110
11010 01011001 00111111 10101110
11010 11001001 00111111 01101110
11010 00001001 00111111 11100110

Before your edits,  I think you mentioned before that the temperatures should all be somewhere around 11C?  If that is correct,  I noticed a possible pattern close to that.  Try taking the last 8-bits from those strings and reverse them so that the last bit is msb or (bit7),  then I think you get the following
0x7a = 122
0x73 = 115
0x75 = 117
0x76 = 118
0x67 = 103

Divide the decimal representation by 10,  then you would get 12.2,  11.5, 11.7, 11.8, 10.3

[floobydust]

I connect a variable resistor in place of the thermistor and dial in a fixed temperature. You can look for the sign bit i.e. try -20.0C and +20.0C as well, and open sensor or low battery, as some bits might be error flags. I would expect a simple CRC but at 23 years old, the MCU F/W might be really basic due to small memory.

I blew up one transmitter running it from larger AA batteries (not CR2032 coin cell) because the dV/dt was too fast and the COB IC latched up and cooked. Add a 47R series resistor if you are powering off a bench supply or bigger battery.

[0-8-15 User]

@RoGeorge, great project and great ideas, thanks! I love the lookup table approach, I would have never thought of doing it that way.

@radioactive, I tried that already (both with the first and the last few bits), but without success. So I started to wonder if the signal is really BMC encoded.

@floobydust, that does indeed sound like the most straightforward way to go. I think I should try that if I can't figure out the encoding by pure guessing.

Given the age I also expect a pretty simple logic. Maybe a sign bit, at least 10 temperature bits (with a scale of 10) and a checksum.

[Syntax Error]

That data stream seems 'ball park' with the Oregon Scientific weather station sensor protocol. A link on this page to a pdf describing the 1.0 2.1 3.0 protocols. May give an insight how the bits are assigned. Happy hacking

https://buildthings.wordpress.com/arduino-intercepting-oregon-scientific-weather-station-anemometer-wind-vane-temperature-humidity-barometer-rain-gauge-data/

[radioactive]

I took a look at some code I worked on for a friend to reverse engineer several different models of Accu-rite Temp/RH sensors back 8 years ago, so quite a bit newer than yours.  I lost the actual sample waveforms, but looking at notes and code and from what I can recall,  I think you might want to try to demodulate the OOK differently.  Try not really paying much respect to the off time, but the on time only,  I took your first graphic and marked it up how I think you might want to try decoding.  This method also worked for several other manufacturers of 433 MHz devices from what I recall.  Anyway, might be worth looking at.  The waveforms you posted look very similar to those Accurite sensors I played around with from what I remember.

[0-8-15 User]

@Syntax Error, you made my day! I don't think I would have had any success anytime soon without the help of this protocol description.

a) The pulse length variation tricked me into believing Biphase Mark Code was used, although Manchester as per G. E. Thomas was used.
b) The temperature is not scaled by a factor of 10, but is instead transmitted as a binary coded decimal number.

Code: [Select]

0010 0110 0001 0010 0001 0000 0100 1000 
0x2  0x6  0x1  0x2  0x1  0x0  0x4  0x8  
---------------------------------------
0010 0110 0000 0010 0001 0000 0011 1000 
0x2  0x6  0x0  0x2  0x1  0x0  0x3  0x8  
---------------------------------------
0010 0110 0011 0010 0001 0000 0110 1000 
0x2  0x6  0x3  0x2  0x1  0x0  0x6  0x8  
---------------------------------------
0010 0110 0100 0010 0001 0000 0111 1000 
0x2  0x6  0x4  0x2  0x1  0x0  0x7  0x8  
---------------------------------------
0010 0110 0101 0010 0001 0000 1000 1000 
0x2  0x6  0x5  0x2  0x1  0x0  0x8  0x8