Detecting the difference between TX and ACK payloads.

[ggallant]

I have two nrf24l01+ modules communicating on a single channel. The "remote" does 99% of the data transmission while the "base" receives and uploads to a host. Occasionally the base station transmits a short packet.

The remote is configured to auto retransmit with the max delay(15) and count(15) plus it will reuse the current TX buffer on MAX_RT. The base is configured with a delay at slightly more than half(9) and will flush the TX buffer on MAX_RT. No data is transmitted in the ACK payload.

A data message is about 70 bytes and typically requires three nrf variable length transmissions. The data message contains a sequence number. The data itself does not change very rapidly so multiple messages are alike. Everything is working great unless the base station does a transmit gets a MAX_RT interrupt.

At which time: One or more of the 3 remote buffers is lost. or The last TX payload appears to be retransmitted.

I read a posting about the TX payload being used as the ACK payload and I could envision this being the same bug. Is there any way for the receiving module to distinguish being transmitted via the TX payload vs the ACK payload?

I am considering adding a unique sequence number and command code to every packet and implementing a protocol where packets can be retransmitted upon demand. Something I hoped the nrf24l01+ would have handled in hardware.

[ggallant]

No quite. The remote is transmitting messages every 50msec. Each message typically requires 3 packets. Sometimes it uses 4 with a very short first packet. That is as expected. The base station ACK's without data in the payload. The remote reuses the prior FIFO if MAX_RT is asserted. Eventually all data arrives correctly. I have transmitted 200K messages with detecting an error. Usually the base and remote are with 100cm of each other.

If the base unit transmits a packet and gets MAX_RT asserted I flush the TX FIFO's. At this time receive FIFO's at the base module seem to misbehave.

From reading other posts on this site regarding ACK problems I have switch from using Pipe 0 to using Pipes 1 and 2 for data and Pipe 0 for ACK data only. As I am not expecting and ACK data I have set traps to report this condition. Since the change I have had flawless data transfer.

[Håkon Alseth]

Sorry for the late reply. If you switch the base-station over to TX operation (PTX), and start transmitting to the remote control, you will need to time-multiplex your remotes. If the remote(s) are still in PTX mode, the transmission from the base-station can be interpreted as an ACK, and the application will misbehave.

I would recommend using ACK payloads for exchanging data from the base-station to the remote.

Cheers, Håkon