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

[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