Best way to track seconds precisely on our nRF52832

RE: Best way to track seconds precisely on our nRF52832

Karl Ylvisaker — Thu, 15 Oct 2020 14:24:09 GMT

Hello,

Let us continue this in the other ticket.

Best regards,
Karl

RE: Best way to track seconds precisely on our nRF52832

riceman0 — Wed, 14 Oct 2020 19:24:36 GMT

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

RE: Best way to track seconds precisely on our nRF52832

riceman0 — Wed, 14 Oct 2020 19:23:46 GMT

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!

RE: Best way to track seconds precisely on our nRF52832

Karl Ylvisaker — Tue, 06 Oct 2020 12:53:17 GMT

Hello,

[quote user="riceman0"]thanks for the answers.[/quote]

No problem at all, we are happy to help!

[quote user="riceman0"]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.[/quote]

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

RE: Best way to track seconds precisely on our nRF52832

riceman0 — Fri, 02 Oct 2020 18:09:17 GMT

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!

RE: Best way to track seconds precisely on our nRF52832

Karl Ylvisaker — Mon, 21 Sep 2020 07:19:59 GMT

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

RE: Best way to track seconds precisely on our nRF52832

Jay Tyzzer — Fri, 18 Sep 2020 17:16:12 GMT

Please take a look at this project located in the github. Maye there is something there you can use or jump off from.

https://github.com/NordicPlayground/nrf5-calendar-example

"This is a small example of how to keep track of time using the RTC timer and the time.h library. By default the example uses the external 32kHz crystal for maximum accuracy."