NUS connection problems with TimeSync example ported to SDK16.0.0

Hi,

I ported the TimeSync example

Could you upload the port you did ?

Hi Sigurd.

Where should I upload the code?

Regards,

Benno

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

Hi,

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

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

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

user85765 said:

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

Great!

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

user85765 said:

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

Great!

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

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.

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