Purpose of PPP field in nRF24L01+ W_ACK_PAYLOAD command?

[laneh]

In the mRF24L01+:

Unlike MultiCeiver mode, I have one TRX and multiple PRX units sending back ACK payloads.

In the PRX, what is the purpose of the PPP field in the W_ACK_PAYLOAD command? If the PRX returns an ACK packet using the same address it responded to, why would a pipe number matter?  Is the PPP field used only for MultiCeiver systems?

[Håkon Alseth]

Hi,

 

Just for reference, this is the section in the nRF24L01+ datasheet:

 

 

In the PRX, what is the purpose of the PPP field in the W_ACK_PAYLOAD command? If the PRX returns an ACK packet using the same address it responded to, why would a pipe number matter?  Is the PPP field used only for MultiCeiver systems?

The three least significant bits, valid from 000 to 101, specifically state which pipe gets the specified payload.

 

A receiver is able to control which address receives the ACK payload by specifying the pipe the data should be uploaded on.

If your PRX is talking to up to 6 PTX devices, then using the ACK payload specifically to one pipe makes sense; if not you wouldn't have control over which PTX device gets the payload back.

 

Kind regards,

Håkon

[laneh]

Hakon,

Thank you for this quick and helpful response. Your sentence, "A receiver is able to control..." cleared it up for me.

I've attached two diagrams to test my understanding of (a) one transmitter talking to one receiver and receiving its ACK packet, and (b) the same transmitter talking to many receivers at once in a "broadcast" mode. Would you please look these over and let me know if my understanding is correct? I think a diagram or two like this in an app note could clear up a lot of the online confusion I see about the nRF24L01+ which must be the most popular radio chip in the DIY community. My understanding of a "pipe" improved once I started regarding it not as a conduit over which data flows, but as an index into a table of addresses.

. 

[Håkon Alseth]

Hi,

 

Your understand looks to be correct in both scenarios, but:

In the case you are expecting an ACK payload, I would recommend that you split this into two on-air RF payloads.

This is because the radio hardware will immediately start to run the ACKing procedure, and if you at the same time try to upload using W_ACK_PAYLOAD on the PRX device, you might miss "the window" in which the PRX Radio sends. This window is only ~130 us before the PRX transmits its ACK, so the host microcontroller must work quite fast to upload this to the nRF24L01+.

The proposed scheme should look approx. like this:

1. PTX sends a "prepare ACK payload" command

2. PRX ACKs the on-air command, and ACK payload is written to the TX FIFO using W_ACK_PAYLOAD after reading out the payload

3. PTX waits for the TX_SUCCESS interrupt

4. PTX sends a dummy payload to fetch the ACK payload

5. PTX checks interrupt TX_SUCCESS and RX_DR interrupt sources.

Kind regards,

Håkon

[laneh]

Hakon,

Again thank you for a quick reply. 

I do understand that the receiver must pre-load the ACK packet and that is why my first diagram says the ACK payload "was loaded" to mean before receipt of the transmitted packet. This question was actually answered in a previous ticket.

My scheme is similar to your suggestion but uses less air time. The purpose of the "broadcast" address (pipe 1) and the transmitter loading the "...NO_ACK" FIFO for this address (pipe 1) is to tell every receiver at once to update its ACK payload. Then the transmitter can address each receiver individually to retrieve each receiver's ACK data. 

[Håkon Alseth]

Hi,

 

laneh said:

I do understand that the receiver must pre-load the ACK packet and that is why my first diagram says the ACK payload "was loaded" to mean before receipt of the transmitted packet. This question was actually answered in a previous ticket.

My apologies, I missed this. Its good to hear that you have control over the radio low level behavior!

 

laneh said:

My scheme is similar to your suggestion but uses less air time. The purpose of the "broadcast" address (pipe 1) and the transmitter loading the "...NO_ACK" FIFO for this address (pipe 1) is to tell every receiver at once to update its ACK payload. Then the transmitter can address each receiver individually to retrieve each receiver's ACK data. 

 This is a good solution, but be careful if one of the receivers doesn't catch the broadcast'ed payload.

 

Kind regards,

Håkon