Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Added support for LaCrosse LTV-WR1 Multi Sensor #1533

Merged
merged 4 commits into from
Oct 26, 2020
Merged

Added support for LaCrosse LTV-WR1 Multi Sensor #1533

merged 4 commits into from
Oct 26, 2020

Conversation

mbruski
Copy link
Contributor

@mbruski mbruski commented Oct 24, 2020

No description provided.

@mbruski
Copy link
Contributor Author

mbruski commented Oct 24, 2020

Let's see if I got this one correct before I add the LTV-TH3.

Note that this decoder outputs good wind speed/direction data but rainfall data is output 'raw_' for now until I discover the magic equation for the raw variables.

@zuckschwerdt zuckschwerdt mentioned this pull request Oct 24, 2020
Closed
zuckschwerdt
zuckschwerdt reviewed Oct 24, 2020
View reviewed changes
src/devices/lacrosse_wr1.c Outdated
data = data_make(
"model", "", DATA_STRING, "LaCrosse-WR1",
"id", "Sensor ID", DATA_FORMAT, "%06x", DATA_INT, id,
"seq", "Sequence", DATA_FORMAT, "%01x", DATA_INT, seq,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seq is 3 bit (0-7) a format isn't needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been displaying correctly during testing but if you want to change it, be my guest.

@zuckschwerdt
Copy link
Collaborator

This looks really good.

@mbruski
Copy link
Contributor Author

mbruski commented Oct 24, 2020

Do you want me to commit additions for LTV-TH3 to this branch or should I create a separate one?

@zuckschwerdt zuckschwerdt merged commit 62406c7 into merbanan:master Oct 26, 2020
zuckschwerdt pushed a commit that referenced this pull request Oct 26, 2020
@mbruski @zuckschwerdt
Add support for LaCrosse LTV-WR1 Multi Sensor (#1533)
10908e6
@mbruski mbruski deleted the feat-ltv-wr1 branch October 30, 2020 10:19
@some-random-kahuna
Copy link

I have an older Lacrosse sensor, the LTV-TH2, and since my Lacrosse C84343 base station lists both the LTV-TH2 and LTV-TH3 as compatible sensors, I took at look at this recent addition and found that it works with my LTV-TH2 with a couple of changes. First, the message length appears to be 285 bytes; greater than the 256 byte upper limit check. Secondly, the CRC transmitted by the sensor has a remainder of zero only with sequence numbers of 2 and 6. For sequence numbers of 0,1,3,4,5, and 7 the CRC is not 0, but 0xac. Maybe the message format is slightly different in the TH2? For my environment , the decoding of messages with those two changes in lacrosse_th3.c is 100% and the data returned corresponds with the temp/humidity shown on the LCD on the sensor. This works for my purposes, but I'm willing to help with a less dirty hack if needed...Aloha

@mbruski
Copy link
Contributor Author

mbruski commented Nov 3, 2020 via email

@some-random-kahuna
Copy link

Hi Mike,

Here are two. The g001 file is a capture that has a sequence of 5 and a CRC of 0xac. The g002 file is a capture that has a sequence of 6 and a CRC of 0x00:

$ rtl_433 -s 1000k -X 'n=th2, m=FSK_PCM, s=104, l=104, r=9600' g001_915M_1000k.cu8
rtl_433 version 20.02-212-ga2de0c9 branch master at 202010270814 inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 144 out of 173 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-173 ]
Test mode active. Reading samples from file: g001_915M_1000k.cu8

time : @0.073940s
model : th2 count : 1 num_rows : 1
rows :
len : 286 data : 555555555555555a5545ba865caae1452c09b27a5a5a5a5a400000000000000000000000
codes : {286}555555555555555a5545ba865caae1452c09b27a5a5a5a5a400000000000000000000000
message: 0x32 0xe5 0x57 0xa 0x29 0x60 0x4d 0x93 0x58 0x68 0x5f crc: 0xac

time : @0.073940s
model : LaCrosse-TH3 Sensor ID : 32e557
Sequence : 5 unknown : 0 Temperature: 26.2 C
Humidity : 77 % Integrity : CRC
++++++++++++++++++++++++++++++++++++++++++++++
$ rtl_433 -s 1000k -X 'n=th2, m=FSK_PCM, s=104, l=104, r=9600' g002_915M_1000k.cu8
rtl_433 version 20.02-212-ga2de0c9 branch master at 202010270814 inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 144 out of 173 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-173 ]
Test mode active. Reading samples from file: g002_915M_1000k.cu8

time : @0.073945s
model : th2 count : 1 num_rows : 1
rows :
len : 286 data : 555555555555555a5545ba865caae1852c09acba5a5a5a5a400000000000000000000000
codes : {286}555555555555555a5545ba865caae1852c09acba5a5a5a5a400000000000000000000000
message: 0x32 0xe5 0x57 0xc 0x29 0x60 0x4d 0x65 0x58 0xc8 0xca crc: 0

time : @0.073945s
model : LaCrosse-TH3 Sensor ID : 32e557
Sequence : 6 unknown : 0 Temperature: 26.2 C
Humidity : 77 % Integrity : CRC

th2_samples.zip

@mbruski
Copy link
Contributor Author

