How to deal with a long time's Clock drift?

[mahone]

Hi,

I use to the nrf51422 with nordic's dev/ev kit.I want to build a project and the purpose is to get the sensor's date and use the ant protocol to deliver the date to another chip every 5 hours.The rest of the time the chip will go to sleep.But recently I test two board's clock drift,I find the clock will drift 1s every 10min.And my test is simple,I use the way: while(1) {
nrf_gpio_pin_set(Pin); nrf_delay_ms(1000); nrf_gpio_pin_clear(Pin); nrf_delay_ms(1000); } I don't know is there any solution can solve this problem? Thanks!

[Stefan Birnir Sverrisson]

Hi Mahone

Thanks Mike for providing a lot of good information. I would however like to add a few things.

For your original test with: while(1) { nrf_gpio_pin_set(Pin); nrf_delay_ms(1000); nrf_gpio_pin_clear(Pin); nrf_delay_ms(1000); }

then you are testing the accuracy of the internal 16MHz RC clock source. Internal 16MHz RC is the clock source for the CPU unless you explicitly start the 16MHz external crystal. The tolerance of the internal 16MHz RC oscillator can be up to plus/minus 5% and is specified in nRF51822 PS v2.0, table 21.

If you would like to do nothing for 5 hours except keep track of time, RTC is much better choice in terms of current consumption, as Mike has already mentioned. The internal 32kHz RC oscillator has default tolerance of plus/minus 2%, but 250ppm when calibrated. The drawback is that calibration adds ~10uA to the current consumption. So the best choice for you would be either to use the internal RTC with a 32kHz external crystal, or as per Mikes suggestion, to use an external RTC. The current consumption is 3.1uA when 32kHz crystal and internal RTC is enabled. If you use external RTC, you could let nRF51 enter System Off and then wake up again on a GPIO level change from the external RTC. System Off consumes 0.6uA with no RAM retention.

If you have softdevice enabled and are using application timers, you could use an application timer to keep track of time, which uses the RTC1 peripheral in the background.

More on the nRF51 internal 32kHz clock sources is here and devzone.nordicsemi.com/.../how-to-minimize-current-consumption-for-ble-application-on-nrf51822

[Mike]

What about the power-consumption when using the application timer? Isn't the usage of the application timer bound to a higher sleep level?

Does application timer not have any jitter? So the accuracy would be the accuracy of the RTC clock source?

[Stefan Birnir Sverrisson]

Hi Mike

When RTC is used directly, you can have it trigger a task of another peripheral on the nRF51 pretty much instantly when using PPI channels.

When you use RTC directly with a RTC interrupt handler, it will typically take 3-4 us from the RTC event trigger until code execution starts in the interrupt handler. This is of course depending on if there is no interrupt with the same or higher priority already utilizing the CPU.

For the application timers, they will work pretty much the same in this regard as when using RTC directly with interrupt handler. There is a little more overhead when using the applicaiton timer, so the delay should be a little longer from RTC event until the application timer handler starts to execute, but it should not be many microseconds in addition to the RTC interrupt handler.

You should test execution delay however with compiler optimization enabled. Enable compiler optimization in order for your application to be executed in as few instructions as possible. This will make the code execute faster and finish sooner and will therefore save power. To enable compiler optimization in Keil, select Options for Target -> C/C++ tab and set Optimization to “Level 3” and check “Optimize for Time”. In order for you to efficiently debug the application code in Keil, the setting should be however Optimization: “Level 0” and “Optimize for Time” should be unchecked.

Since using an application timer will possibly add a few microseconds to the CPU usage compared to using RTC directly, it will add something to the current consumption. However, if the frequency of timer events is only a few Hertz, it is so small it can normally be neglected, in the order of nanoamps.

Application timers are operational in System On low power mode. This is the mode the BLE softdevice uses in between radio events in order to save power. If the device enters System Off low power mode however, neiter application timers or RTC will be operational.