Does RF24 lib and nRF24L01+ enforce CRC integrity?

Projects Networking, Protocols, and Devices
1

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?

2

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.

Pete

3

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).