-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
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
Separate the WH24 and WH65B protocols #844
Comments
As far as I can see the WH65B differes only in a slightly longer preamble. The family code (0x24) is the same as the WH24. If we can always get the full preamble we can take a guess, but that's far from reliable, sadly. |
I suppose a new protocol code that's not enabled by default would work. That way it could be selected on purpose. It is kind of inconvenient that there's no clear difference. |
I just realized that I actually have two devices that come in under protocol 78. In addition to the WH65B, I have a WH25 for indoor temp, humidity, and pressure. If the WH65B was a different protocol, I would still see the WH24 packets as well. So, I guess I need a way to only get the WH65B packets and still get my Wh25 packets. Sorry, it sounds kind of messy. |
I guess I'll add a threshold to the preamble length to decide wether it's a WH65B. You can then test that for a week or so and report if (and how many) wrong WH24 reports came in. Maybe the preamble is stable enough to use after all. |
Can someone post analyzer (-A) output and sigrok pictures? Then more people might be able to help out. |
Maybe they used different amount of repeats ? (Etc...) |
Well the payload differs also 08 vs 00 at the end. Can that be used ? |
Payload is
|
Well one signal seems to be longer 196 vs 209. Can you point me to the samples you use? |
It could be that the WH24 is on 433MHz and the WH65b is 868/915MHz. |
Mine is 915Mhz. |
Ok, analysis by looking at the signal in sigrok (awesome job there @zuckschwerdt ) gives that one cycle in the preamble (one high frequency followed by one low frequency) is 116us in both the the wh24 and wh65 thus any difference in the transport layer does not depend on temperature or batter level. The signal duration of the wh65 signals are ca 12.03ms and the wh24 signals are ca 11.3ms. The preamble duration of the wh24 is 2.389ms and the wh65 2.625ms. The differece of the preambles give this 2625-2389=236. 236 =~ 116*2 -> the wh65 has 2 more cycles of the preamble (4 bits) compared to the wh24. From the posted example it is clear that there are more data present before the sync word visualized below as an X.
So by locating the sync word and using the bit count before the sync word as heuristic should be quick and reliable way to decide between wh24 and wh65b signals. |
Looking a the test samples we got:
and removing then extra 4 bits on front of the WH65B samples we can inspect in BitBench. |
I'd say if (after aligning the sync word) there is a postamble of 8 or more (nominal 12) bits we'll call it a WH65B. The WH24 would have only 3 bits so it should be somewhat resilient to slight errors. |
Something liek this (the actual calculation differences are missing): zuckschwerdt@f09fa12 |
If you look at the signal in sigrok you can see that there is a real signal there but the decoded bits are bogus. But in our case it actually doesn't matter. We just need to measure the signal length somehow. Either towards the beginning or the end. The end is more reliable as the preamble has primed the receiver. As long as the demodulator spits out bits per time unit everything will be fine. |
@StephenR0 can you check if #845 works? |
It looks good at first glance. I'll put it in service and get more experience with it. -> rtl_433 -q -U -F json -p 39.741 -R 78 -f 914980000 |
@StephenR0 give a thumbs up on #845 if everything works as expected. |
It looks good from here. I was thinking that it would be good to get some testing from a WH24 user, but I haven't gotten a response from that. I think we're good, though. |
Reopen if anything comes up. |
Hi Stephen Here is a copy of my WH24 unit. |
That looks good. I was hoping we didn't break anything. 👍 |
#1220 appears related too. Apparently the heuristics that decide whether we're dealing with a WH65B or a WH24 are very susceptible to noise and slightly improper decoding. I've found that if I use |
Yes, the differentiation is only a few bits in the preamble. Not sure if there is a way to improve that. rtl_433/src/devices/fineoffset.c Lines 211 to 218 in 86abae0
|
I have received a communication from Fine Offset about the differences between the output of the WH24 and the WH65B sensor arrays. Here is what they said:
Please note the factor difference for wh65b is as follow:
Beside this, all other is same.
I assume they mean that the wind speed factor is for both the wind and gust data. That is the same as my calculations of the wind speed factor. There is a conflict about the WH24 wind speed factor, though. Here they said that the WH24 wind speed factor is 1.19m/s/hz and the previous information was 1.12. I can't verify that, so I suggest that we not disturb that until we get better information. In any case, I would like to be able to post about how to use rtl_433 with the WH65B without hacking the code as I've done for my purposes. Is there a way to distinguish between the two types of packets? If not, is there another way to specify only looking for one type or the other that could be arranged? Thanks.
The text was updated successfully, but these errors were encountered: