LTV-R3 Rain Sensor about rtl_433_tests HOT 17 CLOSED

There was no PR, all is well.

Nobody figured out how to read rain1/2 yet. https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_r1.c#L14-L17

Just upload a zip with files here and write a short note what sensor you used and what the likely readings in the files (temp, humidity, ...).

Thanks!

from rtl_433_tests.

Great, thanks.
I have only the LTV-R3 Rain sensor, I don't have a station, I am planing to use rtl_433 to get the information.
https://www.lacrossetechnology.com/products/ltv-r3
European version, on 868 MHz

The files 008 and 009 were generated just after I put some old batteries, I hope they have the "Low Battery" flag. I also noticed that they were sent within a short period of time, so they might contain a specific information in order to "talk" to the station(?). 014 was created after a couple of switches (drop simulation).

Files 002, 003 and 004 were created with new batteries, and I simulated drops, if there is a rain-rate field, you may be able to see it (high rate).

The sensor is not installed yet, let me know if you need more specific tests files.

Gcu8-files.zip

from rtl_433_tests.

I made more tests a took notes.

Device ID 70F6A2

18h21 insert batteries
*** Saving signal to file g002_868.3M_1024k.cu8 (35294 samples, 131072 bytes)
*** Saving signal to file g003_868.3M_1024k.cu8 (426802 samples, 917504 bytes)
*** Saving signal to file g004_868.3M_1024k.cu8 (104167 samples, 262144 bytes)
Signal bigger than buffer, signal = 6160384 > buffer 3145728 !!
*** Saving signal to file g005_868.3M_1024k.cu8 (3037473 samples, 3145728 bytes)
*** Saving signal to file g006_868.3M_1024k.cu8 (58544 samples, 131072 bytes)
*** Saving signal to file g007_868.3M_1024k.cu8 (58543 samples, 131072 bytes)
*** Saving signal to file g008_868.3M_1024k.cu8 (58652 samples, 131072 bytes)
*** Saving signal to file g009_868.3M_1024k.cu8 (58542 samples, 131072 bytes)
*** Saving signal to file g010_868.3M_1024k.cu8 (58652 samples, 131072 bytes)
18h23 bascule 1
*** Saving signal to file g011_868.3M_1024k.cu8 (58654 samples, 131072 bytes)
18h24 bascule 2
*** Saving signal to file g012_868.3M_1024k.cu8 (58656 samples, 131072 bytes)
18h24'30" bascule 3
*** Saving signal to file g013_868.3M_1024k.cu8 (58547 samples, 131072 bytes)
18h25 bascule 4
*** Saving signal to file g014_868.3M_1024k.cu8 (58657 samples, 131072 bytes)
18h25'30" bascule 5
*** Saving signal to file g015_868.3M_1024k.cu8 (58661 samples, 131072 bytes)
18h27 bascule 6
*** Saving signal to file g016_868.3M_1024k.cu8 (58666 samples, 131072 bytes)
18h27'15 bascule 7
18h27'30 bascule 8
*** Saving signal to file g017_868.3M_1024k.cu8 (58446 samples, 131072 bytes)
18h29 bascule 9
*** Saving signal to file g018_868.3M_1024k.cu8 (58661 samples, 131072 bytes)
18h30 bascule 10
*** Saving signal to file g019_868.3M_1024k.cu8 (58438 samples, 131072 bytes)
18h32 bascule 11
*** Saving signal to file g020_868.3M_1024k.cu8 (58324 samples, 131072 bytes)
*** Saving signal to file g021_868.3M_1024k.cu8 (57995 samples, 131072 bytes)
*** Saving signal to file g022_868.3M_1024k.cu8 (58655 samples, 131072 bytes)
*** Saving signal to file g023_868.3M_1024k.cu8 (57994 samples, 131072 bytes)
18h39 bascule 12
*** Saving signal to file g024_868.3M_1024k.cu8 (58323 samples, 131072 bytes)
*** Saving signal to file g025_868.3M_1024k.cu8 (58546 samples, 131072 bytes)
Gcu8files.zip

from rtl_433_tests.

I am trying to look at it, but I don't understand how all this works.
Here are few more files generated.

Could someone confirm that the files generated are correct or if I may have a wrong command line (rtl_433 -f 868.3M -s 1024k -G 4 -S unknown) or if the device may be disfunctional?

Gfiles.0617.zip

from rtl_433_tests.

Looks like FSK PCM with 100 µs bit time, preamble matches the LTV-R1 (aad2aa2dd4). This works to get the data.
rtl_433 -s 1024k -f 868.3M -X 'n=LTV03,m=FSK_PCM,s=100,l=100,r=1600,preamble=aad2aa2dd4' *.cu8
See this BitBench.
I'll now need to inspect the data to figure out where the values are.

from rtl_433_tests.

