Decoding the Lacrosse LTV-TH3 and LTV-WR1

[Clambino]

My father-in-law gave me the Lacrosse V40A-PROV2 which uses the LTV-TH3 and LTV-WR1 sensors and rtl_433 doesn't decode the data from these using the available protocols. I've been trying to follow the contrib suggestions but I'm so out of my element it's laughable. Where do I go from here? How can I help provide the info to develop a decoder?

[Tim Reimers KA4LFP]

Well, that could certainly explain MY other thread! 

I'd asked about decoding the LTV-R1 (maybe I mised the "w" in that model, I'm at work and can't check)

Let me try to find the 'how to help contrib' destructions and I'll see what sense I can make of that, and help us both.

I'm also not aware of there being a list of supported devices - but maybe there is, and I should have realized that my device wasn't on it...

[Clambino]

  I appreciate the help! Let me know what we need and I'll do whatever I can. I have data captures and can always generate more along with the analyzer info. 

[Michael Bruski]

The LTV-WR1 is a wind/rain sensor, probably similar to the LTV-WSDTH01 for which I wrote a decoder a few weeks ago.  The LTV-TH3 is a remote temp/humidity sensor.  Both probably use a similar signal/protocol to the WSDTH01.  If you could collect some signal samples I'd be willing to take a look at it.  Use 'rtl_433 -S unknown -f915M' from a terminal window in a temp directory where you want to collect the files.  Three or four minutes worth should be enough to get started.  Kind of tricky but watch the console for wind/temp/humidity updates just prior to rtl_433

dumping  a file and jot down a note about what value was displayed for each file dumped.   Also, look at the WR1 underside and see if it has a barcode and number on it.  That might show up in the bit stream somewhere.   LTV-TH3 might also have a barcode on it some where, not sure.  That barcode number showing up in the bitstream from my WSDTH01 along with humidity value was a BIG help figuring out the frame structure.

Same goes for the LTV-R1.  Console reading would be helpful there as well especially if it is raining.  Note that the R1 is a 'rain only' sensor.  I might be able to gleem some useful info from this device for when I buy a LTV-R3 to add to my station.

[Tim Reimers KA4LFP]

will do, thanks!!!

#####

How excellent, how honorable is man if he arises to fulfill his responsibilities; how wretched and contemptible, if he shuts his eyes to the welfare of society and wastes his precious life in pursuing his own selfish interests and personal advantages.
- Abdul-Baha

####

“A great many people think they are thinking when they are merely rearranging their prejudices.” — William James.

###

--
You received this message because you are subscribed to a topic in the Google Groups "rtl_433" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtl_433/d-AotXhX-Ec/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtl_433+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/4b5afb71-d508-4ff6-9391-3e2564291f8dn%40googlegroups.com.

[Clambino]

I'll start first thing tomorrow. Thanks so much!

[Tim Reimers KA4LFP]

Have been thinking about ways to make a drip set up to so that I can make rainfall on one of these....

I have an older lacrosse rain gauge that was seriously corroded,  which i have cleaned up, and have been wondering if it's even transmitting....so may do a drop setup for it too....

thanks tim

#####

How excellent, how honorable is man if he arises to fulfill his responsibilities; how wretched and contemptible, if he shuts his eyes to the welfare of society and wastes his precious life in pursuing his own selfish interests and personal advantages.
- Abdul-Baha

####

“A great many people think they are thinking when they are merely rearranging their prejudices.” — William James.

###

On Tue, Oct 13, 2020, 12:54 PM Michael Bruski <michael...@gmail.com> wrote:

--

[Clambino]

I have about five minutes worth of capture data from the LTV-TH3 and  LTV-WR1. The only data changes I could see on the display are with wind speed and direction. Weather Underground thinks my station is offline so I don't have any temp or humidity graphs from when rtl_433 was saving data. The Lacrosse app will be able to export a csv of todays data tomorrow. The following link contains a zip of the capture files and a text file with sensor IDs and model numbers. 

https://www.dropbox.com/s/fpichhhz2x3i819/Capture.zip?dl=0

On Tuesday, October 13, 2020 at 11:54:24 AM UTC-5 michael...@gmail.com wrote:

[Michael Bruski]

