Analyze protocol for Fine Offset WH32B

[tgtcd]

I am trying to map the WA5WH32B with rtl_433 to add new device support. When run:

rtl_433 -G -f 914980000

I see good data from my WH65B and WH31E without issue, but I do not see the WH32B. When I attempt to restart the WS32B by removing the battery and replacing, I receive:

pulse_FSK_detect(): Maximum number of pulses reached!

I have done this several times and the error is consistently reproducible. I also tried removing and replacing the battery on my WH31E and received the same error.

I am not sure if the devices just send some junk on the first packet, or if the code is misreading what it is getting.

I also do not see the WH32B in the trace, but I see all other data.

Help on the error trapping would be great.

{"time" : "2019-02-01 16:37:05", "model" : "Fine Offset WH65B", "id" : 41, "temperature_C" : 9.400, "humidity" : 44, "wind_dir_deg" : 119, "wind_speed_ms" : 1.084, "gust_speed_ms" : 1.530, "rainfall_mm" : 134.112, "uv" : 231, "uvi" : 0, "light_lux" : 16585.000, "battery" : "OK", "mic" : "CRC"}
{"time" : "2019-02-01 16:37:21", "model" : "Fine Offset WH65B", "id" : 41, "temperature_C" : 9.400, "humidity" : 46, "wind_dir_deg" : 128, "wind_speed_ms" : 1.084, "gust_speed_ms" : 1.530, "rainfall_mm" : 134.112, "uv" : 209, "uvi" : 0, "light_lux" : 15980.000, "battery" : "OK", "mic" : "CRC"}
{"time" : "2019-02-01 16:37:31", "model" : "AmbientWeather-WH31E", "id" : 226, "channel" : 2, "battery" : "OK", "temperature_C" : 19.000, "humidity" : 29, "data" : "0300000000", "mic" : "CRC"}
{"time" : "2019-02-01 16:37:31", "model" : "AmbientWeather-WH31E", "id" : 226, "channel" : 2, "battery" : "OK", "temperature_C" : 19.000, "humidity" : 29, "data" : "0300000000", "mic" : "CRC"}
{"time" : "2019-02-01 16:37:37", "model" : "Fine Offset WH65B", "id" : 41, "temperature_C" : 9.400, "humidity" : 45, "wind_dir_deg" : 125, "wind_speed_ms" : 1.402, "gust_speed_ms" : 1.530, "rainfall_mm" : 134.112, "uv" : 192, "uvi" : 0, "light_lux" : 15500.000, "battery" : "OK", "mic" : "CRC"}
{"time" : "2019-02-01 16:37:50", "model" : "AmbientWeather-WH31E", "id" : 219, "channel" : 1, "battery" : "OK", "temperature_C" : 7.900, "humidity" : 51, "data" : "1300000000", "mic" : "CRC"}
{"time" : "2019-02-01 16:37:50", "model" : "AmbientWeather-WH31E", "id" : 219, "channel" : 1, "battery" : "OK", "temperature_C" : 7.900, "humidity" : 51, "data" : "1300000000", "mic" : "CRC"}
pulse_FSK_detect(): Maximum number of pulses reached!

{"time" : "2019-02-01 16:38:09", "model" : "Fine Offset WH65B", "id" : 41, "temperature_C" : 9.300, "humidity" : 45, "wind_dir_deg" : 119, "wind_speed_ms" : 0.255, "gust_speed_ms" : 0.510, "rainfall_mm" : 134.112, "uv" : 178, "uvi" : 0, "light_lux" : 14942.000, "battery" : "OK", "mic" : "CRC"}
{"time" : "2019-02-01 16:38:25", "model" : "Fine Offset WH65B", "id" : 41, "temperature_C" : 9.300, "humidity" : 46, "wind_dir_deg" : 119, "wind_speed_ms" : 0.701, "gust_speed_ms" : 1.020, "rainfall_mm" : 134.112, "uv" : 174, "uvi" : 0, "light_lux" : 14880.000, "battery" : "OK", "mic" : "CRC"}

[tgtcd]

For reference - using a NooElec NESDR Mini USB RTL-SDR & ADS-B Receiver Set, RTL2832U & R820T Tuner, MCX Input on Raspberry Pi running current version of CentOS.

[zuckschwerdt]

The overlong message on reset could be a sync pattern. Try to determine the frequency of the new sensor first. Then record some data.
Use CubicSDR or Gqrx and note the frequencies. Or try rtl_433 with a wider sample rate and meta data output (-s 1024k -M level -A) and note the frequencies.
Try a center frequency with a little offset, -f 915M should work well if the sensors is on 914.98M.

[phinnay]

I am also attempting to get the WH32B to work. I see good data from both my WH65B and the WH31E and have saved a few cu8 files that could possibly be from the WH32B? How do you know what recording is useful and what is just noise? Attached is a zip with all the recordings that were not the 65 or 31 with a text file showing the console output
signal.zip

