This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NUS connection problems with TimeSync example ported to SDK16.0.0

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

Parents
  • Hi,

    I ported the TimeSync example

    Could you upload the port you did ?

  • Hi Sigurd.

    Where should I upload the code?

    Regards,

    Benno

  • Hi,

    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):

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

    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.

  • 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

  • Hi Sigurd.

    Are there any news on this issue?

    Thanks,

    Benno

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

    Great!

    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.

  • 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.

Reply
  • 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.

Children
  • 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?

  • 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.

  • I think we are struggling with a timeslot API bug as well, perhaps the same.

    My questions: what is the actual effect of this bug?

    And can we expect a fixed Softdevice S140 6.x?

    Regards

    Hardy