ESB payloads occasionally sent off later than expected

[esmart-engineering]

I am working with ESB between 2 nRF5340DK's (w/ no need to be cross compatible w/ other devices) and with NCS v2.5.0. I am using ESB to wirelessly transmit data every 2ms, and have been mostly able to achieve it by relying on the example projects (located at NCS, nrf/samples/esb/) and by using the following settings:

• PTX

  • struct esb_config config = ESB_DEFAULT_CONFIG;
    
    config.protocol = ESB_PROTOCOL_ESB_DPL;
    config.bitrate = ESB_BITRATE_2MBPS;
    config.mode = ESB_MODE_PTX;
    
    config.retransmit_count = 2;
    config.selective_auto_ack = false;
    config.retransmit_delay = 400;

• PRX

  • struct esb_config config = ESB_DEFAULT_CONFIG;
    
    config.protocol = ESB_PROTOCOL_ESB_DPL;
    config.bitrate = ESB_BITRATE_2MBPS;
    config.mode = ESB_MODE_PRX;
    config.selective_auto_ack = false;

However, occasionally I will see the payload arrive at PRX a little late and then "recover" (for example, I see payloads at t=0, 2ms, 4ms, 6.5ms, 8ms, 10ms,  12ms, ...). From debugging, it appears to be due to the retransmission delay. It appears that the payload being slightly late like this is unavoidable, seeing as:

• Payloads stop getting sent after several seconds if the retransmit delay is too low i.e., 100 or 150 (us is the units for these I imagine)
• I get too many TX_FAILED events if I use no retransmits

I just wanted to get a 2nd opinion to see if this conclusion seems valid. If not, what other things could I look into that could explain (and ideally fix) this issue that I'm seeing?

--------

EDIT #1 - Corrected the timing example. I previously said I see payloads at t=0, 2ms, 4ms, 5.5ms, 5.7ms, 6ms, 8ms, ... I meant to say I see payloads at t=0, 2ms, 4ms, 6.5ms, 8ms, 10ms,  12ms, ...

[Simonr]

Hi 

I guess tis could be the Auto Retransmit delay that does this, which is at least 0.5ms. How would you explain this behavior exactly on your end? Since the payloads come in at 4ms, then 5.5ms, it sounds like the packet is early, not late? Can you show us how exactly you measure the timing here, and do you do ACKing or not?

Unfortunately, our ESB experts have left for the holiday season, so you won't have any expert advice until January 6th I'm afraid. 

Best regards,

Simon

[esmart-engineering]

I corrected the example about when the packets are coming in, to show why the packet is getting sent late.

I measured timing using LEDs and a logic analyzer (and, to clarify again, using the ESB examples heavily as a starting point)

• I rewrote the LED code used in the ESB examples so that leds_update(uint8_t value) will toggle led<value>. For example, leds_update(0) toggles led0, which is LED1 on the nRF5340DK
• On PTX, I toggle led0 before and after the esb_write_payload() call
• On PTX, I toggle led1 twice when handling ESB_EVENT_TX_SUCCESS.
• On PRX, I toggle led0 twice when handling ESB_EVENT_RX_RECEIVED.
• I hooked up a logic analyzer to those LEDs and measured timing this way.
  • PTX led0 toggles every 2ms as expected.
  • PTX led1 and PRX led0 shows the occasional late packet.

The packets do use ACKing (on PTX, I set tx_payload.noack = false).

[Simonr]

Hi

What makes the packet receive what seems to be early here though (4ms - 5.5ms - 7 ms)? Do you have a log or something showing the timings here or do you take them just based on the logic analyzer? 

Best regards,

Simon

[esmart-engineering]

I already clarified this in my previous reply - packets are late, and logic analyzer only is used for timing. Please have your ESB experts address this when they get back Jan 6.

[esmart-engineering]

Just wanted to add a kind reminder for your ESB expert to take a look at this post on the 6th. Looking forward to your thoughts on this.