nRF24L01 Radio: R_RX_PL_WID returns 0

Hello,

I am a developer/maintainer for the RF24 Arduino library at https://github.com/nRF24/RF24

I've found in some cases, the R_RX_PL_WID register returns 0 while the FIFO_STATUS register indicates there is a payload in the FIFO. (returns 0x10)

At this time the STATUS register returns 0xE, indicating RX FIFO is empty

The only way I've found to recover from this issue is to flush the RX buffer with the FLUSH_RX command.

I am wondering

a: If this is a known issue, it seems very similar to the issue where R_RX_PL_WID returns >32

b: If it is known, what is the probable cause &/or prevention? Could it be a software interaction/SPI related issue or is this a NRF24L01P issue?

Testing on Raspberry Pi shows numerous errors in short periods of time (hours) when doing continuous, large data transfers.

I am having trouble recreating the issue on Arduino based devices, but monitoring to see if/when it happens.

I have tested with various radio modules, connectors, hardware etc, and the issue still pops up. Low power modules, high power modules, etc. from various retailers.

Any input on this would probably be helpful.

The old code:

    uint8_t result = read_register(R_RX_PL_WID);

    if (result > 32) {
        flush_rx();
        return 0;
    }
    return result;

The new code:

    uint8_t result = read_register(R_RX_PL_WID);

    if (result > 32 || !result) {
        flush_rx();
        return 0;
    }
    return result;

Parents
  • Hi,

    We are not really providing any support on the nRF24L-series anymore, but I can try to comment a bit anyways:

    Is all the communication here 1:1, or is it possible that you have more than one receiver/transmitter sharing the same TX or RX address during this test?

    Also, are you 100% sure these are genuine nRF24L01+devices? Unfortunately there are a lot of fakes one out there, with identical marking, so the only way to really be sure is either x-ray or make sure you have bought them through a Nordic distributor.

    In any case, I can't really see any problem with your workaround.

    Kenneth

  • Hi,

    All the communication is 1:1 with very little, if any chance that devices are sharing an address directly.

    I've tested this pretty extensively. I believe that, technically, with Auto-Ack enabled, the devices temporarily 'share' an address when the device is switching between TX & RX modes, but that is all handled internally essentially. This is where I suspect the problem is taking place, during the switch from TX to RX and back.

    I did purchase some E-Byte E01-2G4M27D recently through official channels, trying to get some genuine hardware, and they do the same.

    With the volume of nRF24 hardware I have, I would assume that some are genuine.This issue even occurs with the really horrible knockoffs, like SI24R1.

    The nRF24s are still very popular in the Arduino community, as they became somewhat of a standard for wireless communication years ago, and there hasn't been anything outside the newer nRF52, nRF54, etc, that can match the nRF24.

Reply
  • Hi,

    All the communication is 1:1 with very little, if any chance that devices are sharing an address directly.

    I've tested this pretty extensively. I believe that, technically, with Auto-Ack enabled, the devices temporarily 'share' an address when the device is switching between TX & RX modes, but that is all handled internally essentially. This is where I suspect the problem is taking place, during the switch from TX to RX and back.

    I did purchase some E-Byte E01-2G4M27D recently through official channels, trying to get some genuine hardware, and they do the same.

    With the volume of nRF24 hardware I have, I would assume that some are genuine.This issue even occurs with the really horrible knockoffs, like SI24R1.

    The nRF24s are still very popular in the Arduino community, as they became somewhat of a standard for wireless communication years ago, and there hasn't been anything outside the newer nRF52, nRF54, etc, that can match the nRF24.

Children
  • Is 16bit crc used? Do you have any indication that there is much packet loss here in general when the issue occurs?

    The only thing I can think of in terms of root cause is the ack, that it somehow start to "ack the ack", but I would not expect that to happen in a 1:1 situation. But if you were having two receivers and one transmitter, and then one of the receivers missed the packet from the transmitter, but received the ack from the other receiver, it may potentially (if I remember correctly) get into a situation of "ack the ack" of the other receiver, it may have problems getting out of this situation (the ack is normally 0byte). 

    Kenneth

  • Yes, 16-bit CRC is enabled when the issue takes place.

    Yes, the issue is more readily apparent when 3 devices are introduced, but can still occur when only two devices are used. The issue became untenable when doing large data transfers between Linux/RPi devices over a TCP/IP connection via nRF24 radios. For a number of years, I was investigating SPI/Software interaction issues, and eventually narrowed the 'hangs' I was experiencing down to this issue. The transfers are 1:1 direct transfers, using Dynamic Payloads, AA and 16-bit CRC.

    Then I began testing with 1:1 communication and Arduino devices, and although the issue takes longer to occur, it still occurs. I suspect it is because of a difference in timing between real-time micro-controllers and a multi-tasking Linux system.

    After years of investigation, I am still uncertain as to whether this is a nRF24 hardware related issue, or somehow related to the RF24 driver and our software/SPI interactions.

Related