Although two different people have reverse engineered the wireless protocol used by these wireless temperature sensors, they've both ignored the checksum. While that's fine from the perspective of "at least I got the data out," it's not good enough for me. RF is messy; checksums are useful. I'd like to understand what the checksum is, so that I'm relying on more than just parity bits.

First stop: assuming it's a CRC.

Plain CRCs obey a mathematical constraint -- if you XOR the plaintext by a given value, that causes a specific XOR change to the output. So if data (D) is modified by (A) to generate CRC (C) with modifier (B):

D1 ^ A1 = C1 ^ B1

D1 ^ A2 = C1 ^ B2

Then it should also be true that

D1 ^ A1 ^ A2 == C1 ^ B1 ^ B2

If that relationship doesn't hold, then it's not a standard CRC implementation.

Well, I picked three messages, determined their xor'd differences, and found that this relationship was true for those messages. So I spent a couple of hours trying to divine what the polynomial might be, on which that CRC is based.

As a quick aside: I stumbled across RevEng http://reveng.sourceforge.net/ - which I'd not previously seen. Looks interesting.

Sadly, that was all a red herring. I finally decided I should take a look at other checksums, and starting with what I thought would be the simplest one - a modular checksum - I found that the checksum on these packets is no more than adding up all of the bytes in the packet.

Wow, what a waste of time. :)

I'm baffled by the combination of parity bits (as the high bit of each byte) and a simple modular sum byte at the end. A typical modular checksum uses the two's complement of the added bytes, so that the implementation can just add up all of the bytes of the packet, and expect to get a final result of 0. This implementation seems to just make more work for the receiver. It feels a lot like it was implemented by someone that had little experience with RF protocols.