Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ESB retransmission delay

Hi - I noticed an issue in the esb library as of nRF5 SDK v17.0.2 and am looking for clarification.

In the function update_radio_bitrate, the minimum retransmission delay is checked by the following code:

// Ensure that we do not attempt retransmitting before ack timeout.
if (m_config_local.retransmit_delay < m_wait_for_ack_timeout_us + RETRANSMIT_DELAY_US_OFFSET)
{
    m_config_local.retransmit_delay = m_wait_for_ack_timeout_us + RETRANSMIT_DELAY_US_OFFSET;
}

With 2 Mbps bit rate, this implies that the minimum delay is (48 + 62 = ) 110 µs. But when the retransmit_delay value is actually used in the on_radio_disabled_tx function:

NRF_ESB_SYS_TIMER->CC[1] = m_config_local.retransmit_delay - 130;

Any value less than 130 µs would then underflow and give unintended behavior.

Could you clarify if this reading of the code is correct? And why is 130 subtracted from the retransmit delay when it's used for the compare interrupt?

Parents
  • Hi,

      

    With 2 Mbps bit rate, this implies that the minimum delay is (48 + 62 = ) 110 µs. But when the retransmit_delay value is actually used in the on_radio_disabled_tx function:

    Any value less than 130 µs would then underflow and give unintended behavior.

    Could you clarify if this reading of the code is correct? And why is 130 subtracted from the retransmit delay when it's used for the compare interrupt?

    You are correct. Anything lower than .retransmit_delay= 130, and the uint16_t will roll over, and it'll wait for ~65ms before retransmitting.

    The library is implemented to be compatible with the nRF24L-series devices, which use 130 us to ramp up the radio (same when it switches RX->TX or TX-RX). There should be a check here from our side to validate the local configuration. This is a clear bug from our side! I'll create an internal report on this matter. Thank you very much for reporting this back to us, and helping us improve our delivery!

     

    From the nRF52-series and forward, the radio ramp up time can be configured to be lower; but its kept at a legacy ramp-up time in this specific library to be on-air compatible with nRF51-series and nRF24L-series devices.

     

    Kind regards,

    Håkon

Reply
  • Hi,

      

    With 2 Mbps bit rate, this implies that the minimum delay is (48 + 62 = ) 110 µs. But when the retransmit_delay value is actually used in the on_radio_disabled_tx function:

    Any value less than 130 µs would then underflow and give unintended behavior.

    Could you clarify if this reading of the code is correct? And why is 130 subtracted from the retransmit delay when it's used for the compare interrupt?

    You are correct. Anything lower than .retransmit_delay= 130, and the uint16_t will roll over, and it'll wait for ~65ms before retransmitting.

    The library is implemented to be compatible with the nRF24L-series devices, which use 130 us to ramp up the radio (same when it switches RX->TX or TX-RX). There should be a check here from our side to validate the local configuration. This is a clear bug from our side! I'll create an internal report on this matter. Thank you very much for reporting this back to us, and helping us improve our delivery!

     

    From the nRF52-series and forward, the radio ramp up time can be configured to be lower; but its kept at a legacy ramp-up time in this specific library to be on-air compatible with nRF51-series and nRF24L-series devices.

     

    Kind regards,

    Håkon

Children
No Data
Related