@Clambino

Are you sure the TH3 barcode is 10851 and not 110851?   I've looked at about 150 of your files.  Only six appear to have data for the WR1 (g021, g046, g072, g098, g125 and g145) and one appears to have data from the TH3 (g119).  The remainder are from the ultra chatty ISM electric meters in your neighborhood.  Each of your devices is transmitting a few bytes of alternating 1s and 0x followed by a sync word (0x2dd4) and then the six digit hexidecimal device ID (110851 for the TH3) followed by sensor data and possible CRC check.  At this point it would be nice to know what temp/humidity were at the time of capture (even ball park figure helps) as well as general wind speed and direction.

Mike/AJ9X

[Clambino]

It is 110851. Sorry about that! The following is from the data Lacrosse sends when the data archive is requested. I can capture more if you'd like. 

2020-10-10 14:21:25 0 NE 3

2020-10-10 14:21:55 0 N 4

2020-10-10 14:22:25 0 N 3

2020-10-10 14:22:55 0 NW 5

2020-10-10 14:23:25 0 N 3

2020-10-10 14:23:55 0 NE 7

2020-10-10 14:24:25 0 E 5

2020-10-10 14:24:55 0 E 2

[Michael Bruski]

If my guesses on message encoding are correct so far, winds were between 6 and 8mph gusting 16mph out of the S or SW.  Temp was 72.6F and Humidity 37%.   Sound about right?

I can't anything about rain at this point other than it didn't seem to be raining when you captured samples.

Mike/AJ9X

[Michael Bruski]

Depending on how LaCrosse encoded the temperature it could have been 54.9F (12.7C) or 72.6F (22.7C).   I need to know which is closer to the actual temp at the time you captured the signals.

Mike

[Clambino]

Thoes decodes should be right on the money. There was no rain, I'm hoping we get some tomorrow. Is there a way I can tell rtl_433 to limit captured packets to only those station related since the electric meters here are so yappy?

[Clambino]

72.6 is the correct temperature.

[Michael Bruski]

Working with bit streams that don't have a decoder I doubt there is much to do to suppress the yappy meters.   I could code something up based on what I know now and then you substitute 'S unknown' with 'S known' when you capture samples.   Since rtl_433 doesn't recognize those meters, it shouldn't create any sample files for them.

According to the timestamp on the g119_915M_1000k.cu8 file, that signal (TH3) was captured at 14:23 yesterday.  Can you check the archive for temp/humidity/wind-spd/wind-dir around that time frame?  The WR1 produced data between 14:21 and 14:24.  I don't know how well both your computer and the weather console are synchronized time wise but hopefully they are close enough.

Mike

[Michael Bruski]

The attached file shows what I have so far...

Mike

[Michael Bruski]

So I completed writing two candidate decoders earlier, one for the WR1 and one for the TH3.  Both work well against the sample files you captured the other day.  The one for the WR1 only dumps the two fields for rain as 6 hexidecimal digits since I don't know how to interpret them yet.   You could send me some more captures with rain activity (I'll have to sort through the yappy meters) or I could post the test binary for you to run.   I need to check with Christian Z. to see if I need to merge these into one decoder file since they both have the same signal params.  Only the payload length and structure differ.

Sample decoder outputs attached.

Mike/AJ9X

[Tim Reimers KA4LFP]

I'd be happy to test the binary since I'm running multiple Pi doing this....

thanks and 73, Tim KA4LFP 

#####

How excellent, how honorable is man if he arises to fulfill his responsibilities; how wretched and contemptible, if he shuts his eyes to the welfare of society and wastes his precious life in pursuing his own selfish interests and personal advantages.
- Abdul-Baha

####

“A great many people think they are thinking when they are merely rearranging their prejudices.” — William James.

###

--

You received this message because you are subscribed to a topic in the Google Groups "rtl_433" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtl_433/d-AotXhX-Ec/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtl_433+u...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/5697bdc9-c91e-4c4a-a7cc-1595d6ff040en%40googlegroups.com.

[Michael Bruski]

Got invited to my son's house for dinner tonight but I'll see if I can build it on the pi later this evening.  Today I was testing on my laptop.  Just so you know, I can't compile for Soapy at the moment, only rtl-sdr.

