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!

[Mike]

I'm not sure if I understood what you want to do. But I'll try to give you some hints. Correct me if I got you wrong. If you want your device to have accurate real world time and date (like 2014/04/04 - 10:25:58) than the easiest way is too use an external RTC chip (example, there are many other manufacturers: para.maximintegrated.com/search.mvp that counts the time for you. You can read the time and date from it over an SPI or I2C interface depending of the chip you choose.

The advantage is that you can really go to sleep with your nrf51422 because the RTC chip will do everything for you. On some RTC chips you can even set an one time alarm or a periodic alarm so the RTC chip will wake the nrf51422 up by triggering in interrupt on the GPIO.

If you want to use just nRF51422 internals to implement this you could use the RTC that is in the chip. But there are some disadvantages:

• The internal RTCs (there are two: RTC0 and RTC1) do not have date and time. It's just a 24 bit counter, you need some extra software that will make a time from and date from that.
• One of the internal RTCs is used by the softdevice so you cannot use it from your application.
• The other internal RTC is used by the app_timer.c library. You can decide not to use the app_timer.c lib so the RTC is yours. But a lot of the examples use the app_timer.c and it's actually a very useful feature that might help you develop your application.

That the experience I made while trying to implement something similar. Hope that helps you.

[mahone]

Hi Mike, Thank you for your reply,That's a good idea but there may be a little disadvantages cause using an external RTC chip(I don't know how much it is) will need external power and external money consume.I want to make a BLE project,so every costs is counted.So it is best to solve it from software or maybe add a crystal or something like that.

[Mike]

You are right, I thought the same as you when I started implementing it. And yes, it is possible to go this way using the internal RTC but you must live with the drawbacks I mentioned.

The power consumption is very low (0.3 uA) for external RTCs. The internal RTC consumes 0.1 uA and you need another 0.4uA for the internal 32.768 kHz crystal oscillator. So the consumption is very similar. Would be nice if someone from Nordic could confirm.

You must decide what is best for your application. There are pros and cons on both sides.

[mahone]

Thank you so so much!I will think it over.

[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