Secs

[macpherson]

Assuming the crystal is perfect, how accurate is the variable "Secs"?

[rnixon]

The TICKS_PER_SECOND value is 20, so if the crystal was perfect I think you would be +/- 50ms, or 1 tick.

[macpherson]

I understand that the resolution is 50 ms. But how accurate is it? How many seconds will it be off in one day (assuming a perfect crystal).

[Ridgeglider]

This is pretty circular! A "perfect" crystal? One that has no tolerance? One that has no temperature dependence? An environment with no competing interrupt or task priorities? Good design is all about constraints. So what are you willing to live with? Pragmatically I can tell you the secs variable accrues error. Unless you were willing to go to extremes like temperature controlled oscillator ovens, (and perhaps even then) it probably always will. A way to improve on this is to periodically (1x/12hrs?) sync secs to a value calculated from reading the RTC. Even so, according to this app note for the NXP PCF8536, reasonable expected annual deviation of the RTC can be upto +/- 15 minutes per year. The app note discusses ways to improve on this...:http://www.nxp.com/acrobat_download/app ... 0652_1.pdf

Finally, another startegy is to update secs from a gps. Some gps modules produce a 1Hz or 5Hz pulse output that can often be offset by some specified amount (typ 20-900 msec) from the time of the gps sync. It is typically accurate to within 1uSec of an atomic clock standard. Other gps units just give you access to time via a NMEA string, but in any case accurate to within 1 second whenever read...

[rnixon]

If the crystal was "perfect", then I would think the time would be exact. The non-perfect crystal frequency tolerance is what makes the system lose/gain time. This is usually expressed in ppm, and is temperature dependent. As mentioned in the other posts, check in with a ntp server once a day (or whatever makes sense for your app) and sync the time. I think you can just write Secs directly.

[macpherson]

Thanks for your replies.

What I really am asking is a completely different thing.

Is one sec really 1.000000000 seconds or is it e.g. 1.000000000034 because of some non decimal division? In addition what if some ints are missed or slow. Is that possible? And will any of this affect the number of seconds in a day?

Thanks again.

[rnixon]

Because of the crystal tolerance issue, even if the number you stated of 1.000000000034 was true it makes no difference. You need to sync up any time keeper to compensate for the crystal tolerance. The only way some ints could be missed is if your application creates a higher level int that takes more than 50ms (in this case the time accuracy would be the least of your worries). The same is true of being "slow". You have a 50ms window.

[joepasquariello]

I happen to be working on using the RTC in the MOD5213. What I'm finding is that the RTC is good to within about 2 seconds per day, I've measured Secs as drifting from actual time by up to about 5 seconds per day (~0.006% accuracy).

What I'm doing now is reading the RTC every couple of minutes and checking its value against the system time, which is based on Secs. When the RTC and system time differ by more than 2 seconds, I reset the system time to the RTC time.

To answer your question more directly, if the crystal frequency is perfect AND you choose a PIT period that divides evenly into 1 second, then Secs will get incremented precisely every 1 second, and Secs would be "perfect". With the default NB configuration for MOD5213, with 20 ticks/second, a perfect crystal would lead to a perfect value of Secs. That assumes that you don't miss any PIT interrupts, which should be a safe assumption. If your system is spending so much time at interrupt level that it can miss a PIT interrupt, that's bad.

Joe