The LTV-R3 seems to send a shorter preamble and less trailer. And there is a bug with the CRC check in the LTV-R1 decoder.
Change these two lines and recompile and you should get some data out:
https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_r1.c#L67
if (msg_len < 256) { to if (msg_len < 200) {
and https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_r1.c#L101
return DECODE_FAIL_MIC; to // return DECODE_FAIL_MIC;

from rtl_433_tests.

I've added preliminary support for the LaCrosse LTV-R3. Get the current rtl_433, recompile and test please.
There are rain1 and rain2 values strangely. Those are counters and should be something like x0.1 mm total rain?
Not sure why the R3 has two counters and the R1 just one counter. Could be something like "1 hour ago", as the second counter seems lower.

from rtl_433_tests.

Thank you very much!
I installed the latest version. Only few messages are recognized and decoded.
Sometimes I have the message "lacrosse_r1_decode: CRC failed!" but sometimes I have nothing (I just see the data due to -X parameter)

I just see now that you edited the -X command and added ",preamble=aad2aa2dd4", it seems that your are missing more messages with this parameter.

from rtl_433_tests.

Yes, something is strange about the CRC. In many (R3) packets it's apparently wrong.
I commited another change now. You can add -vv to get all messages (ignores CRC).

You should see

lacrosse_r1_decode: CRC failed!
lacrosse_r1_decode: {142} 70 f6 a2 0c 00 aa 0a 01 54 1a ac 00 00 00 00 00 00 00

and the output. This is for debugging only. We don't want outputs with broken CRC. Please collect many of those lines (100?) and post here. Thanks!

from rtl_433_tests.

There at least two different formats for this packet: R1 with 8 bytes for CRC, R3 with 11 bytes for CRC. And my guess is that there is actually a third type with some other CRC -- we need to determine that.

from rtl_433_tests.

I tried to get more lines, but I am not sure I got the proper command line. Would you mind to give me the correct command line to generate what you need?
I use this : /usr/local/bin/rtl_433 -f 868.3M -s 1024k -S unknown -vv

However, I got some weird results, including a difference in the sensor ID, so here is the output I got
0618-tests.txt

From your previous link to bitbench, I put the Sensor ID "70f6a2" in the "Align" field and apparently it finds many lines, more than I get when I run rtl_433.

from rtl_433_tests.

rtl_433 -f 868.3M -vv will do.

from rtl_433_tests.

In your file there are just 4 codes with failed CRC. All look like invalid data.

lacrosse_r1_decode: {143} 70 f6 a2  42  00 aa 00  00 aa 00  04  00 00 00 00 00 00 00 <- bad counter
lacrosse_r1_decode: {146} 70 f6 a2  44  00 aa 00  00 55 00  09  00 00 00 00 00 00 00 00 <- bad counter
lacrosse_r1_decode: {143} 70 f6 a0  04  01 54 02  01 54 01  84  00 00 00 00 00 00 00 <- bad ID
lacrosse_r1_decode: {144} 70 ed 44  00  00 aa 02  00 54 05  bc  00 00 00 00 00 00 00 <- bad ID

So maybe the CRC working fine, you just have bad reception and thus frequently broken codes.

from rtl_433_tests.

I got it running and the only few CRC errors I had was due to bad ID.

Apparently, the value to use is raw_rain1, raw_rain2 probably contains the last value sent (although I am not sure for a couple of times, but the device might have missed the transmission).
0618-tests2.txt
I will have to compare rain value with other stations around, but I thing the unit is mm, every switch represent 1 mm of rain per m2.

I wanted to do a kind of reset of the device in order to see what happens to the rain values, so I removed the batteries. But then rtl_433 is not working, I get this error :

baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us
philips_aj7010_decode: wrong number of bits (0)
secplus_v2_callback: DECODE_FAIL_SANITY
secplus_v1_callback:return DECODE_ABORT_LENGTH
philips_aj7010_decode: wrong number of bits (0)
secplus_v2_callback: DECODE_FAIL_SANITY
secplus_v1_callback:return DECODE_ABORT_LENGTH

I unplugged the dongle and will retry, but do you have an idea of the problem here?

from rtl_433_tests.

Confirming if it's really 1mm/m2 per bucket tip would be great!

What you notice there is not an error, just secplus_v1 and philips_aj7010 telling (because of -vv) that data that's coming in does not fit -- which is expected, quite a number of decoders are asked to decode evey random bit sequence.

from rtl_433_tests.

Looking more carefully, could be 0.5mm/m2 as well. After a good raining day, it should be possible to compare.

I had a look at other tests files and I was afraid you would say the messages are normal.
So, it seems my device is not working anymore, I don't get any other data...

from rtl_433_tests.

What about rtl_433 -s 1024k -f 868.3M -X 'n=LTV03,m=FSK_PCM,s=100,l=100,r=1600' ? Reseting the battery should be robust, perhaps a battery prong didn't connect? I'd reset again and also watch the band with CubicSDR or Gqrx. And then-A` will show any data coming in, to see if there is some kind of signal still.

from rtl_433_tests.