TMR2 is set up to fire 100 times per second and the interrupt routine simply sets a flag that is handled in the main loop. In the main loop I calculate tenths of seconds, seconds, hours, days, nothing fancy. (add value, check rollover unit, if rollover increment next unit and reset, etc.)
Over the course of 24 hours the program gains about 10 seconds, compared to the clock on my PC. The clock on my PC is updated via the internet daily.
I just wanted to confirm that this is 'normal'. Thanks in advance.
[solved] Timing - using TMR2
Moderator: Benj
- Jan Lichtenbelt
- Posts: 797
- Joined: Tue Feb 17, 2009 8:35 pm
- Location: Haren GN, the Netherlands
- Has thanked: 128 times
- Been thanked: 264 times
- Contact:
Re: Timing - using TMR2
Dear dbasnett,
What is normal? That the PC updated the clock with internet? Although my PC says it does, in practice it doesn't. I have to do that manually.
Or is the 10 seconds/day deviation as expected for the accuracy of the crystal used?
Kind regards
Jan
What is normal? That the PC updated the clock with internet? Although my PC says it does, in practice it doesn't. I have to do that manually.
Or is the 10 seconds/day deviation as expected for the accuracy of the crystal used?
Kind regards
Jan
-
- Matrix Staff
- Posts: 9520
- Joined: Sat May 05, 2007 2:27 pm
- Location: Northamptonshire, UK
- Has thanked: 2585 times
- Been thanked: 3815 times
- Contact:
Re: Timing - using TMR2
If you would like to post your flowchart, then I can look at it for you.
I would expect the time to be more accurate than that, Epically using an external crystal.
Martin
I would expect the time to be more accurate than that, Epically using an external crystal.
Martin
Martin
-
- Posts: 125
- Joined: Mon Aug 15, 2011 1:54 pm
- Has thanked: 8 times
- Been thanked: 11 times
- Contact:
Re: Timing - using TMR2
My question is if I have TMR2 set to fire 100 times per second, how accurate will it be over long periods of time? In other words, does it fire exactly 100 times per second or about 100 times per second(i.e. 99.9 times per second)?
-
- Valued Contributor
- Posts: 548
- Joined: Tue Jun 26, 2007 11:23 am
- Has thanked: 6 times
- Been thanked: 44 times
- Contact:
Re: Timing - using TMR2
The standard xtals used have a typical tolerance of +/-50ppm. This affects all operations in the microcontroller and could directly contribute nearly 4.5 seconds of drift within a counter/timer over a 24 hour period (86400 seconds).
The load capacitors used in the oscillator circuit also have 'typical' values, but may mot be a perfect match for an individual xtal, resulting in additional frequency drift. Your figures indicate a total drift of approximately 115ppm.
There are higher specification xtals, and more advanced oscillator circuits, that could produce a more accurate and stable clock frequency if required.
The load capacitors used in the oscillator circuit also have 'typical' values, but may mot be a perfect match for an individual xtal, resulting in additional frequency drift. Your figures indicate a total drift of approximately 115ppm.
There are higher specification xtals, and more advanced oscillator circuits, that could produce a more accurate and stable clock frequency if required.
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: Timing - using TMR2
Most RTC applications use a low frequency 32.768KHz watch crystal. These use the same low cost standard tolerance crystals but because they are running at a much lower frequency the ppm error becomes much more negligible.
20MHz crystal with +/- 50ppm error : Max error = 20 x 50 = 1KHz which equates to +/- 8640 clocks per 24 hours.
32.768KHz crystal with +/- 50ppm error : Max error = 0.032768 x 50 = 1.6384H which equates to +/- 10 clocks per 24 hours.
Me and Sean are at odds on this, though I remember investigating this at college so hopefully I'm not far off.
20MHz crystal with +/- 50ppm error : Max error = 20 x 50 = 1KHz which equates to +/- 8640 clocks per 24 hours.
32.768KHz crystal with +/- 50ppm error : Max error = 0.032768 x 50 = 1.6384H which equates to +/- 10 clocks per 24 hours.
Me and Sean are at odds on this, though I remember investigating this at college so hopefully I'm not far off.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
-
- Posts: 125
- Joined: Mon Aug 15, 2011 1:54 pm
- Has thanked: 8 times
- Been thanked: 11 times
- Contact:
Re: Timing - using TMR2
Thanks. I was just looking for confirmation, which you have both provided. I am gaining about 10 seconds / 24 hours which means that the clock is 99.988% accurate.
-
- Posts: 125
- Joined: Mon Aug 15, 2011 1:54 pm
- Has thanked: 8 times
- Been thanked: 11 times
- Contact:
Re: [solved] Timing - using TMR2
Added code to adjust the clock by hundredths of a second per hour. This fixed the drift.
-
- Posts: 125
- Joined: Mon Aug 15, 2011 1:54 pm
- Has thanked: 8 times
- Been thanked: 11 times
- Contact:
Re: [solved] Timing - using TMR2
I learned something about the time on my PC when I noticed that the clock on the EB006 was off by several seconds after re-booting my PC. The details are here
http://social.msdn.microsoft.com/Forums ... 05a49365a1
http://social.msdn.microsoft.com/Forums ... 05a49365a1