Mike/AJ9X

[Michael Bruski]

Tim,

See if this one will play for you.

Mike/AJ9X

[Christian Z.]

see if I need to merge these into one decoder file since they both have the same signal params.  Only the payload length and structure differ.

Two decoders is fine and actually preferred. But you can put them both in the same source file if they have some relation.

[Michael Bruski]

Thanks Christian,  I'll keep them separate then.  I have a question that perhaps you can answer.   How does one determine the reset_limit for the decoder?  Unlike the the BreezePro and TH3 sensors which have a long trail of 0s before the transmitter cuts off, the WR1 doesn't do that.   In fact, the tail of that transmission looks somewhat mangled.   All the same I get everything up to and including the CRC check byte.  I rationalized that if I was missing 48 bits of  data (all 0s in the four 12 bit data fields), that would qualify as a reset?  And so multiplied 48x my pulse width.  That appears to be working but a value of 20000 seems kind of high.   If I set it too low, I get multiple rows of bits that are too small to be meaningful.   Should I be trying something else?

Mike/AJ9X

[Christian Z.]

reset_limit is just the longest gap (or space for FSK) that is still accepted.

Usually set it slightly above the packet gap if you have multiple packets in a transmission or the longest data-bit gap if there is a single packet.

For FSK set it slightly above the longest expected space, e.g. for Manchester use 1.5x the half-bit width. If it's just plain PCM (which is not a good design) see what your longest run of 0's could be.

I don't think anything above a byte is reliable anyway (i.e. 10 zeros? or 11 zeros? is just a 10% margin and easily wrong with usual jitter).

[Michael Bruski]

Yes, FSK_PCM on these guys sending single packets so no gaps between which is why I picked 48x (all 4 data fields - maybe too many).  In a dead wind condition, the 12 bit wind speed field will be all 0s and no telling how many zero bits on either side.  If the MCU doesn't get input from any of the raw sensors, it is probable the sensor data fields could be all zeros.   With no gap at beginning or end I didn't know what to do with that.

[Michael Bruski]

Tim,

I did a prototype decoder for the R1 given what I expect to see.  To finish setting it up I'll need one or two samples from your bucket so I can measure pulse and packet lengths.

Mike/AJ9X

--

You received this message because you are subscribed to a topic in the Google Groups "rtl_433" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtl_433/d-AotXhX-Ec/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtl_433+u...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/6897b894-1567-4561-917a-b48c46944182n%40googlegroups.com.

[Michael Bruski]

Tim,

here is the r1 decode so far...

Mike

[Michael Bruski]

You could try the flex decoder to see the stuff in your sample files:

rtl_433  -Y minmax  -M level  -R 0  -r ~/ltv-r1/g010_915M_250k.cu8  -X 'n=r1,m=FSK_PCM,s=84,l=84,r=9600'

or, substitute -f 915M  for  -r ~/ltv-r1/g010_915M_250k.cu8

Mike

[Michael Bruski]

The rain data may be cumulative with the console tracking the total and the calculating the delta.  Spec for r1 and wr1 says it can report rainfall from 0 to 9999mm.  I found easiest way to track what sensor is sending to the console was to set that param to display in native units... mm instead of inches in this case.  Makes it a whole lot easier to see what is going on.   The value could also be a Rainday total as calculated by the console.  The sensor has very little smarts built in.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/0ac1dae0-9472-48f2-b810-69af328867a2n%40googlegroups.com.

[Michael Bruski]

Thinking this a little more... the sensor is probably only counting the number of times the bucket tips.  The console knows what volume of rain each click represents and calculates the total for the day, resetting the number at midnight... or tracking the number of toggles over the last 24 hour period.  What does your owner manual say about that?

I'm done for today... we can pick this up some more tomorrow sometime.

73s,

Mike

[Clambino]

Do you still need this info? I've had a touch of corona so I'm a little behind on things. Sorry!

[Clambino]

The captures in this zip should have rain data along with the chatty meters. I've included a text file with the time, rain and other info.

https://www.dropbox.com/s/5lo50k6w2p0o3d2/rain%20captures.zip?dl=0

[Michael Bruski]

