Issues with Ecowitt WH53 temperature sensor

[jpmv27]

I recently purchased an Ecowitt WH53 temperature sensor from AliExpress.
Considering the source, it is possible this is some sort of "clone" rather than a genuine unit.

What I observed is that, for the first few hours after I powered it on, valid messages were only
54 bits long instead of the expected 55 bits. But if I strip off only six bits instead of seven, then the
rest of the message is formatted as expected.

After a few hours uptime and a period of transition, the message length has stabilized at 55 bits.

However, I am also observing that the message header (the first six or seven bits) is sometimes all
'1' bits, but just as often the first bit is '0' and the remainder are all '1'.

In summary, if I strip off 6 or 7 bits depending on the bit length and ignore the header value
check, these messages all decode correctly, including the CRC check.

Does this sound like an issue with my WH53, or is there something in the decoding that
could account for these issues at the start of the message?

[zuckschwerdt]

Sounds like reception problems, but that is expected really. We should likely not demand a full 7-bit "header" but instead look for, say 4 1's and the model code 0x53 to be more reliable.

E.g. something like

    uint8_t const preamble[] = {
            0xf5, 0x30 // preamble and model code nominally 7+8 bit, look for 12 bit only
    };

    int row = 0;
    // Find preamble
    unsigned start_pos = bitbuffer_search(bitbuffer, row, 0, preamble, 12);

[jpmv27]

Thanks. I'll come back with a PR in a few days.

[ProfBoc75]

Hi @jpmv27 : FYI I already updated the decoder, if you want I can open a PR.

Notice that with this approach with the preamble we have a better result, 6 decoded messages instead of 4, tested with the cu8 samples from rtl_433_tests

[jpmv27]

Salut @ProfBoc75

You can go ahead if you wish.
In my change, I am also accounting for the 54-/55-bit packet issue I mentioned, with 6-/7-bit header respectively,
so my change is a little different than what @zuckschwerdt proposed.