Best way to track seconds precisely on our nRF52832

[riceman0]

Hello, I've seen several posts about this, but I'm a little hesitant to use older posts since you guys put out new and improved versions pretty quickly.  We are using SDK 16.0 and an nRF52832.

What is the best way to keep track of precise real time (in our case, seconds)?  We started using a timer like the one below, and found that it wasn't quite 1000Hz, we were off by a few minutes every day.

Is there a relatively simple way we can do better than this?  Any thoughts, or a link to sample code or the applicable doc would be awesome.

Thanks!

    uint32_t rtncode_timerinit = app_timer_init();
    uint32_t rtncode_timercreate =  app_timer_create(&m_serviceloop_timer_id, APP_TIMER_MODE_REPEATED, ServiceLoop_Timeout_Handler_1000Hz);

[Karl Ylvisaker]

Hello,

@Jay 's referenced github repository is an excellent example of how you may go about doing this.
Unfortunately, if you only rely on the RTC then you may experience some drift as time passes ( influenced by the operating conditions ). If your application needs to minimize this drift you may look at implementing the Current Time Service ( or a similar custom service ) on your central, so that your peripheral can sync its time with the central, if it is connected at any time.

Best regards,
Karl

[riceman0]

Hey guys, thanks for the answers.  We are using that technique (thanks Jay) and seeing that the drift is approximately one minute per day.  Is this what you guys see?  Since we can't count on an opportunity to sync with a central, and real time is important, we are hoping we are making some mistake that can be fixed, or (if this is expected drift) we are trying to think of any way to improve that.

Thanks again!

[Karl Ylvisaker]

Hello,

riceman0 said:

thanks for the answers.

No problem at all, we are happy to help!

riceman0 said:

We are using that technique (thanks Jay) and seeing that the drift is approximately one minute per day.  Is this what you guys see?  Since we can't count on an opportunity to sync with a central, and real time is important, we are hoping we are making some mistake that can be fixed, or (if this is expected drift) we are trying to think of any way to improve that.

One minute per day sounds much.

When you are using the app_timer, the timeout handler will update RTC compare register on each iteration, so drift should depend on (1.) clock accuracy + (2.) accuracy of the compare register compared to the timeout configured and (3.) noise/ripple on VDD.

(1.) Clock accuracy; in this case will be 5ppm = 5us @ 1second. However this should be verified by measurement, because the load capacitors can affect the tolerance much more than what the crystal is specified to be. The load capacitors will offset the frequency by a fixed value. 
For example, on the nRF52-DK the 32kHz external crystal is 20 ppm, this will give you a drift at 10.51 minutes for 1 year. The lowest ppm I have seen for a 32kHz external crystal is 5 ppm (2.63 minutes drift for 1 year). What is the ppm of your external crystal?

(2.) Accuracy of compare register; a RTC tick take 1/32768kHz and this fit well with a 1second [32768 periods]. That would for instance not be the case with a 1ms timeout, since that will equal 3276.8periods, which will have an error of ~10us for each 1ms timeout. What is your timer width?

(3.) noise/ripple on VDD. Noise/ripple on VDD; For instance the 32kHz is a analog signal in the few hundred mV peak-to-peak amplitude. If you have much ripple (e.g. >100mV) on VDD, for instance due to current drawn by the radio, then this may have an effect the clock periods and thereby drift. Have you done any measurements on this, if so; what were they?

Best regards,
Karl

[riceman0]

Hello, thanks for the detailed answer.  Using Jay's example, it uses a prescaler of 0xFFF (+1=4096), which sets a timer period of 125msec and then we set our "callback interval" using nrf_cal_set_callback with a parameter of 4 seconds.  This causes the RTC->CC[0] register to be set to 4*8=32, which should come out to exactly 4 seconds (no resolution error).  So I think #2 should not be a contributor?

What I've done is I've printed out a serial message on the callbacks, which should be 4 second intervals.  What I am seeing is this, consistently:

Tick 0 at 0 msec

Tick 93 at 371875msec (3998.65msec/tick)

Tick 155 at 619796msec (3998.68msec/tick)

Tick 574 at 2275250msec (3998.68msec/tick)

This is consistent across my tests, even when I boil my application down to just this timer.  It comes out to an error of about 30 seconds per day.  

I've asked our EE to confirm the ppm of our crystal, and it seems like this should not cause errors this big, don't you think?

Your idea #3 I'm not familiar with.  What happens, would the noise somehow cause extra pulses on a clock signal?  Would this cause the clock to run faster than configured?  (Which would be the opposite direction of my error, right?)

Seeing as how the error is so consistent, I *could* compensate with a constant to fix it, but this would be very risky without understanding the source of the error, obviously.  Could you comment on my inferences above, and does anything else come to mind when I provide the data above?

Thanks!

[riceman0]

Actually... I see that I've already verified the answer for this question... sorry I will start a new one.

[Karl Ylvisaker]

Hello,

Let us continue this in the other ticket.

Best regards,
Karl