PTX with dyn ack, sleep problem

RE: PTX with dyn ack, sleep problem

Jon Gunnar — Wed, 01 Mar 2017 09:37:41 GMT

RE: PTX with dyn ack, sleep problem

mr_creosote — Mon, 20 Feb 2017 15:25:18 GMT

Hi Håkon, Thank you! Best, Mahesh

RE: PTX with dyn ack, sleep problem

Håkon Alseth — Mon, 20 Feb 2017 13:25:19 GMT

Hi Mahesh,

Q1: Do you mean that if the PTX asks for ACK+payload, the PRX radio will AUTOMATICALLY send an ACK + the payload ALREADY in its buffer? The PRX CPU has NO control over this, correct?

Does this mean that calling hal_nrf_write_ack_payload(pipe, payload_data, length) on the PRX ONLY "uploads" the packet to the radio and DOES NOT actually send the ACK packet out? So it's best to have the PRX radio "primed" with the ACK packet as far as possible. Correct?

That is correct. The function call uploads the ack-payload to the chosen rf-pipe in the radio FIFO.

If you upload an ACK-payload to pipe 0 and pipe 1, they will only be transmitted (read: appended to the ACK going from PRX->PTX) when you receive a payload on each of these pipes. This means that if you never receive a TX-payload on pipe1, the ack-payload will remain there.

Q2: Thus, if no new ACK packet is uploaded to the PRX radio by its CPU, it will send the SAME ACK packet to the PTX over and over and over again. Correct?

No, that is not correct. If you upload one ACK-payload, this will be sent back to the PTX on the next received "payload #1". This will then be removed from the FIFO if the "PID" field in the "payload #2" has incremented, which indicates that this was not a re-transmitted payload.

Chapter 7.8 in the datasheet for protocol examples.

Q3: What do you mean by "this has to be updated to a specific RF pipe?" Shouldn't the PRX use the same pipe on which the RX packet was received to transmit the ACK packet?

See answer for Q1 for details on this. The command "W_ACK_PAYLOAD" command (which is the command used for ack payload) requires that you also set the RF pipe this should be addressed to.

Q4: Assuming that my understanding is correct, at 250Kbps, what delay would you recommend between the "ack packet prepare" and the "fetch ack payload" packets sent by the PTX?

You can send them back-to-back if you'd like. In gazell, we use a delay of a couple of ms between "ack prepare" and "fetch ack", in case the PRX is busy doing other processing.

Best regards,

Håkon

RE: PTX with dyn ack, sleep problem

mr_creosote — Mon, 20 Feb 2017 08:13:48 GMT

Assuming that my understanding is correct, at 250Kbps, what delay would you recommend between the "ack packet prepare" and the "fetch ack payload" packets sent by the PTX? Thanks, Mahesh

RE: PTX with dyn ack, sleep problem

mr_creosote — Mon, 20 Feb 2017 08:00:18 GMT

Hi Håkon,

Do you mean that if the PTX asks for ACK+payload, the PRX radio will AUTOMATICALLY send an ACK + the payload ALREADY in its buffer? The PRX CPU has NO control over this, correct?

Thus, if no new ACK packet is uploaded to the PRX radio by its CPU, it will send the SAME ACK packet to the PTX over and over and over again. Correct?

This is a race condition that could happen:

1. PTX sends a packet, asks for ACK+packet.

2. PRX radio raises an IRQ.

3. PRX CPU then (because of my code) starts assembling an ACK packet and then uploads it to the radio by calling hal_nrf_write_ack_payload, which uploads it using SPI.

4. In the meantime, PRX radio is AUTOMATICALLY getting ready to send out the ACK packet.

5. PRX radio sends out an ACK packet. The PRX CPU **may** have updated the ACK packet buffer in the radio before it was sent out... or not. Race condition, we don't know what will happen.

THUS, a good solution is to have PTX send a packet, notifying PRX that an ACK packet will be required soon. PRX then hurries up, creates a packet and uploads it to its radio by calling hal_nrf_write_ack_payload(). PTX now sends a second packet. PRX gets this packet too and since the ACK packet is already uploaded into the PRX radio's buffer, it is AUTOMATICALLY sent out with no interference from the CPU.

So, use the first packet to get the ACK packet ready. Then when the second packet comes, DO NOTHING, and the ACK packet will be sent out AUTOMATICALLY.

BTW, this is how I set PTX to ask for ACK + payload:

hal_nrf_setup_dynamic_payload(0xFF);// Enable dynamic payload on all pipes

hal_nrf_enable_dynamic_payload(1); //Enable Dynamic payload

hal_nrf_enable_ack_payload(1); // Enable ACK with payload

hal_nrf_enable_dynamic_ack(1); // need this to be able to get & read ack payload sent by prx.

D. What do you mean by "this has to be updated to a specific RF pipe?" Shouldn't the PRX use the same pipe on which the RX packet was received to transmit the ACK packet?

Thanks!

Mahesh

RE: PTX with dyn ack, sleep problem

Håkon Alseth — Mon, 20 Feb 2017 07:10:57 GMT

Hi Mahesh,

In order for the PRX device to send an ACK-payload, this has to be updated to a specific RF pipe.

If you are, on the PRX, uploading this to the radio at the time of receiving a packet, the hardware simultaneously controlling the radio and performing the RX->TX turnover. At this point, you have a race-condition between the CPU and the radio-hardware, and you're not guaranteed to successfully upload the ACK-payload before the radio has started transmitting the empty ACK.

This is the reason why case 3 will work. You send one TX-payload, the PRX is then able to upload the ACK, then you send a new TX-payload to fetch the ACK-payload.

Best regards,

Håkon

RE: PTX with dyn ack, sleep problem

mr_creosote — Fri, 17 Feb 2017 16:40:39 GMT

Hi Håkon,

I don't quite understand.

Case 2 is Wake, send 0, sleep, where PTX gets an ack but not the ack payload.

Case 3 is wake, send 1, send 2, sleep. where PTX gets BOTH the ack payloads ackp1 and ackp2 (which have different data in them).

Both case 2 and 3 end with send, sleep (for 2 seconds). Why would case 3 get ackp3?

In case 2, I've tried putting in a delay before sleep: wake, send 0, delay_ms(1000), sleep. Makes no difference.

Thanks!

Mahesh

RE: PTX with dyn ack, sleep problem

Håkon Alseth — Fri, 17 Feb 2017 10:17:52 GMT

Hi Mahesh,

It looks like your application relies on reading the data from the PTX, then bouncing the data back via ACK payload dynamically. In such a scenario you will have to send two payloads from the PTX to successfully receive the ACK-payload.

Case 2 does not work because there's not enough time for the PRX to upload the ACK payload. Therefore you must send another one to fetch the ACK-payload.

The recommended procedure is:

* PTX sends "ack payload prepare" to PRX

* PRX uploads ACK-payload

* PTX sends "fetch ACK-payload" command to PRX

* PRX sends ACK with payload back to PTX device.

Based on this, case 3 is the recommended procedure.

Best regards,

Håkon

RE: PTX with dyn ack, sleep problem

mr_creosote — Fri, 17 Feb 2017 07:20:22 GMT

Hi, I really need to get it done this week (deadline); I'd greatly appreciate it if you could send me a response today! Thanks!! Mahesh