Advice for analyzing and adding a Lacrosse TX59UN-1-IT weather station decoder?

[Clint Fisher]

Hello everyone,
I'm new to the group and new to RTL_433, but I'm learning quite a bit as I go.  

I have a Lacrosse weather station that uses a TX59UN-1-IT temp/humidity sensor which also serves as a relay for the rain gauge and wind-speed/direction sensors.

I am embarking on a journey to create a rtl_433 decoder for this unit...

So far, I have found that it transmits on 903.000MHz, and am currently capturing .cu8 files which look to be fairly consistent in size, except for when looks to be relaying info from the other sensors, and then those are fairly consistent in size too.

I'm at the point where I'm going to start loading the cu8 files up into PulseView to have a look and see if I can group the data fields.

If any of you have time to give advice, direction, or pointers to the general workflow, how-to guides etc, or helpful threads here or elsewhere, I'd be most appreciative.

It would be nice to add this to the pool of available decoders.

[Christian Zuckschwerdt]

903M sounds odd. I would rather guess 915M. Is 903M even an unregulated frequency in your country?

Open an issue at https://github.com/merbanan/rtl_433/issues to get this going. Look into other recent issues to get a feel what's needed.

[Clint Fisher]

On Thursday, January 30, 2020 at 1:19:25 AM UTC-8, Christian Zuckschwerdt wrote:

903M sounds odd. I would rather guess 915M. Is 903M even an unregulated frequency in your country?

Open an issue at https://github.com/merbanan/rtl_433/issues to get this going. Look into other recent issues to get a feel what's needed.

903.000M is what it's transmitting at, as verified by very clear signals received by SDR#.   I assume that it's in the 915M "range".   The FCC filings for the transmitter specify 905M even though the label on the back says 915M.   Also, the rain-gauge and or wind-sensor seem to transmit around 906M but I'm less interested in those because the temp/humidity sensor also relays those back to the base station.

[Clint Fisher]

For anyone else wondering about this, I found an excellent and comprehensive guide on the Wiki:

https://github.com/merbanan/rtl_433/wiki/digitech_xc0324.README

[Christian Zuckschwerdt]

In Europe the bands are quite narrow, e.g. 433 MHz ISM band is 433.05–434.79 MHz, the 868 SRD band has more room 863–870 MHz.
The American ISM band however is really wide 902–928 MHz -- didn't know that.

[Tolip Wen]

I have no idea if my method is typical, I'm still hunting for some info for the things I can't reproduce inside my house like wind at a known velocity.

My method got me as far as my post here regarding the EcoWitt WS68 Anemometer without asking any questions.

The best link to view my post is @ github issue 1283 linked below my crude method requires a fixed font to display correctly.

https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmerbanan%2Frtl_433%2Fissues%2F1283&sa=D&sntz=1&usg=AFQjCNG6_CmInObuaAJnF7nEBvzCH9bh4g

What model Lacrosse weather station uses a TX59UN-1-IT for input?

Do you already have a working flex decoder?

If not you could take a guess based on other Lacrosse devices.

I'm assuming a linux environment BTW

I have my source stored in /usr/src/rtl_433

If I enter the command

tail /usr/src/rtl_433/src/devices/lacross*.c

I get hints on how to reuse existing Lacrosse decoders as general purpose flex decoders.

There might be more examples in those files, I just looked at the last 10 lines of each file with 'tail'.

./rtl_433 -X

will show helpful details on how a flex decoder is described to rtl_433

I end up with the following after I changed the names and removed the quotes and spaces and slashes etc. The -X command needs quotes and I don't put quotes in strings with quotes around them.

-X "name=NOT_LaCrosse_TX_Temp_Hum_Sensor,m=OOK_PWM,s=550,l=1400,g=3000,r=8000,s=0"
-X "name=NOT_LaCrosse_TX141-Bv2_TX141TH-Bv2_TX141-Bv3_TX141W_TX145wsdth_sensor,m=OOK_PWM,s=208,l=417,sync=833,g=625,r=1700"
-X "name=NOT_LaCrosse_TX35DTH-IT_TFA_Dostmann_30.3155_Temperature_Humidity_sensor,m=FSK_PWM,s=105,l=105,r=4000"
-X "name=NOT_LaCrosse_ELV_Conrad_WS7000_WS2500_weather_sensors,m=OOK_PWM,s=400,l=800,r=1100"
-X "name=NOT_LaCrosse_WS-2310_WS-3600_Weather_Station,m=OOK_PWM,s=368,l=1464,r=8000"

The modulators names have been shortened so I removed the word "PULSE" from the modulators.

then run

rtl-433 -f 903e6 -R 0 -X "name=NOT_LaCrosse_TX_Temp_Hum_Sensor,m=OOK_PWM,s=550,l=1400,g=3000,r=8000,s=0"

and see what shows up

You can put them all on one command line but it is a nightmere if you use the up arrow to edit and rerun commands.

So I create a shell script that contains

#!/bin/bash

