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;

  • Hi,

    I am checking this internally with the team and will get back to you as soon as I get an update.

    Regards,

    Priyanka

  • Hi, just wondering if any further information has become available regarding this issue?

    The main question I still have is whether this issue relates more to the nRF24 hardware itself, or could be triggered/caused by some sort of software or SPI interaction.

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

  • 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

Related