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]

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

[nordicfreak]

What do you think is the reason for the duplicates? disabling the radio too soon after tx?

[nordicfreak]

As you can see in my tx function, I am blocking until  NRF_ESB_EVENT_TX_SUCCESS or NRF_ESB_EVENT_TX_FAILED received.

This should take care of that right?

[Kenneth]

nordicfreak said:

disabling the radio too soon after tx?

In normal radio communication in the 2.4GHz it's pretty common with packet loss due to interference from nearby wifi or other bt devices. So if you have 1ms delay, you are likley only have enough time to send 1ack, and if that one is lost then the peer will retransmit again. I suspect that when you are exiting rx mode/disabling esb that the ESB library no longer remember what the latest packet received was, so once you enter rx mode again, it will treat the received packet as a new packet, hence fowarding it to the application.

Kenneth

[nordicfreak]

Are there any protocols already written that will ensure packets arrive in the other side or do I have to write it from scratch?

i can barely find anything about esb online to be honest.

[Kenneth]

Gazell:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/gzll_02_user_guide.html 
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/gzll_examples_device_and_host.html 

PTX is called device, and PRX is called host in Gazell.

Kenneth

[nordicfreak]

As far as i remember, Gazell has a pretty small max payload size. Is there any code available demonstrating bidirectional communication using parge payloads?

[Kenneth]

32byte payload either way should be supported as-is I believe, do not believe larger is possible no.

Kenneth

[nordicfreak]

Can you please provide some sample code for Gazell RX and TX, for sending 300 byte payload?

How about bi-directional, can I change between host and device fast enough? Any other tips?