nRF24L01(+) RX ACK payload lost

[Janis]

I have problems with sometimes loosing ACK payloads from TX FIFO for RX device. My algorithm is:

1. config channel and other settings
2. clear status and FIFOs
3. upload new ACK payload
4. start RX by setting CE=1
5. wait for packet from TX device
6. RX_DR IRQ
7. Wait 15ms for ACK to be sent
8. stop RX CE=0
9. read received data
10. Repeat from 1.

For me normally TX_DS is never set for RX device, I assume because I restart RX mode. But sometimes I get TX_DS flag and ACK payload is discarded before sending ACK, so TX device receives only ACK, but without payload.

1. I need clarification on exactly when ACK payloads are removed. Datasheet writes, that: "The payload is pending in the TX FIFO (PRX) until a new packet is received from the PTX" What exactly is "new packet". Also if I exit RX mode (CE=0) and upload new ACK payload then enter RX mode, should next received packet still discard my payload?

2. What about TX side, would entering power down mode reset the PID counter for TX packets?

[Hung Bui]

Hi Janis, A new packet is a packet that has different CRC or PID from the previous packet. It's mentioned at page 29 in the nRF24L01+ Spec.

The PID field is incremented at the TX side for each new packet received through the SPI. The PID and CRC fields (see section 7.3.5 on page 30) are used by the PRX device to determine if a packet is retransmitted or new.

If you are in PRX mode and receives TX_DS flag, this mean:

• You've received a new packet from PTX
• You have added a payload into the last ACK packet, and that payload arrived successfully .

I don't think the PID will be reset by going back to standby mode CE=0.

If you going to transmit same payload packet, it's better to add one PID extra byte that can be controlled by the application. This will cause the CRC to change. And the L01+ will treat it as a new packet.

Note that we have 3 slots for ACK payload. You can queue up to 3 packets for ACK.

I don't really understand why you have to stop RX and start it again when you receive a packet.

Entering power down mode, on the other hand can do a reset for PID counter.

[Janis]

I would like to know the full rule on removing the ACK payload from RX device TXFIFO.

For instance if I flush TXFIFO and upload new ACK payload, then on next RX it stays and TX_DS is not set, but on subsequent RX it will be removed and TX_DS is set. It seems that nRF remembers if that payload was sent with ACK and only then it will remove it on next received packet. So it would seem that there is more to the condition then just if the recieved packet is new.

[Hung Bui]

Hi Janis,

I think it makes sense, the ACK TXFIFO is flushed before receiving the new packet from PTX means we don't care anymore about the ACK payload (and won't retransmit if old packet is received). So the TX_DS should not be triggered. But on the subsequent RX, when the ACK payload is ACKed properly, then it should trigger TX_DS and discard the ACK payload.

I assume that the bit which tells there is a ACK payload in the last ACK packet will also be cleared when we do a flush on TXFIFO.

To be able to confirm this behaviour and have insight information about this, I will try to get hold of our expert with nRF24L series. But I can't guarantee because the chip was designed more than 10 years ago.

[Janis]

Hi Yes, that makes sense. The problem is that in some rare circumstances I get TX_DS after TX FLUSH.

Anyway, hope you can get some more info.

[Hung Bui]

Hi Janis, I afraid that I don't have further information than what discussed. To be able to investigate more, could you provide an example code that can reproduce the issue that you mentioned "in some rare circumstances I get TX_DS after TX FLUSH" ?