Advertising causes timer1 delay?

RE: Advertising causes timer1 delay?

hawk — Thu, 07 Jul 2016 07:38:10 GMT

@stefan， we have the external crystal oscillator，// Initialize the SoftDevice handler module. SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, false); the detail is described in this url： devzone.nordicsemi.com/.../

RE: Advertising causes timer1 delay?

Stefan Birnir Sverrisson — Wed, 06 Jul 2016 11:18:54 GMT

@hawk The app timer uses RTC1 in the background which in turns uses 32kHz clock source. What clock source are you using? The app_timer drift can be caused by the drift of the clock source chosen.

How to choose a clock source: When you initialize and enable the softdevice by calling ble_stack_init, you have several clock source options which either use external 32kHz crystal or internal 32kHz RC oscillator. If you use the RC, the accuracy is 250ppm, when you use crystal, it usually has better accuracy.

RE: Advertising causes timer1 delay?

hawk — Tue, 05 Jul 2016 05:37:41 GMT

I use the old SDK 5.2.0 and S110 6.0.0; I use the app timer to count sec,min,hour(make one time clock), and found that the second of mine is less after i set an initial sec/min/hour and run for some days. how to avoid delay the app timer of old SDK?

RE: Advertising causes timer1 delay?

Stefan Birnir Sverrisson — Tue, 12 May 2015 13:27:42 GMT

To decrease the CPU blocking time, you do not need SDK 8.0.0/8.1.0 + S110 8.0.0. You can continue using SDK 7.1.0 and S110 7.1.0 and unblock the CPU in order to have maximum latency less than 1ms during advertising. But again, unblocking the CPU will only work if you have third revision nRF51.

RE: Advertising causes timer1 delay?

gwayne — Fri, 08 May 2015 12:43:39 GMT

Thanks for your response. I attempted to update my project to 8.0 a while ago, but ran into a number of issues and had to back off. The changes were difficult to reconcile and frequently undocumented. Updating to 8.0 is probably the best ultimate best solution, so I plan to try once again. For now 10ms of resolution works well enough for this project to move forward.

RE: Advertising causes timer1 delay?

Stefan Birnir Sverrisson — Thu, 07 May 2015 12:34:51 GMT

I think your assumption is correct. The peripheral will send an advertising packet, then start the RX receiver in order to listen for a potential connection request or scan request. If the central device is an active scanner (i.e. sends a scan request) the peripheral will respond with a scan response packet, which will increase the blocking time of the CPU.

IOS generally performs active scanning when the IOS app is in the foreground, which explains the behavior. When the peripheral is advertising and does not send scan response packet, I suspect the CPU is blocked for less than 1 ms, but when sending scan response packet the CPU is blocked for more than 1 ms.

If the CPU is blocked during two consecutive Timer1 interrupts, you will lose one interrupt, i.e. for two timer1 interrupts, the counter will only be incremented once.

I suspect the problem can be solved by using third revision nRF51 hardware and softdevice 110 7.1+ which allows for the CPU to be used during radio activity. See this thread how to unblock the CPU for S110 v7.1.0 (only works with third revision nRF51, see comp matrix for what nRF51 devices are third revision). For S110 v8.0.0, the CPU is unblocked by default.

If you look at the S110_softdevice Specification version 1.3 (targeted at softdevice 7.0.0), section 11.3.1, you see that the softdevice can block the CPU up to 1700 us. If you however look at the same section in S110_softdevice Specification version 2.0 (targeted at softdevice 8.0.0), you see the CPU blocking time during advertising is only 440 us.

An idea of a workaround is to use Timer1 with 1ms interrupt frequency and use Timer2 as counter, and let Timer1 CC0 event trigger a counter task on Timer2 trough a PPI channel. That way, no CPU is needed to increment the ms counter.

Another dirty workaround would be to advertise with whitelist. The peripheral will not send scan response packet to a central that is not in the whitelist.