I managed to find 10 records from the WR1 in that .zip file.   Looking at the rain info, Rain2 never changed, Rain1 incremented by 1 every other record (about 5 transitions from hex value 66 to hex value 6a.   In the text file where you gave me the readings, is the 0.01 the rain reading?   Is that in inches or millimeters?   If possible, it would be good to capture those values in millimeters because that is what the sensor is sending (some times what it actually measures is scaled by a fractional number to compute the actual millimeters).  During conversion to inches, there is some rounding error introduced and another rounding error when I convert it back to millimeters.

On your two sensors I think we have nailed down the wind speed, wind direction, temperature and humidity.   We just need to nail down this rain gauge and I can submit both decoders for inclusion in the next release.

BTW, how are you feeling?

Mike

[Michael Bruski]

Decoder sheet for the 10 files I found in your .zip.  I think rain1 is low-order bits and rain2 is hi-order bits when not set to 0xaaaa.   I'm not sure how to scale that value (rain1) though.

Mike

[Clambino]

Way above my head!

[Michael Bruski]

Ryan,

Did any of the beta executables I posted for you and Tim produce any output like this with live input:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.077943s
model     : LaCrosse-TH3 Sensor ID : 110851
Sequence  : 0            unknown   : 0             Temperature: 22.7 C       Humidity  : 37 %          Integrity : CRC

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.031351s
model     : LaCrosse-WR1 Sensor ID : 19047a
Sequence  : 2            unknown   : 16            Wind speed: 14.1 km/h     Wind direction: 213       raw_rain1 : 050           raw_rain2 : aaa           Integrity : CRC

Mike

[Clambino]

I don't recall seeing a binary.

[Michael Bruski]

Attached is the last one I posted for raspIOS buster.  Can you try it?  Command line should be something like:

rtl_433-pi-beta4 -M level -s 250k -f 915M

Please let me know what you see, if anything.

Mike

[Clambino]

Here you go!

[Clambino]

Here's the output with 1000k.

[Deepak Gunasekaran]

May I know how you guys analyze the .cu8 files? I went ahead and converted those to .sr file and try to open on pulseview. The pulseview does show up some spikes and square waves. I have no idea how I can convert those to Digital (1s and 0s) and finally converting to the actual decimal values. BTW, I'm trying to do the similar exercise on a offbrand temperature sensor which is on 433Mhz range. Thanks again!

-D

[Christian Z.]

May I know how you guys analyze the .cu8 files? I went ahead and converted those to .sr file and try to open on pulseview. The pulseview does show up some spikes and square waves.

Drop the .cu8 on https://triq.org/iqs/ to check the spectrum. Then convert the .cu8 to (ook) pulses: rtl_433 -w FILENAME.ook FILENAME.cu8

and drop that file on https://triq.org/iqs/pdv to inpect the pulses and timings. The .ook is also readable text. The .sr Pulseview is more to see the inner workings of rtl_433's demodulator.

[Jesse Kohn]

I see this thread is a couple of months out of date but I just wanted to jump in and say thank you, as I own a V40-Pro station with these two sensors, and I see that rtl_433 now has profiles for these devices. When i first gave SDR a go over a year ago, I had very little success getting data from this station and gave up. I currently extract the data from the indoor unit using a network redirect (capturing the data that's sent to Weather Underground, but it's very limited).

I'm happy to help with any further testing to improve the reliability of this effort. it might also help that I have two of the outdoor units as one has a broken wind meter (so could potentially speed up testing of the rain gauge?)

[jdw...@menelos.com]

Hello. I have a La Crosse LTV-TH2 which I'm hoping is similar enough to the TH3 to be relevant here. I've been following this thread and would like to throw in my results and help to get a working decoder for these units.

I tried to decode using a fresh build of version of rtf_433 from GitHub source dated 202103120818, but didn't seem to be able to properly decode.

I downloaded the rtl_433-rpi-beta4 from the previous post and ran the test command Mike provided. Attached are my results.

Happy to try any new builds and provide additional test data.

Thank you,

-Jason

Note: I tried to set the sample rate of 250k, but would always default to 1000k.

On Thursday, October 22, 2020 at 10:52:23 AM UTC-5 michael...@gmail.com wrote: