ESB RX_ACK different from NRF5 SDK to NRF connect SD

[KennFischer]

Hi

Im converting from NRF5 SDK to NRF connect SDK, and im using ESB but noticed that there is a different in RX ack timeout on the NRF5 SDK vs the NRF connect SDK. 

The NRF5 SDK Rx Ack timeout is: 
#define RX_WAIT_FOR_ACK_TIMEOUT_US_2MBPS        (48)        /**< 2 Mb RX wait for acknowledgment time-out value. Smallest reliable value - 43. */

Where the NRF connect SDK Rx Ack timeout is: 
#define RX_ACK_TIMEOUT_US_2MBPS                             160        /* 2 Mb RX wait for acknowledgment time-out value. Smallest reliable value: 160. */

Is there a reason behind this, and is there a way to get the NRF connect SDK to be lowered, as it does seems to not be reliable at a lower rate?

Best regards 
Kenn

[tesc]

Hi,

While it's pretty clear from the comments that the value should not get below 160 ms, I have not found the underlying reason. Most likely the number stems from testing during the porting of the library from nRF5 SDK to nRF Connect SDK. It's hard to tell whether the value can be lowered, and if so by how much, but I will dig some more internally to figure out more about the issue. What impact does the increased timeout have for your project, is the issue latency, throughput, power consumption, other, or a combination?

Regards,
Terje

[KennFischer]

Hi Terje

Thanks for the answer.

The change does have big impact on my project, as latency on the radio has to be as low as possible. And at the moment I'm not sure I can get the throughput fast enough as I could with the Nrf5 SDK. 

Hope you found out some interesting internally that could help this problem. 

Best regards

Kenn

[tesc]

Hi,

I am afraid I don't have any definite answer to why this setting is changed, nor why it is at exactly 160. There is however one possible explanation, which I have not gotten any confirmation for yet:

It may have to do with giving enough time for receiving a full ACK with payload. ACK with payload was an optional feature in nRF5, but I do not find a setting for it in NCS so it might be always present. That might explain the need for additional time for the ACK timeout. In that case, a lower value might be possible if the ACKs don't contain payload.

If it's up to the ESB library to decide whether to include payload in the ACK, then you cannot be sure, in cases where the peer device is also based off of nRF Connect SDK. If on the other hand you know that the peer device will not send payloads in the ACK, then it might be safe to reduce the timeout.

Have you tried to reduce the value, and seen any issues as a result?

Regards,
Terje

[KennFischer]

Hi

I have tried to change the timeout to the same value as the old SDK, however I can not get a stable connection between my PTX and PRX. 
I'm still testing if the speed is good enough, and found out that this value in ESB.c file aswell is alot higher than previous SDK. "RETRANSMIT_DELAY_MIN" However it does seem to be able to change it from 435 to 135, without any issues. 

Best regards 
Kenn

[tesc]

Hi,

We have traced the values back to worst case scenarios from full capacity testing of the ESB implementation. In other words, the values are, as we see it, indeed the minimal values for ESB in the current nRF Connect SDK.

You may get away with some lower values if not running at full throughput, or if you accept degraded performance in other areas, but I am afraid that would be something you must experiment with yourself and there are no guarantees such values exist.

For information on what to expect in the future, please contact our Regional Sales Director (previously Regional Sales Manager) for your area. If you don't know who that is, please ask in a private ticket or private message, and we will let you know.

Regards,
Terje

[KennFischer]

Hi 

What about if I want to change a define value in the ESB.c file in the SDK, how do I make it available, when I clone the SDK to a new PC, without having to manually change it? 

The value I want to change is a define in the ESB.c file: 

/* Minimum retransmit time */
#define RETRANSMIT_DELAY_MIN 435

My project works with this changed to 135, but as its in the SDK, I have to do it manually. 

[tesc]

Hi,

I am afraid there is no short and simple solution for this.

If the define had been in a header file, then you could add a static assert for the value of this define to your project, reminding the developer to manually update the define. However, since it is in a c file, you don't have access to it outside of that compilation unit. In other words you cannot do such a check from application code.

In general, you would have to update the SDK code through a manual process. Through changing the file manually in an editor, or through applying a patch, or through a script modifying the source file, or some similar method. A scripted solution could theoretically run as part of the build process, modifying the SDK if needed before building, although that solution could look a bit weird and unexpected to anyone picking up the project at a later point in time.

Alternatively, fork the SDK, and use that fork instead of the official release from us. Then maintain that fork for every new SDK release, keeping it identical to the SDK except for the one define being different. It sounds to me like a lot of complication for keeping one single define different, though. I think this would be more relevant as a solution if you had larger differences.

It should be possible to copy the full ESB library into a custom library that is kept as part of your application project, under a different name, handling it as any custom library. That would lead to maintenance work, for keeping the library in line with the version found in the SDK.

And of course, this might get improved in the SDK itself, in some future SDK release, at which point you no longer need to patch the SDK. I wouldn't spend too much time and effort on how to patch the library, just find a quick and safe (enough) solution that works for you.

Regards,
Terje