Search code examples
checksumcrccrc16boolean-polynomials

Unable to get the correct CRC16 with a given Polynomial

I'm struggling with an old radiation sensor and his communication protocol.
The sensor is event driven, the master starts the communication with a data transmission or a data request.
Each data telegram uses a CRC16 to check only the variable data block and a CRC8 to check all the telegram.

My main problem is the crc16, According to the datasheet the poly used to check the data block is:
CRC16 = X^14 + X^12 + X^5 + 1 --> 0x5021 ??

I captured some data with a valid CRC16 and tried to replicate the expected value in order to send my own data transmission, but I can't get the same value.
I'm using the sunshine CRC calculator trying any possible combination with that poly. I also try CRC Reveng but no results.

Here are a few data with the correct CRC16:.

    Data    | CRC16 (MSB LSB)
14 00 00 0A | 1B 84
15 00 00 0C | 15 88
16 00 00 18 | 08 1D
00 00 00 00 | 00 00
00 00 00 01 | 19 D8
00 00 00 02 | 33 B0
01 00 00 00 | 5A DC
08 00 00 00 | c6 c2
10 00 00 00 | 85 95
80 00 00 00 | 0C EC
ff ff ff ff | f3 99

If I send an invalid CRC16 in the telegram, the sensor send a negative acknowledge with the expected value, so I can try any data in order to test or get more examples if needed.

if useful, the sensor uses a 8bit 8051 microprocessor, and this is an example of a valid CRC8 checked with sunshine CRC:

CRC8 = X^8 + X^6 + X^3 + 1 --> 0x49
Input reflected   Result reflected

    control byte    |    Data   |CRC16 |  CRC8
01 0E 01 00 24 2A 06 ff ff ff ff f3 99 |-> 0F

Any help is appreciated !

Solution

  • Looks like a typo on the polynomial. An n-bit CRC polynomial always starts with xn. Like your correct 8-bit polynomial. The 16-bit polynomial should read X16 + X12 + X5 + 1, which in fact is a very common 16-bit CRC polynomial.

    To preserve the note in the comment, the four data bytes in the examples are swapped in each pair of bytes, which needs to be undone to get the correct CRC. (The control bytes in the CRC8 example are not swapped.)

    So 14 00 00 0a becomes 00 14 0a 00, for which the above-described CRC gives the expected 0x1b84.

    I would guess that the CRC is stored in the stream also swapped, so the message as bytes would be 00 14 0a 00 84 1b. That results in a sequence whose total CRC is 0.