NUS connection problems with TimeSync example ported to SDK16.0.0

[Benno Trutmann]

Hi,

I ported the TimeSync example devzone.nordicsemi.com/.../wireless-timer-synchronization-among-nrf5-devices to the current SDK 16.0.0 and S140_nrf52_7.0.1_softdevice. But now the NUS client has difficulty to connect to the NUS server. The connection request is mostly aborted with reason 0x3E and only after dozens of retries the connection gets established:

<info> app: Connecting to target 7E80BA93D6E9
<info> app: Disconnected. conn_handle: 0x0, reason: 0x3E
<info> app: Connecting to target 7E80BA93D6E9
<info> app: Disconnected. conn_handle: 0x0, reason: 0x3E
...
<info> app: Connecting to target 7E80BA93D6E9
<info> app: Disconnected. conn_handle: 0x0, reason: 0x3E
<info> app: Connecting to target 7E80BA93D6E9
<info> app: Ble NUS max data length set to 244
<info> app: Discovery complete.
<info> app: Connected to device with Nordic UART Service.

When I disable the TimeSync timeslot protocol then the NUS has no problem connecting. With the original TimeSync example based on SDK 14.2.0 and with S140_nrf52840_5.0.0-2.alpha_softdevice I  had no such problems.

Has there somthing changed regarding the timeslot API between S140_nrf52840_5.0.0-2.alpha_softdevice and S140_nrf52_7.0.1_softdevice?

Thanks,
Benno

[Sigurd]

Hi,

I ported the TimeSync example

Could you upload the port you did ?

[Benno Trutmann]

Hi Sigurd.

Where should I upload the code?

Regards,

Benno

[Benno Trutmann]

Hi Sigurd.

Increasing the advertising interval from 40ms to 80ms helps alot!

Do you have an explanation for this? For me it seems quite unrelated that the advertising interval on the peripheral influences the connection probability on the central. And how does this relate to the timeslot API?

Thanks,

Benno

[Benno Trutmann]

Hi Sigurd.

Are there any news on this issue?

Thanks,

Benno

[Sigurd]

Benno Trutmann said:

Increasing the advertising interval from 40ms to 80ms helps alot!

Great!

Benno Trutmann said:

Are there any news on this issue?

It's good that the proposed workaround is working. I have started to look into the root cause. Based on initial testing, it's seems like using NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED is causing the first packet sent by the master after CONNECT_IND packet to be sent a bit too early. Other workarounds could be to set NRF_SDH_CLOCK_LF_ACCURACY to 1, or use NRF_RADIO_HFCLK_CFG_NO_GUARANTEE. I will continue to investigate the root cause.

[Sigurd]

I can confirm that this is a bug in the SoftDevice introduced in v6.1.1, and also present in v7.0.1

Another workaround is to start the timeslot session after the scanning is started.

[Benno Trutmann]

In the time_sync example HFCLK is alway on due to calling sd_clock_hfclk_request(). So if I change the timeslot requests from NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED to NRF_RADIO_HFCLK_CFG_NO_GUARANTEE are there any drawbacks?

When will there be a SD fix available?

[Sigurd]

Benno Trutmann said:

there any drawbacks?

Only that the HFCLK is not turned off between BLE radio and timeslot usage, so the current consumption will potentially be a little bit higher.

Benno Trutmann said:

When will there be a SD fix available?

 There is no specific date. Likely in a couple of months.