This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF24L01+ sending ACK with payload that was clocked with W_TX_PAYLOAD command

Hello, I have a weird problem, the nRF24L01+ is sending a TX PAYLOAD that was left in the TX FIFO (clocked with W_TX_PAYLOAD) as an ACK PAYLOAD when switching to PRX mode.

I have a one PTX device trying to send payloads to an device that is turned off. It makes a an attempt to send but if it fails (no ACK received) I leave the payload in the FIFO (to try to send later without the need for clocking the payload again) and then it goes to PRX mode for some time, then it tries to send, so according to the specification just having CE = 1 it tries to send again.

I am sure I have disabled EN_ACK_PAY (Payloads with ACK) in the FFEATURE register, also the payload being sent ask ACK Payload was clocked with the W_TX_PAYLOAD command, not with the W_ACK_PAYLOAD command.

Are there any undocumented issues issues leaving data at the TX FIFO as PTX mode and then going to PRX mode?

In page 33 it says:

*An ACK packet can contain an optional payload from PRX to PTX. In order to use this feature, the Dynamic Payload Length (DPL) feature must be enabled. The MCU on the PRX side has to upload the payload by clocking it into the TX FIFO by using the W_ACK_PAYLOAD command. The payload is pending in the TX FIFO (PRX) until a new packet is receivedfrom the PTX. nRF24L01+ can have three ACK packet payloads pending in the TX FIFO (PRX) at the same time.*

So it says that any payload that is going to be attached to an ACK

MUST
be clocked with the W_ACK_PAYLOAD command. I'm not even using this command, I'm just leaving an unsuccessful payload in the TX FIFO to try to retransmit later, I don't want to use it as an ACK Payload, I don't even have the EN_ACK_PAY feature enabled!

Paying much attention to the

Fig. 11 PRX Operation in Enhanced Shockburst
flow diagram in page 37 it says that when sending ACK
it just checks if there's pending payload in TX FIFO to send ACK with or without payload
. This would explain this behavior, but why doesn't it check if the EN_ACK_PAY feature is enabled?

Anyway I've resolved the problem by flushing the TX payload if I decide to go to PRX mode and when trying to send it later just clock it again. But now, the problem is that the PID in the Packet Control Field will now be different for the same payload (because was clocked again) and in the PRX I might net repeated payloads if one or more ACKS were lost. Leading me to re-create this functionality in firmware, which will be very inefficient as an additional CRC or other checksum scheme will be needed. If just the PRX Operation take into account the EN_ACK_PAY bit deactivation, this wouln't be necessary.

Parents Reply Children
No Data
Related