NRF52 - ESB - Receiving duplicate packets

[nordicfreak]

We are having some issues with ESB, it seems the automatic ACKs are not working properly and we get spammed with a lot of duplicates.

We believe the issue is because we start some function immediately when NRF_ESB_EVENT_RX_RECEIVED is triggered and because of this it doesn't have time to send an ACK.

How can we delay without blocking the CPU before starting our function?

This seems to work but is it the best way?

//event triggered

for(int i=0; i<50; i++){
nrf_delay_us(10);
}

//start function

[Kenneth]

Hello,

Typically the ESB run on relative high priority, so even if the application may be executing code with lower priority it should not affect the ESB libray handle the transmisson of acknowledgements. 

If you have enabled ack you should allow sufficient time (e.g 500us) on reception of packet to ensure ack can be sent out. If you don't care about ack, it is possible to disable ack when transmitting the packet.

Kenneth

[nordicfreak]

Hi,

I added a 1ms delay before processing the RX events, and I still get duplicates

[Kenneth]

And you are not starting and stopping rx here at any time? e.g. nrf_esb_start_rx()/nrf_esb_stop_rx().

Kenneth

[nordicfreak]

Check line 100 in RX code.

[Kenneth]

Try to remove that, keep rx allways on. Or at least remove the ESB disable/enable part. When you disable/enable ESB you like also remove the info of the last received packet info, thereby it think it is a new packet.

Kenneth

[nordicfreak]

even when switching to tx mode?

[Kenneth]

If the PRX want to send data to the PTX, then it don't disable esb or switch to tx, it simply call nrf_esb_write_payload() while in rx mode, then the packet will be appended to the next ack going from the PRX to the PTX. So there should be no need to disable esb or switch mode of operation to use nrf_esb_write_payload().

If you look at the \examples\proprietary_rf\esb_low_power_prx you can see what I mean.

Kenneth

[nordicfreak]

Yes, this I understand. However, the RX might send some data after a few minutes so appending to ack would not be feasible, that's why I keep both sides in RX mode and when they want to send I switch to TX.

Is this not a good approach?

[Kenneth]

nordicfreak said:

Is this not a good approach?

No, if the PTX expect data, it can just send 1byte 0xFF dummy data to fetch the data from the PTX. This is also much better in terms of current consumption.

Kenneth

[nordicfreak]

What if data is unexpected? Should I send every 1ms some empty packet from the TX until RX has data available?

[Kenneth]

nordicfreak said:

What if data is unexpected? Should I send every 1ms some empty packet from the TX until RX has data available?

It depends on your latency requirements really.

Kenneth

[Kenneth]

But I see your point, if you send data so infrequently it may make more sense to follow your approach, but have in mind that having a radio in continous rx will draw current. But if you follow your approach you must live with handling duplicates in rx.

Kenneth