I've also recorded whatever is coming out of the WH32B when you remove / replace the batteries via CubicSDR and have attached it here - it sounded clearest with FM modulation
WH32B_wav.zip

I'd love to get this device supported! if there is anything else I can do to assist let me know.

[zuckschwerdt]

How do you know what recording is useful and what is just noise?

Drop the sample file in triq.net/iqs and verify that it looks "proper". Broadly speaking there should be one "streak" of data.

Best advice is to remove the antenna from the receiver and place the device under test about 10 cm from the receiver. That way you only get that single device.

[zuckschwerdt]

From your signal zip: 4,7,12,15 look like proper FSK. 13, 21 are too weak.
The others are strong (and harshly switched) FSK signals that use an exceedingly wide band by aliasing heavily. They show no data, just a regular pulsing for 3 seconds. If that pattern appears too frequently I would locate that device and remove it. It acts like a jammer.

Data from your good samples can be read with

rtl_433 -R 0 -X 'n=new,m=FSK_PCM,s=58,l=58,r=290' FILENAME.cu8

Looks like there is a sync word of 2dd4, try:

rtl_433 -R 0 -X 'n=new,m=FSK_PCM,s=58,l=58,r=290,preamble=2dd4' FILENAME.cu8

Now write down the codes you see (e.g. {60}e9f27b2a273be20) along with the expected sensors readings. A table of 10-20 entries should suffice to start locating the bits.

[phinnay]

interesting, so that 3 second screech at battery insertion is just noise? What would be the reason for that?

I disconnected the antenna from my RTLSDR and placed the WH32B in the enclosure with it:

The unit is in a basement and cannot hear any other devices without the antenna from there, I recorded new cu8 files with the following command:
rtl_433 -f 915000000 -S all

then decoded them as per your instruction:
rtl_433 -R 0 -X 'n=new,m=FSK_PCM,s=58,l=58,r=290,preamble=2dd4' FILENAME.cu8
attached below is a ZIP with the recording and a text file with the output.
signal2.zip

resulting code output:

codes     : {61}e392552727799100
codes     : {61}e392552727799100
codes     : {60}e39259262777920
codes     : {60}e39259262777920
codes     : {59}e3925c252777940
codes     : {59}e3925c252777940
codes     : {61}e3925f2527799900
codes     : {61}e3925f2527799900
codes     : {58}e39261242777980
codes     : {58}e39261242777980
codes     : {59}e392642427789c0
codes     : {59}e392642427789c0
codes     : {61}e392662327769b00
codes     : {61}e392662327769b00
codes     : {61}e392672327779d00
codes     : {61}e392672327779d00
codes     : {56}e3926a232777a0
codes     : {56}e3926a232777a0
codes     : {61}e3926f222776a300
codes     : {61}e3926f222776a300
codes     : {25}e392700
codes     : {25}e392700
codes     : {25}e392700
codes     : {25}e392700
codes     : {59}e39271212776a40
codes     : {59}e39271212776a40

The sensor remained in the box in the basement for the whole time, why the variation in code length? I'd think that would remain the same length of bits. You can see the values on the LCD screen in the pics.

[zuckschwerdt]

Great! I'll look into decoding this. The trailing bits (mostly 0) are just an artefact of the FSK demodulation.

[zuckschwerdt]

It could reasonably be something like ID?8d FLAGS?4h TEMP?12d HUM:8d ?16h CHK:8h
(where temperature is °C offset 40 scaled 10 and the checksum is plain addition with carry).
Use that bitbench to decode data with exactly known value, best case very high and low values.

[phinnay]

this is fun :D

I captured six packets at known temperatures, it looks like you got humidity figured out, but temp and pressure don't line up.

69.1 F / 32% RH / 29.80 inmg
e3925e20

69.3 F / 33% RH / 29.80 inmg
e3925f21276c880

69.1 F / 33% RH / 29.81 inmg
e3925e21276e8900

e3925e21276d880
69.1 F / 33% RH / 29.80 inmg

e3925f21276d8900
69.3 F / 33% RH / 29.80 inmg

e3925f21276c880
69.3 F / 33% RH / 29.80 inmg

[zuckschwerdt]

Very good! If you convert the F to C, scale and offset you get the "raw" values:

• 69.1°F = 20.6°C (+40 x10 = 606)
• 69.3°F = 20.7°C (+40 x10 = 607)

Same for the Pressure from inHg to hPa:

• 29.80 * 33.864 = 1009.14
• 29.81 * 33.864 = 1009.48

See in this BitBench.

If you now take the battery out a few times and note where the bits change we can identify the ID position and then we are done. (Bonus: use a known flat battery or variable power supply to find the battery_low flag.)

[phinnay]

Ahh, i forgot to offset that's why my numbers didn't work.

I hooked the WH32 up to a power supply and dropped the voltage until the LCD screen was dim. It did not like that. The LCD showed dashes for temp and humidity however I still picked up packets that coincided with the transmit indicator on the screen.

low battery (2v)

