NRF52 Timing Accuracy

RE: NRF52 Timing Accuracy

Dave_couling — Thu, 21 Dec 2017 20:13:50 GMT

You are likely subject to the HFCLK ramp-up time. Manually requesting the HFCLK will keep it up until you release it.

RE: NRF52 Timing Accuracy

RK — Fri, 26 May 2017 01:38:24 GMT

I was thinking about your previous post overnight and thought of sd_clock_hfclk_request() this morning, but you figured it out yourself before I got there. Good stuff, the softdevice code is written to be power aware and has to be pressed a little to keep everything running.

RE: NRF52 Timing Accuracy

rct42 — Fri, 26 May 2017 01:09:34 GMT

I've solved the drifting issue. I've tested the accuracy of my milli-second resolution timer and it is 13.4 ppm, similar to that of the 10 ppm HF XTAL on the NRF52 dev board. Key findings:

You must call "sd_clock_hfclk_request" and wait for confirmation that it is running via "sd_clock_hfclk_is_running". The call to "SOFTDEVICE_HANDLER_INIT" will set the system to use the HF CLOCK. However, the resulting timing suggests that the system is still using the internal RC oscillator if the aforementioned setup is not done afterwards. This is not very clear in the examples and I recommend that future examples explicitly do this, ideally not buried away in some optional module that the end user may not use in their application.
When using the TIMER module in the timer mode, you need to get the current timer value via issuing a capture on a different channel than that of your compare. The internal timer count is then immediately accessible on the appropriate CC register. [This is
The correct value for the compare channel is the (value), not the (value - 1). This is slightly odd as I'd assume the SHORTS mechanism reloads the timer value to 0 and the timer counter increment on the next clock.

I have also reduced the interrupt frequency of the compare to 20Hz (originally 1000Hz). This is to ensure that no interrupts are lost while the CPU servicing BLE radio tasks. In my application I also use this compare interrupt for timed callback functions. I'll need to increase the interrupt frequency for finer controlled timed callbacks but run the risk of missing interrupts while using BLE.

The updated example program can be found here: www.dropbox.com/.../nrf_timer_accuracy_test_final.c

RE: NRF52 Timing Accuracy

rct42 — Thu, 25 May 2017 04:25:32 GMT

I've since updated my test program. I've also reduced the capture compare interrupt frequency to 20Hz, so should not have any missing interrupts while the radio is being operated. If I enable the HF XTAL via the "registers", I observer a drift of 3.21ms over 4 minutes. However, if I enable the HF XTAL via enabling the soft device, the drift is much worse - 193ms over 1 minute! Suggestions? Updated test program can be found here: www.dropbox.com/.../nrf_timer_accuracy_test2.c

RE: NRF52 Timing Accuracy

rct42 — Thu, 25 May 2017 03:11:51 GMT

RK, I think your suggestion to check the clock source is the answer here. (I usually have the soft device running, but for the purpose of a small test program I neglected to switch over to the HF crystal). I've retested the timer and it is drifting at 13.4 ppm. I'll stick with the current compare match feature, mainly because I also use this interrupt to trigger timed callbacks.

RE: NRF52 Timing Accuracy

RK — Wed, 24 May 2017 23:36:11 GMT

just keep a separate counter of the number of times it rolled over. your timestamp is then (rollover count * timer rollover ) + ( timer current value). This is sort of how everyone keeps a long-running timestamp.

by the way - you did explicitly start the HF crystal didn't you, the softdevice starts that for you usually, if you're not using that and don't start it yourself (you can check the bit in the mask to see if it's running) then you're on the internal oscillator.

RE: NRF52 Timing Accuracy

rct42 — Wed, 24 May 2017 23:19:50 GMT

RK, as for the method of clearing the counter, I've enabled the event-task shortcut to clear the timer on the compare event. The only thing I'm doing that is timer-related in the ISR is clearing the interrupt flag, so I don't expect any drift to be occurring due to the duration of the ISR. I've posted a short program which demonstrates the problem. This can be downloaded here: www.dropbox.com/.../nrf_timer_accuracy_test.c

RE: NRF52 Timing Accuracy

rct42 — Wed, 24 May 2017 23:17:03 GMT

RK, good point about the timer value being the value. Unfortunately, I need to maintain a timestamp that is capable of values well beyond that of the rollover of the timer!

RE: NRF52 Timing Accuracy

RK — Wed, 24 May 2017 22:55:59 GMT

also if you just want a time not a time signal, just let the TIMER run free and keep a counter each time it overflows, then you just read the timer value every time you need a timestamp and use it directly. You don't have to increment a separate value in RAM, the timer IS your value.

RE: NRF52 Timing Accuracy

RK — Wed, 24 May 2017 22:52:28 GMT

How are you resetting the TIMER after the interrupt fires. If you'd doing it in the interrupt handler, you're going to drift all over the place as interrupt handlers can get delayed. If you don't already have it, you need to set up the PPI or shortcut so that the timer firing event clears the timer in hardware.

RE: NRF52 Timing Accuracy

rct42 — Wed, 24 May 2017 21:36:46 GMT

My requirement is to capture and record BLE packets. This data is to be synced up to another separate independent system that time-stamps data using UTC time and GPS PPS. I can "sync" the two data sets once only, but require both systems to time-stamp data with millisecond resolution timers that are have low drift (ideally within 10 ppm, currently 560 ppm is too much!), due to the nature of the data and duration of the events.

RE: NRF52 Timing Accuracy

rct42 — Wed, 24 May 2017 21:27:42 GMT

Unless I can somehow use the PPI to update the millisecond timer value in RAM? (My understanding that PPI is to connect one hardware peripheral to another without using the CPU).

RE: NRF52 Timing Accuracy

rct42 — Wed, 24 May 2017 21:15:38 GMT

Kristin,

I'm trying to create an accurate timestamp, not an accurate timer signal. (I'm only generating a timing output so I can validate the accuracy of the timer against the GPS PPS).

RE: NRF52 Timing Accuracy

FormerMember — Wed, 24 May 2017 09:12:47 GMT

To generate an accurate timer signal, you should use hardware peripherals (PPI and GPIOTE to toggle a GPIO), rather than software interrupts. The gpiote example in the SDK shows how to do so.

RE: NRF52 Timing Accuracy

rct42 — Wed, 24 May 2017 02:46:52 GMT

I just had a read through the RTC module. Unfortunately, I can't use this as I require a milli-second resolution (the RTC module is clocked from a 32.768kHz source). Basically I'm after something that increments a 32-bit value stored in ram every 0.99999 - 1.00001 ms (1ms +/- 10 ppm).