La Crosse TX7U Temp/Humidity Sensor

[merbanan]

La Crosse TX7U Temp/Humidity Sensor

[mnhauke]

On 11.08.2013 21:40, Michael Sabino wrote:

Here is an example frame I was able to capture with my radio shack scanner antenna and "rtl_433 -a -l 800":
[00] {44} f5 f6 88 87 88 10 : 11110101 11110110 10001000 10000111 10001000 00010000

As I understand it (according to http://forum.arduino.cc/index.php?topic=155483.0), this breaks down as follows:

|11110101 1111|0110 100|0|1000| 1000|0111| ... this I don't know: 10001000 00010000
| MODEL ID |SENSORID|P|TENS|ONES|TENTHS|
Where the TENS position is subtracted from ten, and the ones and tenths position are subtracted from 15 to yield the actual values at those positions.
so, 10-TENS = X * 10^1
15 - ONES = X * 10^0
15 - TENTHS = X * 10^-1

That's for the temperature. As for the humidity, I am also getting two frames in sequence per cycle that look like this:

11110101 00010110 1000|1010 _1110_1111 10101110 10110000

with a different model Id, but sent very shortly after the first two frames that have the 11110101 1111 in the header portion that contain valid temperatures. The humidity ones place is starred (subtract from 15).

I've written a few scripts, that when run simultaneously, report the temperature and humidity, but, I am not sure about the TENS place in the humidity, and at least 2 times in the cycle, an unusual alternating temperature (1111) and humidity (0001) frame appears, but with invalid humidity data.

I may be receiving data from two different sensors. I am not sure.

Hi Michael,

it looks like the generic Lacrosse protocol used by other sensors from
this company.
A good reference describing the protocol can be found here:
http://www.f6fbb.org/domo/sensors/tx3_th.php

First you have to invert the bits...

Thermo:
11110101 11110110 10001000 10000111 10001000 00010000 // your capture
00001010 00001001 01110111 01111000 01110111 11101111 // inverted
0 1 2 3 4 5 6 7 8 9 10 11 // nibble
-7- -7- -8- -7- -7- // measure

27.8°C <<<

Hygro:
11110101 00010110 10001010 11101111 10101110 10110000 // your capture
00001010 11101001 01110101 00010000 01010001 01001111 // inverted
0 1 2 3 4 5 6 7 8 9 10 11 // nibble
-5- -1- // measure

51 %rH <<<

---

0 = Preamble
1 = Data length (number of nibbles)
2 = Type (0 = Thermo, E=Hygro)
3 = SensorID_0 (bit 1-4)
4 = SensorID_1 (bit 1-3), bit4 unknown
5-9 = Measure (temperature in tenths degrees BCD +50 degrees)
The measure is on 3 BCD digits, the two first digits
are repeated to fill the 5 nibles.
10 = Checksum

11 = Unknown

best regards,
Martin Hauke

[mnhauke]

email to github was no good idea...
The data is totally mixed up.

Use the following link...
http://pastebin.com/YDLWfbra

best regards,
Martin Hauke

[rct]

Anyone have a version of rtl_433 that handles the LaCrosse sensors yet? Looks like issue #24, by GiddyHup also is asking for the same thing, with a different bash script for parsing the output.

[toke]

It looks like I have a sensor in my neighbourhood. I'll look into that.

[rct]

I'm trying to get LaCrosse sensors implemented, but I can't figure out how to get the same bits in the debug call back that -a shows. The -a output correctly detects the bits (other than the fact that they are inverted).

The -a output:

*** signal_start = 5026155, signal_end = 5099864
signal_len = 73709,  pulses = 88
Iteration 1. t: 233    min: 133 (26)    max: 334 (62)    delta 20
Iteration 2. t: 233    min: 133 (26)    max: 334 (62)    delta 0
Pulse coding: Short pulse length 133 - Long pulse length 334

Short distance: 256, long distance: 259, packet distance: 7172

p_limit: 233

[00] {44} f5 ff 38 fd 8f 90 : 11110101 11111111 00111000 11111101 10001111 10010000
[01] {44} f5 ff 38 fd 8f 90 : 11110101 11111111 00111000 11111101 10001111 10010000

*** signal_start = 5141066, signal_end = 5213111
signal_len = 72045,  pulses = 88
Iteration 1. t: 234    min: 134 (34)    max: 334 (54)    delta 32
Iteration 2. t: 234    min: 134 (34)    max: 334 (54)    delta 0
Pulse coding: Short pulse length 134 - Long pulse length 334

Short distance: 256, long distance: 259, packet distance: 7112

p_limit: 234

[00] {44} f5 1f 3d 8f d8 90 : 11110101 00011111 00111101 10001111 11011000 10010000
[01] {44} f5 1f 3d 8f d8 90 : 11110101 00011111 00111101 10001111 11011000 10010000

The above corresponds to:
Sensor 06: Temperature 68.4 F, ( 20.2 C)
Sensor 06: Humidity 27.0% (27%)

What I'm getting with the debug call back is:

[00] 14 0c 2e 0c e0 a0 00 00 00  ...
[01] 14 0c 2e 0c e0 a0 00 00 00  ...
[snip]
[00] 15 cc 24 c0 4d e0 00 00 00  ...
[01] 15 cc 24 c0 4d e0 00 00 00  ...

Here is what I'm currently using for the r_device definitions:

r_device lacrosstx7u = {
    /* .id             = */ 11,
    /* .name           = */ "LaCrosse TX7U Temperature and Humidity Sensor",
    /* .modulation     = */ OOK_PWM_P,
    /* .short_limit    = */ 238,
    /* .long_limit     = */ 1500,
    /* .reset_limit    = */ 20000,
    /* .json_callback  = */ &debug_callback,
};

I've tried other values for the limits, but can't seem to get the same bits that -a shows. What am I missing?

Thanks for any help you can provide.

[rct]

Here's a better view of the differences I'm getting in bits between the -a output (a) and the debug call back (d). The -a output (top line) is correct. The debug (second line) call back isn't. I feel like I must be missing something obvious.

a: [00] f5 f9 f8 f7 8f 90 : 11110101 11111001 11111000 11110111 10001111 10010000
d: [00] 14 0c 0e 0e e0 a0 : 00010100 00001100 00001110 00001110 11100000 10100000


a: [00] f5 19 ec ef ce 80 : 11110101 00011001 11101100 11101111 11001110 10000000
d: [00] 15 cc 26 20 62 e0 : 00010101 11001100 00100110 00100000 01100010 11100000

[rct]

Ok, I've made some progress. There are two key differences in what pwm_p_decode (the pulse width encodes the bits) and what pwm_analyze (-a) outputs.

1. pwm_p_decode() is ignoring the first bit as a start bit, it doesn't get added to the packet.
2. The bit values are inverted between pwm_analyze (-a) and pwm_p_decode().

Looking through some of the issues, I think others have been tripped up by this. I might create a separate issue to make this clear to anyone else who stumbles on this.

Note: for LaCrosse, pwm_p_decode() the bits are the correct values, long pulses are zeros, and short pulses are ones, it's pwm_analyze (-a) that uses the opposite, which confused me because I thought I would be seeing the same as what pwm_analyze was outputting in -a mode.

Look at what I posted above (a == -a pwm_analyze output, d = pwm_p_decode, c = corrected by inserting the start bit and shifting

 a: 11110101 11111001 11111000 11110111 10001111 10010000
 d: 00010100 00001100 00001110 00001110 11100000 10100000
c1: 00001010 00000110 00000111 00000111 01110000 01010000 0  (add bit)
c2: 11110101 11111001 11111000 11111000 10001111 10100xxxx  (add bit)

So, now I can get access to the data I need to decode if I insert a bit (assuming the start bit was discarded by pwm_p_decode().

There probably should be way to indicate to the decoders whether there is a start bit to discard or not. Knowing that it was there are the timings would be useful in determining whether one has the right packet or not.

[Batilan]

Did you have a look at issue #42, @zerog2k might be able to assist.

[rct]

I've described the bug in pwm_p_decode (OOK_PWM_P) in issue #67.

Because of the bug, I had to use 238, 1500, 8000 for short, long, and reset limits. After fixing that bug, I'm able to use 238, 750, and 8000, which are much closer to the actual periods for the short and long pulses. (Those numbers are sample counts using a 250 Khz sample rate that rtl_433 requires for the protocol definition.)