-- F / -- RH / 29.96 inmg
e0ffffff27a0a40

-- F / -- RH / 29.96 inmg
e0

-- F / -- RH / 29.96 inmg
e0

-- F / -- RH / 29.96 inmg
e0ffffff27a2a60

I then put good batteries back in and captured 5 more packets, didn't record the climate info since that's already figured out

efa2482727759c0
efa2472727769c0
efa2462727759a0
efa2462727759a0
efa245272775990

[zuckschwerdt]

Updated BitBench.
The first 4 bit seem fixed to 0xe. The next 8 bits could be ID.
The battery_low flag then could be the top bit of temperature, but hard to say as the temperature reading failed (the voltage was too low).

What is the claimed range for temperature? The values can represent

• -40.0 to
• 62.3 (at 10 bit)
• 164.7 (at 11bit)
• 369.5 (at 12 bit).

I'd say 10 bit is too close. But 11 bit will work well. So the top bit could be battery_low.

If you want to make this bullet proof:

• Cycle the battery 10 or more times and record data each time (no need for the actual reading). This will tell if the first 4 bit are really fixed and if the next 8 bits all change.
• Drop the voltage low but just high enough that there the reading still works. This will have a proper temp value and show the battery_low bit.

[phinnay]

I'm away on business this week, if someone else can capture the packets needed that'd be awesome! If not we will have to pick this up next week.

[zuckschwerdt]

@phinnay since your build already looks great here some quick hints to make it really shine:

Never plug the receiver directly into a board. At least the Raspi (and I guess all unshielded SoCs) have nasty emissions. Even a short USB extension cable will make a difference (looks like you got room to space the receiver with a 10cm cable.

The cheap RTLs have no heat sinking. Fine for 250k but at 2048k heat will be a problem (90°C at the chip surface). At 3200k I have killed some of my unfortunate receivers.
Just clip the case open and use a self-sticking heat pad to put a tiny heat sink on the R820T(2) -- the chip near the antenna port.

[phinnay]

Thanks for the tips on the RTL receiver, I'll make the adjustments!

Here is the device, power cycled 10 times and recorded:
device_id.zip

ed72742726ee0
e712622926e6900
e1d272280
ef12672a26e49c0
ee80
e280
efa2762526f4460
e7c26f2826e64c0
e6f2700
ec72722726e60

Here is 10 readings with low battery (2.5v)
low_battery.zip

1	72.1F / 39% / 29.50InHg
eaca6e272700

2	71.6F / 39% / 29.50InHg
eaca6c27270a780

3	71.4F / 39% / 29.51InHg
eaca6b272709760

4	71.4F / 39% / 29.51InHg
eaca6b2727087500

5	71.2F / 39% / 29.52InHg
eaca6a27270b7700

6	71.1F / 40% / 29.51InHg
eaca69282708740

7	70.7F / 40% / 29.50InHg
eaca67280

8	70.9F / 49% / 29.50InHg
eaca680

9	70.5F / 40% / 29.50InHg
eaca66282700

10	70.5F / 40% / 29.50InHg
eaca66280

[zuckschwerdt]

Very nice! This confirms TYPE:4h ID:8d FLAGS:2b TEMP_C:10d HUM:8d HPA:16d CHK:8h
With 8 bits of ID and with flag bits 00: "good", 10: low_battery, and 11: invalid reading/dead battery.
Did I already put code for that on a branch somewhere? Anyway, I'll implement this shortly.

[phinnay]

Teriffic! Looking forward to pulling the new version.

[zuckschwerdt]

Will take a few days, sorry.

[phinnay]

no problem, thank you so much for helping with this! rtl_433 is a great project.

[steepleian]

I was just wondering if there is any further progress?

[zuckschwerdt]

This will take more time to implement, the transmission is more intricate, sorry. Ping back in a week or two.

[steepleian]

Ok many thanks for the update.

…

Sent from my iPhone

On 23 Mar 2019, at 08:27, Christian W. Zuckschwerdt ***@***.***> wrote: This will take more time to implement, the transmission is more intricate, sorry. Ping back in a week or two. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[zuckschwerdt]

Support added with #1040. Reopen if you notice problems.

[slvrscoobie]

I have a Fineoffset-WH32B as well as 8 AmbientWeather-WH31E. The problem im running into is the newer version issues on April 7 now sees my AmbientWeather-WH31E devices as Fineoffset-WH32B devices but has bad data, and missing info. IE: the humidity is 171% on my one device, and it lost the 'channel' information which helped me understand which AmbientWeather-WH31E was which.

[zuckschwerdt]

The protocols are somewhat similar. The AmbientWeather-WH31E has a stronger checksum which will reject almost all bad data. The Fineoffset-WH32B might get false positives, but it should only (wrongly) decode the AmbientWeather-WH31E packets occasionally.
I'll have a look at the sample data you supplied with merbanan/rtl_433_tests#296

[zuckschwerdt]

Should be fixed with 78b7449