Using NRF24L01 without CRC

Using Arduino Programming Questions
1

Hi,

I'm back here to get rid of another (and I hope one of the last) problem I have on my project.
I'm trying to send a message from a Uno (Tx) to a Nano (Rx) wireless. I therefore use two NRF24L01 modules to communicate between the Arduinos. Everything is working well, until I try to disable the CRC implemented in the NRF24, and the auto-ack at the same time.

When disabled, I receive no more. I don't really understand what the auto-ack is, and I just want to transmit the message with my own CRC algorithm (which works well). Do you know how I can disable CRC/auto-ack and still receive the message sent ?

Thank you

2

It is used to send an acknowledgment message from the Rx back to the Tx indicating that a message has been received. This can be used with a timeout at the Tx to resend a message or take other actions if it is not acknowledged by the Rx

3

I had no problems switching CRC off on the receiver side,
it is needed to analyze data, or sniff for addresses and smaller packets.

If you want to have a special own CRC, just add it to your packet and use the usual CRC on top.

If you disable CRC, I doubt any automatic ACK is possible.

4

What is the problem with the NRF24 CRC ?

If you disable CRC at TX and RX, then reception works, no problem switching it off here either.

5

Keep in mind that you have no protection for bit errors of any length,
and will probably 'receive' junk packets, if just the pipe address is seen.

6

Sure, but I see no compelling reason to turn it off in the first place.

7

One legit application, is getting as close to promiscuous mode as possible.

If you set up 2 byte addresses, and set the top byte to the correct preamble byte,
you can receive packets to all pipe addresses that start with a specific byte.
Six addresses with the same MSB can be scanned at the same time.

For this, you need to disable the CRC.

8

Thanks for your answers,

I added my own CRC to the packet. The point is, I actually need to prove that my algorithm works. Which means, I have to send messages with and without CRC (my own) and compare the number of errors. If it seems strange to you, let's say it is purely academical.

Well, it doesn't work for me. As soon as I disable auto-ack and CRC, Rx Output is an empty byte, whereas it is exactly what I expect when auto-ack/CRC is enabled.

9

For testing the algorithm, I would introduce errors on the sending side,
while using the built-in CRC to deliver that deliberately damaged packet intact to the receiver.

The setup I used for the sniffer was

void radioSetup() {
  printf_begin();
  radio.begin();
  radio.setChannel(radioChannel);
  radio.setDataRate(radioSpeed);
  radio.setAddressWidth(adrBytes);
  radio.setPayloadSize(packetSize);
  radio.setAutoAck(false);
  radio.disableCRC();
  setupAddresses();
  radio.startListening();
}

void setupAddresses() {
  for (byte i = 0; i < 6; i++) {
    if (i < numAdrs) {
      radio.openReadingPipe(i, adr + adrBytes * i);
    } else {
      radio.closeReadingPipe(i);
    }
  }
}
10

I agree and I did something very similar for LoRa recently.

At a basic level it was to do with being able to have a 'relaible' packet, one that the receiver could be sure was destined for it, rather than from some foriegn source, and thus had invalid data.

A CRC of the data payload was appended to the end of the packet. The receiver could then generate its own CRC of the payload and compare it with the one appended to the packet end.

Checking for errors was easy enough, just alter the payload or appended CRC just before transmit or just after receipt to see if the error was detected.

Normal CRC checking was left on, why would you want to check your added CRC if the packet was aleready corrupt ?

11

If there is no RX, surely there is RX output at all ?

It would be odd for the designers of the NRF24 to include a no CRC option if it did not work.

12

It returns an empty byte.

But I'm then unable to get stistics on the failing rates or the to evaluate which settings are making the signal worse. I'll remember it though, if I can't have it work without.

13

There are no empty bytes, sorry.

There is no access to the reason a packet is dropped, to see CRC errors,
but the number of retries gives an estimate of the connection quality.

14

I use Python to receive, print, and store the messages, as for my CRC and a Huffmann code algorithm. WHen I ask Python to return what the Rx has received, it rteturns an emty byte. With auto-ack on, it returns what I expect.

15

There are no empty bytes in Python also, there could be an empty byte array.

But I'm not familiar with the Python NRF24L01 driver.

Good luck.

16

As has been pointed out, there is no such thing as an 'empty byte'

A byte has a decimal value of 0 to 255 and 0 is a valid byte, it is not 'empty'

If you are receiving a byte whoes value is 0, then that is the byte received, suggesting that RX has actually worked.

17

Well, it has nothing to do with the Python driver, since it works with the NRF24's CRC.

I don't know what decimal value is attached to this byte. What I can tell is that a byte object in Python is written b'value' and, with auto-ack off, Python returns b''.

18

No idea, Arduino is programmed in C++.

Perhaps try TX and RX as Arduinos first.

19

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.