Why am I getting no ACKs from an nRF24L01p in PRx mode?

[JimR]

Hi folks, I'm making progress with a program to get two nRF24L01p modules communicating with each other, but there are a couple of remaining problems. I hope someone can help with them, please:

1. The PTX module seems to be transmitting my 3-byte payloads correctly, and the VDD_PA pin on that nRF24L01p pulses high (~2.0V) as expected. The PRX module even reports that it is receiving most packets from the PTX module (often 6 packets in a sequence, but then there's a 'timeout' reported). BUT the PRX module never seems to be sending back an ACK, and the PTX module consequently reports that no ACK has been received. The VDD_PA pin on the PRX chip never pulses high, either -- presumably because no ACK is being sent. Can anyone suggest what I'm doing wrong?
2. I'm puzzled as to why the PRX module reports that 6 successive packets have been received successfully, but then reports a timeout with no packet received. Then it will report that the next 6 packets were received, before reporting another timeout + no packet received. And so on. This sounds a bit like some sort of timing problem, but I can't work out exactly what. Any suggestions? Thanks, JimR

[JimR]

Hi again Torbjorn, Actually I probably made a mistake in providing that configuration info, so I want to make things a bit clearer. Since I'm using the same code in both the PRX and PTX modules, what I'm doing is calling the two modules Radio0 and Radio1, and then when a module is running as Radio0, I set its two pipe addresses to: RX_ADDR_P0: E7E7E7E7E7 and TX_ADDR: C2C2C2C2C2. then when the module is to run as Radio1, I set its two pipe addresses to: RX_ADDR_P1: C2C2C2C2C2 and TX_ADDR: E7E7E7E7E7. I'm so confused now that I can't decide if these are right or wrong. Can you please put me straight? Thanks Torbjorn, JimR

[ovrebekk]

Hi Jim

The one law of nature that you must abide by is that when either kit is in PTX mode RX_ADDR_P0 and TX_ADDR has to be the same. Otherwise the ACK's will never be received, and the PTX will assume that the PRX didn't receive anything.

I think the easiest way to do what you want is to simply set TX_ADDR and RX_ADDR_P0 on both sides to E7E7E7E7E7.

Using the same code for both devices can be a bit tricky, as you have to be careful with the timing when switching from PTX to PRX mode or vice versa. Are you planning to switch between PTX and PRX dynamically as the devices are running, or just once during startup?

Best regards
Torbjørn

[JimR]

Hi Torbjorn,

Thanks for that very helpful and clear answer. In my code I do allow a user to switch between PTX and PRX dynamically, although they would probably only do it once during startup -- just as the switch between Radio0 and Radio1. Is this likely to cause problems, and if so is there any way to avoid the problem? Thanks, Torbjorn.

[JimR]

Hi again Torbjorn,

This is just to advise that I changed the TX_ADDR and the RX_ADDR_P0 address for both devices to E7E7E7E7E7 as you suggested, and they are now exchanging data and ACKs nicely -- apart from a 'glitch' or two if they are swapped from PRX-->PTX and RTX-->PRX dynamically. Is that what you meant? If so, I believe it's acceptable. Thanks again for your help, Torbjorn! Jim R

[ovrebekk]

Hi Jim

If you only switch during startup it shouldn't be a problem.

The reason I brought it up is that I have seen people inventing 'clever' schemes to switch between PTX and PRX dynamically, in an attempt to support bi-directional data. The idea behind ESB is that you can use the ACK payload feature to support bi-directional data without having to change modes in this fashion.

The problem of switching is that you mess up the state of the protocol, and might lose any packets already queued in the TX/RX FIFO's, which might be the reason for the glitch you noticed. If you use the radio in legacy Shockburst mode, then switching from TX to RX is more straight forward, since in this mode there is no ACK'ing or retransmissions going on, and the state machine in the radio is much simpler.

Best regards