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

[Sigurd]

Hi,

[Benno Trutmann]

Ok, here it is. It has configurations for central/peripheral and PCA10040/PCA10056.

I saw another weired thing: On the PCA10056 somewhere randomly BSP_EVENT_KEY_x events are generated which turn on and off the sync beacon transmission. On the PCA10040 there are no such BSP_EVENT_KEY_x events!

timesync.zip

[Sigurd]

Hi,

Benno Trutmann said:

On the PCA10056 somewhere randomly BSP_EVENT_KEY_x events are generated which turn on and off the sync beacon transmission. On the PCA10040 there are no such BSP_EVENT_KEY_x events!

The sample was originally written for PCA10040, and there pin P0.24 is available and used for the measurement.

Snippet(sync_timer_button_init/sync_timer_init):

    // Debug pin: Toggle P0.24 from sync timer to allow pin measurement
    nrf_gpiote_task_configure(3, 24, NRF_GPIOTE_POLARITY_TOGGLE, NRF_GPIOTE_INITIAL_VALUE_LOW);
    nrf_gpiote_task_enable(3);

But on PCA10056, P0.24 is also used for button 3. So try using pin 27 for the pin measurement instead.

Benno Trutmann said:

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

Could be, could also be some timing related changes in advertising/scan module in the SDK, or interrupt priority levels that has changed. 

Try to increase the advertising interval, try changing APP_ADV_INTERVAL from 64 to 150.

[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?