mbruski commented Nov 3, 2020 via email •
edited by zuckschwerdt
Loading

@zuckschwerdt
Copy link
Collaborator

If there is a sufficient preamble (like the 55555555555555s here) the slicer will automatically pick that up. You could use 80 µs or 150 µs and it will still work.

@mbruski
Copy link
Contributor Author

mbruski commented Nov 3, 2020 via email

@some-random-kahuna
Copy link

Happy to check it on my HW, but I'm not seeing the attachment.

@mbruski
Copy link
Contributor Author

mbruski commented Nov 4, 2020 via email

@mbruski
Copy link
Contributor Author

mbruski commented Nov 4, 2020

Please send me a PM at [email protected]. Github is not allowing me to attach a .c file to emails.

@zuckschwerdt
Copy link
Collaborator

If it's just changes for the CRC you might consider checking both in the TH3 code an then toggle the model.

@mbruski
Copy link
Contributor Author

mbruski commented Nov 4, 2020 via email •
edited by zuckschwerdt
Loading

@mbruski
Copy link
Contributor Author

mbruski commented Nov 4, 2020 via email •
edited by zuckschwerdt
Loading

@zuckschwerdt
Copy link
Collaborator

Timing likely isn't a factor here. The units (receivers and sender) won't have a stable enough reference and thus just lock onto the preamble. That's suggested best practice (not that any designer there ever seems to care about best practice…)

If only the CRC is the difference (and maybe some model bits we don't known about) and even the CRC can overlap (2,6 cases) then it's best to handle it in a single decoder -- having false positives is worse. Maybe even regard the TH2 as a TH3 if there isn't enough evidence to split them: model names refer to a protocol, user will known or not care what specific revision their unit is.

@some-random-kahuna
Copy link

Maybe that's why there's a TH3: they fixed the firmware that generated a bad CRC 25% of the time in the TH2

@mbruski
Copy link
Contributor Author

mbruski commented Nov 5, 2020 via email

@some-random-kahuna
Copy link

Hi Mike,

If you're still interested in this, I've been running your TH2 decoder for a while and have noticed at least one malformed message that made it though. The file it's going into has been awked and I don't have any other information. Would you like a few more captures to fine tune the decoder timing?

2020-11-20 03:05:16 26.700 75
2020-11-20 04:05:16 226.400 302
2020-11-20 05:05:16 26.500 75

Aloha,
Mark

@mbruski
Copy link
Contributor Author

mbruski commented Nov 20, 2020 via email

@zuckschwerdt
Copy link
Collaborator

Using the values we should be able to convert them back to the original message, maybe something obvious pops out then?
(e.g. on some decoders we assumed a value to be 8 bit but then the top bit was something like a battery flag).

@mbruski
Copy link
Contributor Author

mbruski commented Nov 21, 2020 via email

@some-random-kahuna
Copy link

Hi Mike,

I've had it running for some time now without any more spurious outputs. Given that whatever is going on looks like a rare occurance, I think your suggestion of just sanity checking the temp and humidity values makes sense. Here's what I added:

// base and/or scale adjustments
temp_c = (raw_temp - 400) * 0.1f;

if (temp_c < -40.0 || temp_c > 60.0 || humidity < 10 || humidity > 99) {
    if (decoder->verbose) {
       fprintf(stderr, "%s: Spurious temp and/or humidity values!\n", __func

__);
}
return DECODE_FAIL_MIC;
}

@mbruski
Copy link
Contributor Author

mbruski commented Nov 24, 2020 via email •
edited by zuckschwerdt
Loading

@zuckschwerdt
Copy link
Collaborator

The fail code shoud be SANITY not MIC :)
We generally limit only known bad values, not implausible ones.
A sensor might work with 60+ °C? If you limit to 60.0 then (600+400) you limit the field to 10 bit, but it's 12 bit -- or are the upper bits something else? How would < -40 work with unsigned - 400 :)
Some sensors report humidity 0/100 on under-/overflow, is 10/99 really a protocol limit? Why is humidity 12 bit wide? I guess the upper bits are something else, right?

@some-random-kahuna
Copy link

Hi Christian,

All good questions.

The fail code shoud be SANITY not MIC :)
OK (with me at least)

A sensor might work with 60+ °C? If you limit to 60.0 then (600+400) you limit the field to 10 bit, but it's 12 bit -- or are the upper bits something else?

I picked the numbers based on the sensor environmental specifications mentioned earlier in the module. As for how the fields are really defined, your guess is as good as mine. Based on the operating specs, though, 2^10 seems more plausible than 2^12 for temperature and a single byte would do it for humidity. Where did the field definitions for the TH3 come from?

How would < -40 work with unsigned - 40

raw_temp is an int, so the conversion and subsequent limit check should be copacetic.

I will fully agree that this is a dirty hack and that we're missing something about the bits coming in from the TH2 sensor. Suggestion? More raw captures?

Aloha,

-Mark

@zuckschwerdt
Copy link
Collaborator

To clarify on the < -40, a recent compiler or linter will be smart enough to point out that unsigned - 40 will never match that condition ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@zuckschwerdt zuckschwerdt zuckschwerdt left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@mbruski @zuckschwerdt @some-random-kahuna