Method to detect AA has completed?

[pico]

Is there a method to determine if a receiving nRF24 device has completed the ACK (assuming AA is enabled on both transmitting ang receiving devices)?

I ask because I was tracking down a subtle problem where in response to a message, I was performing some configuration actions which included resetting the TX and RX0 addresses on the receiving device. I discovered that doing this too quickly was effectively killing the ACK from the receiving device to the transmitting device, and so the the transmitting device did not see that the message had been received correctly even though this was the case. This had me scratching my head trying to figure out what the problem was. I found that putting a fixed delay in the code of 6500us before resetting the TX and RX0 addressing worked as a crude fix, but this is not ideal, as the code is in an interrupt handler.

I had another look through the datasheet to see if I could spot any discussion of the issue there, but couldn't see it.

Is there a known minimum time documented anywhere you need to allow to ensure not interfering with the AA response? I know the 6500us is excessive, it was just a hack to test the hypothesis of what was going wrong. Or alternatively is there a flag that can be tested somewhere that tells the AA has in fact completed? More generally, is there a way to ensure you never clobber the AA of an incoming packet when setting the TX/RX0 addresses? I was a bit surprised to discover the device doesn't actually handle the issue itself, as the AA response is otherwise fairly invisible. Thanks for any advice and insights.

[brennen]

Looking at the datasheet, I don't see any hardware based method to make sure you don't clobber the return ACK from the RX after you receive the RX_DR interrupt. If you read the PRIM_RX bit during this time, does it read as TX (0) or RX (1)?

To implement a time-based wait in software to acheive this end, then the datasheet gives the calculation for Tack:

Code: Select all

Tack = [(8 bits / byte) * ((1 byte preamble) + (3/4/5 byte TX address) + (N byte ack payload) + (1/2 byte CRC)) + (9 bit packet control field] / [250 kbps/1 Mbps/2Mbps air data rate]

Assuming you are using a 5-byte address, no ack payload bytes, and a 2-byte CRC, the number of ack bits is 8 * (1 + 5 + 0 + 2) + 9 = 73 bits. Then, assuming you're using a 2 Mbps data rate, divide the number of ack bits by 2,000,000 bits/second to get the the delay you need, which turns out to be 36.5 microseconds. You would probably want to round that up ot 40 or even 50 microseconds to make sure to give some slack time to the L01.

[pico]

If you read the PRIM_RX bit during this time, does it read as TX (0) or RX (1)?

Good idea: I'll try polling for changes in this flag to see if that can be reliably used to determine state.

To implement a time-based wait in software to acheive this end, then the datasheet gives the calculation for Tack:

And thanks for this, it gives at least a principled approach to selecting the time delay, which is better than just hacking. I'm using 1MHz, so I've selected a delay value of 100us, and a quick test indicates that seems to work OK. It would be nice to come up with a method usable across all data rates. (Well, I suppose using a worst-case value of something like 400us would work even for 250KHz!)

I will try the polling method and get back if there are any usable results.