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

[ggallant]

In the past I used to have the base station poll the remotes every 20msec and use the ACK payload to contain data from the remotes. If the remote did supply data in the ACK payload I cut the delay to 5msec to increase the data transfer rate. I used an 8bit sequence number to identify packets and could detect missing or duplicated messages. This solution was not optimal. I might revisit it now that I a better understanding of the radio.

What I could easily do is add a minimum delay (2msec) after receiving a message to allow the remote to rapidly process multiple TX payloads without collisions. In my environment the base station needs to be able to tell the remote to stop transmitting. Perhaps the ACK payload could be used. This will require some thinking.

I have a 100% data completion with a few MAX_RT interrupts per 10,000 messages.