rtl_433\

 -d 0\

 -f 903e6\

 -R 0\

 -A\

 -X "name=NOT_LaCrosse_TX_Temp_Hum_Sensor,m=OOK_PWM,s=550,l=1400,g=3000,r=8000,s=0"\

 -X "name=NOT_LaCrosse_TX141-Bv2_TX141TH-Bv2_TX141-Bv3_TX141W_TX145wsdth_sensor,m=OOK_PWM,s=208,l=417,y=833,g=625,r=1700"\
 -X "name=NOT_LaCrosse_TX35DTH-IT_TFA_Dostmann_30.3155_Temperature_Humidity_sensor,m=FSK_PWM,s=105,l=105,r=4000"\
 -X "name=NOT_LaCrosse_ELV_Conrad_WS7000_WS2500_weather_sensors,m=OOK_PWM,s=400,l=800,r=1100"\
 -X "name=NOT_LaCrosse_WS-2310_WS-3600_Weather_Station,m=OOK_PWM,s=368,l=1464,r=8000"

name it something like 'lacross_test_command_line'

 Every line but the first TWO lines starts with a space (the rtl_433 line can have one too)

Every line but the first and last ends in a backslash\

You might need gain and sample rate too.

I had to use low gain with the tx and rx in the same room.

then run it with

source lacross_test_command_line

or

chmod 777 lacross_test_command_line

then run with

./lacross_test_command_line

You can use backslashes while typing in the command line too for clarity but then using the up arrow for rerunning commands gets funky

If you look at the issue I just opened linked below you can see what data I gathered before I posted anything. It speeds the process and helps motivate those on whom we depend on to add it in. I did not capture any .cu8 files at all until I knew what would be in them.

https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmerbanan%2Frtl_433%2Fissues%2F1283&sa=D&sntz=1&usg=AFQjCNG6_CmInObuaAJnF7nEBvzCH9bh4g

Then you can see the old skool way and how Christian does it faster with Bitbench if you follow his link in the thread.

I found a working flex decoder that way, loooooong before I fully understood flex decoders.

I got lots of devices around me @ 915 and I was challenged identifying the ones of interest.

I knew the timing of TX from the device so I hunted the timestamps for the correct interval.

Once I got rtl_433 to output the hex digits I needed, I started changing things in the sensor environment in a predictable way and looking for changes in the hex string. Then I switched to binary because some nibbles are multi purpose.

In my issue post I go into some details about saving everything in a file and different ways of querying the file for different items.

I'm a newb too in this whole RX flex decoding thing but I have hunted for bits before.

Hope this helps.

[Clint Fisher]

Thank you Tolip!   While I haven't yet decoded this, I feel like I'm getting closer thanks to your help...
My tactic now is to take a known good .cu8 file and run differently-configured flex decoders past it.
I also loaded the same .cu8 file in Audacity and converted the IQ to AM & FM.  In the AM output, I see very clear bit pulses and blanks.  Each pulse, either a one or zero is 27.5uS long.   The problem is that there doesn't seem to be any variable width to the pulses, so OOK_PWM gives me garbage.
Essentially, the Audacity AM output is solid high before the start of the data, and then the pulse train starts with some high and low pulses.  Then there is a 13.5mS long train of high pulses that looks to be a preamble, followed by what looks like data, and then followed by solid high after the pulse trains.

The problem is that, though the data looks clear to my eyes in Audacity, I cannot get a decoder to give me a representation of what I see.  Tried most modulation options and no luck. 

Is there an OOK modulation scheme where the pulses are fixed-width and either high or low represents the bits?

[Christian Zuckschwerdt]

Is there an OOK modulation scheme where the pulses are fixed-width and either high or low represents the bits?

That's called PCM in rtl_433. Fixed bit rate and the level determines if 0 or 1. I just updated the demod to lock onto the actual bit rate, so you should be fine to just ballpark it. The 27µs sounds right.

 

[Clint Fisher]

Thank you Christian!
I'm seeing more consistent and realistic looking data blocks now. 
Here is a flex decoder and typical looking output.  Note the number of pulses (199) vs len (655) I think the 000's and ffff's might be the capture buffers, but the meaningful-looking data in the middle kind of resembles the waves I've seen.

I'm still very new to this. :)

 rtl_433 -f 903M -R 0 -A -S all -X "name=CEF_TX4,m=OOK_PCM,s=27,l=27,r=13000,g=30,y=3500,invert"

Detected OOK package    2020-02-04 20:19:23
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2020-02-04 20:19:23
model     : CEF_TX4      count     : 1             num_rows  : 1             rows      :
len       : 655          data      : 04000000000000000000000000000000000060c18164e2189400000000701c01cc001f07fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe
codes     : {655}04000000000000000000000000000000000060c18164e2189400000000701c01cc001f07fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe
Analyzing pulses...
Total count:  198,  width: 7.92 ms              ( 7915 S)
Pulse width distribution:
 [ 0] count:   11,  width:   71 us [67;82]      (  71 S)
 [ 1] count:   35,  width:   42 us [40;45]      (  42 S)
 [ 2] count:  128,  width:   15 us [13;17]      (  15 S)
 [ 3] count:    2,  width:  195 us [180;210]    ( 195 S)
 [ 4] count:    3,  width:  142 us [122;152]    ( 142 S)
 [ 5] count:   18,  width:   11 us [10;12]      (  11 S)
 [ 6] count:    1,  width:   97 us [97;97]      (  97 S)
