La Crosse wireless format

[Guest]

hi everyone,

Has anyone decoded the temperature data that is transmitted via a LaCrosse wireless thermometer? the unit transmits on 433Mhz and I believe I have the data stream captured with a 18F2455 but now I want to tray and decode the temperature. The first 17 bits appear to be an ID since they never appear to change. I then get 27 bits that do change with temp but I'm not sure what to compare them to, deg C, deg F, Kelvin ??? I guess it's possible that a lookup table entry could be transmitted but it appears to be real data.

Here's an example of what the display on the receiver shows with a captured stream:
000101011001011101011001010

Any help would be appreciated as I'm working on a home projct to make use of this temperature information.

Thanks in advance

Dan

[dan king]

Sorry the last post was mine, I forgot to log in. Also, the example temperature was 37.8 degrees F for the data stream shown.

Thanks

[Ttelmah]

I'd not be at all surprised if somebody on the web hadn't cracked this already.
However if you can't find the format, you would need to get some more data.
I'd suggest first of all trying with an accurate thermometer, and seeing if you can work out what the _smallest_ temperature change is, which produces a change in the format. This will then give you a rough idea of the step size being used. A second point several degrees away, will then make it much more likely that we can crack the code used.

Best Wishes

[dan king]

I've been tabulating the results the best I can, I do have the advantage of being able to read the LCD display of the receiver for the temp it's receiving from the transmitter. The problem is, I can see the format change as temperature changes but the receiver appears to average ~ 4 to 5 readings before the display changes so the best I have been able to achieve is to wait for a stable temperature and wait for the readings to match for 4 to five times in a row and assume the display matches the TX. The data I posted in the original post does just that for 37.8 degrees F.

Any other suggestions are most welcome.

Thanks, Dan

[Ttelmah]

Forget about the display.
It is the stream, that you want to decode.
I'm assuming you can monitor the stream, and setup a temperature source so you have a _stable_ reading from the stream. Then you want a record of your source temperature, and the stream reading. Then you need to adjust the temperature really slowly till you see the _stream_ change (not the display). This then gives the smallest step size in the stream data, and which bit of the stream is the LSb. Then repeat this for another set of temperatures several degrees away.
The point is that the stream almost certainly will be in something like perhaps 1/10th degree C steps, but the step size could be anything, and the origin, might well be absolute zero, or some abitrary figure. As such the stream will have little relationship to degrees F. Their display unit will be doing the conversion, smoothing, and rounding. This makes what they 'display', almost useless as a decode reference.
When doing something like this, you always want to choose the point with the _least_ decoding present (the stream itself, rather than what is displayed), and find multiple reference steps.

Best Wishes

[libor]

Just two additional thoughts to the problem.

1. Don't forget that you can simulate any temperature for the testing if you replace the sensor (depending on operating principle of the sensor) with a very fine variable resistor, or a voltage divider.

2. Just in case you can't cope with the reverse-engineering of the coding scheme, just before giving-up, there's a brute force approach: you can record all the possible combinations lets' say from -20 to 60 C (with 0.1 resolution, that's 800 value pairs only) and build a lookup table (stripping off the permanent part of the stream of course) to find the according temperature value.

[dan king]

Hi,

Ttelmah, good point about not using the display reading. I was trying to cheat and it looks like it's not getting me anywhere. The tough part, for me, will be a variable stable temperature for reading the data stream. I like Libor's idea of hacking the sensor. I might try that approach if I can get an idea of the data-temp relationship for the part.

other than that, I might resort to a thermocouple along side the sensor and track changes that occur in the room.

Libor,

I was thinking a crude look-up table may be the brute force approach too. Looks like great minds think alike ;)

Thanks for the input,

Dan

[dan king]

Yippee !!! I figured out enough of the data stream to get temperature info out of the sensor. For anyone looking to do the same, the transmission is packetized into 11 nibbles and the temperature is BCD coded for each digit to represent degrees C, it even repeats a couple times. There are a lot if nibbles that I didn't use but I think they are for device ID, checksum, ..... For some reason there is an offset of ~50 degrees C that has to be subtracted before converting to F, not sure where that is coming from but the measurements match a thermometer I have been using for comparison through a wide swing of temperatures.

Thanks for everyone's input, now I'm off to use this info to make a "freezestat" that turns itself on only when the temperature in new england drops below 25 F. I'm using this to protect pipes from freezeing.

[PCM programmer]

You may be the first person to have done this. How about posting
a bit diagram or a table of the bit fields and their usage ? Post whether
the stream comes out MSB first or LSB first, etc. Post which parts
of the 34-bit stream are the ID, checksum, and other fields.

[dan king]

Sure but keep in mind I don't know what some of the fields are, to me they look like an ID but they may contain other information. From what I have determined:

format = 44 bits
IIII IIII IIII IIII IIII aaaa bbbb cccc aaaa bbbb xxxx

I = id bits?? maybe something more but never changes.
a = 1st temperature digit (deg C) BCD coded msb first and lsb last for all
b = 2nd temperature digit (deg C) BCD coded
c = tenth's decimal place of temperature (deg C) BCD coded
x = not sure, might be checksum but haven't figured the formula yet.

After the temperature is determined, subtract 50.0 and then you have degrees C to do with as you please.

and remember, the 44 bits are transmitted twice separated by 26.8mS pause and this repeats every 40 or so seconds.

I have the data stream specifics too as far as what is received via 433Mhz but I don't have a graphics program to illustrate the signals. They're easy to figure though. pulse width for a 1 is 500 microseconds and a 0 is 1.24 milliseconds. The low time between pulses is 1.24 milliseconds.

Rgds,

dan

[Ttelmah]

Very well done.
I'd suspect that some of the 'header', is saying what the device 'is', remember that they do a lot of different sensors.
I'd also suspect the fifth 'IIII' section might well be another digit, otherwise there coud be a problem at 999 counts (49.9C).
Obviously the '50' offset, allows them to handle most likely temperatures, without dealing wth -ve numbers. I felt it was quite likely that the number would be in fraction of a degree 'steps' like this from an origin, but was perhaps expecting either.

Best Wishes

[crj]

[dan king]

Hi Chris,

I didn't touch the LaCrosse Hardware. I used a separate 433Mhz receiver module I purchased off of Sparkfun.com. I used their lower baud rate receiver so I could modify the op-amp on it to reduce noise while there wasn't any data transmitting.

Let me know if you have any other questions.
Rgds,


Dan