Go Down

Topic: Does RF24 lib and nRF24L01+ enforce CRC integrity? (Read 1 time) previous topic - next topic


I'm using a network of nanos communicating with RF24 lib and nRF24L01+ transceivers. The solution is designed to collect data from a network of sensors, some of which are not in direct contact with the collector.

It's basically working. The nanos self-organise into a tree structure and collaborate to pass sensor readings back to a central collector.

As expected, radio reception isn't always perfect and some messages get lost. That's no problem.

But what I've noticed is that quite often, after a message has got lost, the recipient will receive another message containing a payload of almost all zeroes, just with a few bits set. Now, receiving garbage isn't a surprise. There's all sorts of noise and retries and retransmissions going on and plenty of ways to get bogus data after the start of a frame that looked valid. But what surprises me is that so many of these packets get passed back to the sketch. I have not configured the CRC, which I believe means that 16 bit CRC is selected. It seems odd that so many of these bogus messages would have a valid CRC. The number of bogus messages is very close to the number of lost messages and I suspect that in fact I'm seeing every message received, valid CRC or not.

What happens to incoming packets - is the CRC actually checked?


According to the docs you can use RF24::getCRCLength() to find out what the library is using.
The function will return:
RF24_DISABLED if disabled or RF24_CRC_8 for 8-bit or RF24_CRC_16 for 16-bit

If you are seeing so many errors it's unlikely that CRC checking is on - or to put it another way, it'll be really hard to explain those bad packets if CRC is in use.

Don't send me technical questions via Private Message.


The initialisation code appears to set 16bit CRC as the default, and I haven't set it explicitly. Dumping the radio status suggests that it's still using the defaults (1Mbps, hi power, 16 bit CRC).

Go Up