WEC-2103 checksum algorithm

[tommie]

#2185 added support for WEC-2103, by @tthurnreiter. It never received a resolution about the checksum.

I've spent some time figuring out the protocol of my cheap temp/humidity sensor, and it seems the protocol is identical. Here's a decoder: https://github.com/tommie/tx07k-reverse/

However, I think I also managed to figure out the checksum, though I can't be sure the WEC-2103 and my TX07K-THC (as written on the PCB) are the same. Looking at the WEC-2103 FCC internal photo, it's labeled TX07Y-THC, so very likely the same.

The checksum is a modified/broken CRC-4. I'd love to contribute that, but since I don't, technically, have a WEC-2103 to confirm this with, I'm not sure if it would be accepted. Seeking contribution guidance, or help confirming the checksum.

[zuckschwerdt]

Your findings look plausible enough and entirely what we expect from those implementations :)

Do the recordings in #2185 (comment) work with your checksum?
If so then just PR the addition.

[merbanan]

@tommie there are some signals and decoded messages you can test the crc-4 code with. One thing I'm not sure this is a broken crc-4 checksum.

rtl_433/src/util.c

Line 157 in 7a836e3

uint8_t crc4(uint8_t const message[], unsigned nBytes, uint8_t polynomial, uint8_t init)

compared to

https://github.com/tommie/tx07k-reverse/blob/3907833c7b46ba3116255916ddd04a8eebeb298a/tempdec.py#L28

it looks fairly similar. Maybe it just needs to be reflected? Ie poly 0x9.

[tommie]

Re. the CRC-4, the problem is the last operation needs to be an XOR, AFAICT. The normal CRC-4 ends with the shift, which doesn't align with my samples. Though I'm by no means a CRC authority. (I go into depth of this RE process in https://tommie.github.io/a/2023/10/reverse-engineering-checksum).

Confirmed the #2185 recordings pass CRC check.

[tommie]

For future reference, the #2185 recordings look like this in hexadecimal:

ec b 8 67b 66 1
ec 6 8 67d 66 1
37 f 8 657 61 1
37 2 8 664 61 1
37 f 8 664 61 2
37 0 0 664 61 3

None of them have batt-low set, but I'll assume it's the same as on my device.

[zuckschwerdt]

Reordering the CRC-4 in that way has the effect of "laging" the data behind:
The first operations don't do anything but change the init.
Then the data is pushed in (lagging behind the CRC ops), so only the next round processes the data.
The last chunk of data is never processed. The CRC stops short.

I'd say, compared to a normal CRC, this one is a nibble shorter and just xor's the last nibble (instead of CRC'ing it).
(note: that remainder ^= message[byte]; is an optimization, each bit would go in one by one with the conditional.)

[merbanan]

This is my interpretation also. The original implementation should possible to use with some light change of the logic.

[zuckschwerdt]

In other words this is equivalent (tested):

    int crc_received   = b[1] >> 4;

    b[1] = (b[1] & 0x0f) | ((b[4] & 0x0f) << 4); // The last nibble is moved here.

    int crc_calculated = crc4(b, 4, 3, 0) ^ (b[4] >> 4);

It could be that the original CRC used operates byte-wise and the "designers" wanted to patch on a last nibble ;)

[tommie]

Thanks for thinking and testing! I've updated #2662.