Gap width distribution:
 [ 0] count:  129,  width:   11 us [11;14]      (  11 S)
 [ 1] count:   68,  width:   14 us [14;17]      (  14 S)
Pulse period distribution:
 [ 0] count:   11,  width:   84 us [82;94]      (  84 S)
 [ 1] count:   35,  width:   55 us [55;57]      (  55 S)
 [ 2] count:  145,  width:   27 us [26;29]      (  27 S)
 [ 3] count:    2,  width:  210 us [196;225]    ( 210 S)
 [ 4] count:    3,  width:  157 us [139;167]    ( 157 S)
 [ 5] count:    1,  width:  112 us [112;112]    ( 112 S)
Level estimates [high, low]:   1555,     17
RSSI: -10.2 dB SNR: 19.6 dB Noise: -29.8 dB
Frequency offsets [F1, F2]:    1330,      0     (+20.3 kHz, +0.0 kHz)
Guessing modulation: No clue...

*** Saving signal to file g5969_903M_1000k.cu8 (50684 samples, 131072 bytes)
Detected OOK package    2020-02-04 20:21:20
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2020-02-04 20:21:20
model     : CEF_TX4      count     : 1             num_rows  : 1             rows      :
len       : 655          data      : 040000000000000000000000000000000000608181200618b400000000701e21c1001f07fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe
codes     : {655}040000000000000000000000000000000000608181200618b400000000701e21c1001f07fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe
Analyzing pulses...
Total count:  199,  width: 7.92 ms              ( 7915 S)
Pulse width distribution:
 [ 0] count:   11,  width:   70 us [67;81]      (  70 S)
 [ 1] count:   25,  width:   42 us [40;45]      (  42 S)
 [ 2] count:  136,  width:   15 us [13;17]      (  15 S)
 [ 3] count:    5,  width:  108 us [96;124]     ( 108 S)
 [ 4] count:    4,  width:  166 us [152;181]    ( 166 S)
 [ 5] count:   18,  width:   11 us [11;12]      (  11 S)
Gap width distribution:
 [ 0] count:  136,  width:   11 us [11;14]      (  11 S)
 [ 1] count:   62,  width:   15 us [14;17]      (  15 S)
Pulse period distribution:
 [ 0] count:   12,  width:   86 us [83;111]     (  86 S)
 [ 1] count:   25,  width:   55 us [54;57]      (  55 S)
 [ 2] count:  153,  width:   27 us [26;29]      (  27 S)
 [ 3] count:    4,  width:  182 us [167;197]    ( 182 S)
 [ 4] count:    4,  width:  125 us [111;140]    ( 125 S)
Level estimates [high, low]:   1527,     17
RSSI: -10.3 dB SNR: 19.5 dB Noise: -29.8 dB
Frequency offsets [F1, F2]:    1271,      0     (+19.4 kHz, +0.0 kHz)
Guessing modulation: No clue...

*** Saving signal to file g5972_903M_1000k.cu8 (50684 samples, 131072 bytes)

[Christian Zuckschwerdt]

Pulse width distribution:
 [ 0] count:   11,  width:   71 us [67;82]      (  71 S)
 [ 1] count:   35,  width:   42 us [40;45]      (  42 S)
 [ 2] count:  128,  width:   15 us [13;17]      (  15 S)
 [ 3] count:    2,  width:  195 us [180;210]    ( 195 S)
 [ 4] count:    3,  width:  142 us [122;152]    ( 142 S)
 [ 5] count:   18,  width:   11 us [10;12]      (  11 S)
 [ 6] count:    1,  width:   97 us [97;97]      (  97 S)
Gap width distribution:
 [ 0] count:  129,  width:   11 us [11;14]      (  11 S)
 [ 1] count:   68,  width:   14 us [14;17]      (  14 S)

 

That doesn't look right, why would there only be 1-bit wide gaps, never anything else? And why distinctly 11 µs and ~15 µs gaps/pulses? But no 27.5 µs pulses/gaps.

You should upload a sample here or post a screenshot from Sigrok Pulseview (btw. g5972 ? Wow you really saved many samples).

[Clint Fisher]

Thanks for the assistance Christian!   I won't have time to work on this for another couple days, but when I do, I will gather some of the best samples and post them.   I have a lot of samples for a couple reasons:  I left it running for a few days, and I also found out that simply jingling my car keys in my pocket or ruffling my coat creates enough RF interference to trigger a sample.  D'oh! 
In any case, I do appreciate the help and look forward to picking this back up in a few days.