FineOffset WH1080 868.3 branded WX-2008 not recognized by rtl_433

[pcossu61]

FineOffset WH1080 868.3 branded WX-2008 has FSK coding signal samples uploaded at rtl_433_test/WH1080/05 https://groups.google.com/forum/#!topic/rtl_433/tJ3U81aFiP0 tried to do some progress on https://triq.org/iqs/ but I am not into bit and byte codes Anyone could give me some help to decode the signals ?

[klohner]

The structure of this pull request seems a little malformed with the cu8 files in the root.

I couldn't get rtl_433 to parse these sample files. I thought something like this would work: rtl_433 -s 1000k -Y minmax -r g001_868.18M_1000k.cu8 -X n=WX2008,m=FSK_PCM,s=58,l=58,r=580 but it doesn't return sensible data.

However, I see the data in URH and could parse out the symbols there. Each signal seems to be 6 repetitions of a message, FSK, 58 samples/symbol. Here is a bitbench of these messages:

aaaaaa2dd4a9e0a6410a1100bb0cd900 [g003_868.18M_1000k] aaaaaa2dd4a9e0a93f0e1500bb0c3b00 [g001_868.3M_1000k] aaaaaa2dd4b9ea51054220c302455900 [g001_868.18M_1000k]

These messages do not seem to be formatted anything like how the fineoffset_wh1080.c driver expects messages.

[klohner]

The 2d d4 identifier after the preamble makes me think of the protocols listed in fineoffset.c, though. So maybe a9 is a family code for a protocol not recognized by that driver.

[merbanan]

    if ((br[1] >> 4) == 0x0a) {
        msg_type = 0; // WH1080/3080 Weather msg
    }
    else if ((br[1] >> 4) == 0x0b) {
        msg_type = 1; // WH1080/3080 Datetime msg
    }

|BBBBBBBB| Station ID / rolling code: Changes with battery insertion.

aaaaaa2dd4[a]|9e|(0a9)3f0e1500bb0c3b00
aaaaaa2dd4[b]|9e|a51054220c302455900

This is no coincidence. But applying the code logic give the wrong temperature values. If you skip subtracting the offset (400) you get a9->169 and the PR lists out temperature as 16.9. But the rest is most likely correct. @klohner do you have the time to add the needed support?

[klohner]

@merbanan I see what you mean. If I take the messages, replace the aaaaaa2dd4 preamble with ff and feed them as 88 bits to rtl_433, it looks like it recognizes the messages as valid WHx080 data with mostly sane values. Humidity and Clock seem accurate. Wind values seem within reason. The parsed temperatures seem particularly off.

$ rtl_433 -y {88}ffa9e0a6410a1100bb0cd9
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
model     : Fineoffset-WHx080                      Msg type  : 0             Station ID: 158
Battery   : 1            Temperature: -23.4 C      Humidity  : 65 %          Wind Direction: 270
Wind avg speed: 12.24    Wind gust : 20.81         Total rainfall: 56.1      Integrity : CRC

$ rtl_433 -y {88}ffa9e0a93f0e1500bb0c3b
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
model     : Fineoffset-WHx080                      Msg type  : 0             Station ID: 158
Battery   : 1            Temperature: -23.1 C      Humidity  : 63 %          Wind Direction: 270
Wind avg speed: 17.14    Wind gust : 25.70         Total rainfall: 56.1      Integrity : CRC

$ rtl_433 -y {88}ffb9ea51054220c3024559
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
model     : Fineoffset-WHx080                      Msg type  : 1             Station ID: 158
Signal Type: DCF77       Radio Clock: 2020-03-02T11:05:42                    Integrity : CRC

Besides the temperature issue though, fineoffset_wh1080.c expects OOK_PULSE_PWM signals instead of the FSK_PULSE_PCM signals from this WX-2008 unit.

Also, @pcossu61, you've detailed that the info you're receiving on the display unit is:

out_temp 16,9 C
out_hum 62 %
991.1 hpa
wind_dir west
wind_speed 9.3 - 13.8 knots

What is sensing the 999.1 hPa measurement? I don't see pressure as a value reported in the typical WH1080 signal. Are both average and gust wind speeds reported? The WH1080 message seems to contain both. Look at the fineoffset_wh1080.c code to see what messages from the sensor are expected to contain. Maybe there's a message type or flag for reporting pressure data that isn't coded for in a signal we haven't analyzed yet. Would you be able to play around with this command to see if you can get rtl_433 to accurately capture the messages from your device? Maybe try varying antenna setup, or the -Y, -s, or -f values until things look right.

rtl_433 -f 868.25M -s 1000k -Y minmax -X n=WX2008,m=FSK_PCM,s=58,l=58,r=580

Also, I think we'd need more quality .cu8 samples from this device along with the measurement values reported on the display unit for each to verify message parsing. Would you please provide? We need more data points. Also, this sensor throws at least two different message types and we'd want to know if it throws any others.

@merbanan, what's the thoughts behind why fineoffset_wh1080.c and fineoffset.c are kept separate? Do you feel there's advantages to combining all the fineoffset code into a single driver file? I'd imagine one driver file with multiple r_device definitions for the various OOK_PULSE_PWM and FSK_PULSE_PCM signal transmissions, leveraging common code for parsing and validating what appears to be variations on similar messages.

[merbanan]

@klohner remove the -400 thing and the temp will be correct.

[klohner]

@merbanan I understand that looks true for this example. But how are negative temperatures represented in the message? How are pressure values transmitted? Does the message contain any flags that would let me know when the temperature value should and shouldn't have -400 subtracted to differentiate the message from other WH1080 messages which expect this? I'm not sure I understand all the nuance behind it yet.

[merbanan]

@klohner negative values most likely have the msb set. But yeah we need to get real samples to be sure. And regarding merging both files, I am afraid of regressions but if you are sure that both files can be merged then go ahead with the cleanup work.

[merbanan]

@klohner one obvious way to differentiate is to do it based on the device callback.

[klohner]

Yes, I imagine that's one way to do it. Sorry, I don't have the time to add the needed support.

[zuckschwerdt]

If there isn't any code to share I'd prefer to have smaller decoder units and not one big file which lumps everything together. Good reasons for multiple decoders per file are e.g. OOK and FSK version of the same protocol.

[gareth-ellis]

I am having the same issue - that I have a wh1080 whos messages dont match what rtl_433 can decode - they appear to match what @pcossu61 sees on theirs though. Mine is a clas ohlson wh1080.

I'm quite keen to get this working - if some pointers can be given I don't mind having a go and see if I can get this working

[merbanan]

I'll fix support but I need better samples and corresponding reference readings. Can you produce that and send a PR to rtl_433_tests ?

[gareth-ellis]

@merbanan sure will try and get that sorted tomorrow!

[merbanan]

Was able to demod the samples from the thread with rtl_433 -Y minmax -s 1000k -A -r g003_868.18M_1000k.cu8 -X n=WX2008,m=FSK_PCM,s=58,l=58,r=5800,preamble={24}0xaa2dd4.

a9e0a6410a1100bb0cd900.........

But looking at the pulses it is clear the pulse recovery code is not working properly but as it recovers the bits we can create a decoder.

[gareth-ellis]

@merbanan Does that mean you don't need the better samples?

[merbanan]

If I get proper samples I no longer have an excuse to not add the support. And proper samples is a requirement for adding the decoder. So it all depends how much you want the support.

[gareth-ellis]

I wasn't sure if you're most recent comment was saying that you had what you needed - I will sort the samples out

[merbanan]

I lied. I always want more samples.

[merbanan]

Added in 2706e4221bd909a2376d90c94d98dbd367b47214