Calculation of CRC in Frame Check Sequence (FCS) field of IEEE 802.15.4

RE: Calculation of CRC in Frame Check Sequence (FCS) field of IEEE 802.15.4

Kenneth — Tue, 23 Apr 2024 14:33:05 GMT

Thank you for sharing the details to make this work!

Kenneth

RE: Calculation of CRC in Frame Check Sequence (FCS) field of IEEE 802.15.4

fabian2 — Tue, 23 Apr 2024 13:12:42 GMT

Hello Kenneth,

Thanks for the fast response. I was able to solve my issue and it was indeed related to endianess on bit level!

Furthermore, I have found a different blog post about the CRC topic on the nRF in ESB CRC calculation

To re-calculate the CRC of the payloads, that I have provided in the upper table, I have tried out different algorithm implementations. However, it makes more sense to test at first with bit-symmetric payloads, i.e, 0xE7 = 11100111 or 0xFF to make sure that we don't face any endianess issues.

With these test payloads, I identified that the big-endian version of the CRC algorithm in RIOT OS works as the one on the nRF.

https://github.com/RIOT-OS/RIOT/blob/master/sys/checksum/ucrc16.c#L26

(Maybe interesting ... there are corresponding unit tests demonstrating the use of the algorithm, too: https://github.com/RIOT-OS/RIOT/blob/0dc150f3fbc5cc7bf050a8bf209298d430e23bab/tests/unittests/tests-checksum/tests-checksum-ucrc16.c)

When using this CRC16 algorithm and poly set to 0x1021 and seed set to 0x0000, I was able to reproduce the CRC values of the nRF for bit-symmetric payloads.

Since my test-script ran on a little-endian based system, the payload had to be converted bit-wise, i.e., a 0x01 payload corresponds to 0x80 input of the algorithm.

This helped me to re-calculate the CRC values in the FCS field of an IEEE 802.15.4 frame transmitted among nRF nodes.

RE: Calculation of CRC in Frame Check Sequence (FCS) field of IEEE 802.15.4

Kenneth — Mon, 22 Apr 2024 13:30:11 GMT

Hello,

As you write, this is handled in hardware and not something we usually are much involved in. Tyically we configure the radio, and the hardware does the rest. I don't have any indication this is done wrong. The common problem with calculating crc in software is related to endianess, seed and what data it should be calculated over (e.g. should the address be included, is there any data related to length that is not directly part of the payload etc).

So for instance a payload of 0x01 might be either 0000 0001 or 1000 0000 depending on endianess on bit level.

Kenneth