Exact match. Not showing close matches.
PICList
Thread
'[PIC]: Clock accuracy'
2002\11\26@070547
by
Tauno Siitam
|
Hi!
I'm designing a car rally trip computer with PIC16F876. However, I've
not got very far yet. Biggest problem seems to be keeping track of time
accurately.
I'm running PIC with 4MHz crystal oscillator and I've been trying to
implement a clock using TMR2 interrupt. I initialized TMR2 with
prescaler 4, postscaler 1:1 and period 250. So, I'm getting interrupts
every millisecond. When a counter inside ISR reaches 1000 I increment
seconds and zero the counter. Am I right so far? Anyway, clock lags
behind about a second in 4 minutes. IMHO, the error is too big to fix it
only in software. So there must be something else wrong. I'm guessing
4MHz isn't 4MHz accurately enough. I don't have an oscilloscope and I've
not measured the osc frequency yet. I was using 33pF capacitors with
oscillator and replaced them with 15pF - no noticeable change in
accuracy!? I'm planning to test it with another oscillator now.
But I wanted to ask is it possible to design accurate clock using this
approach? Is the oscillator itself stable enough to correct the error in
software? Or is it better to use special temperature controlled watch
oscillator and external RTC chip perhaps? What about DS32kHz
(http://www.maxim-ic.com/quick_view2.cfm?qv_pk=2940)?
Any good advice is greatly appreciated!
Tauno
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuT
mitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@074605
by
Olin Lathrop
>>
I'm running PIC with 4MHz crystal oscillator and I've been trying to
implement a clock using TMR2 interrupt. I initialized TMR2 with
prescaler 4, postscaler 1:1 and period 250. So, I'm getting interrupts
every millisecond. When a counter inside ISR reaches 1000 I increment
seconds and zero the counter. Am I right so far?
<<
Yep. I've done this many times. Your clock should be as accurate as your
crystal.
>>
Anyway, clock lags
behind about a second in 4 minutes.
<<
There is something seriously wrong here. Either your crystal isn't what you
think it is (is it specified for parallel operation?), or you have a bug
that missing some ticks.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspam
@spam@mitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@075234
by
Kevin A. Benedict
Hi Tauno,
Try Roman's page at
http://www.romanblack.com/one_sec.htm
Should be easy to adapt to your needs.
> Hi!
>
> I'm designing a car rally trip computer with PIC16F876.
However, I've
> not got very far yet. Biggest problem seems to be
keeping track of time
> accurately.
>
> I'm running PIC with 4MHz crystal oscillator and I've
been trying to
> implement a clock using TMR2 interrupt.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv
KILLspammitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@080304
by
Russell McMahon
|
I'm running PIC with 4MHz crystal oscillator and I've been trying to
implement a clock using TMR2 interrupt. I initialized TMR2 with
prescaler 4, postscaler 1:1 and period 250. So, I'm getting interrupts
every millisecond. When a counter inside ISR reaches 1000 I increment
seconds and zero the counter. Am I right so far? Anyway, clock lags
behind about a second in 4 minutes. IMHO, the error is too big to fix it
only in software. So there must be something else wrong. I'm guessing
4MHz isn't 4MHz accurately enough. I don't have an oscilloscope and I've
not measured the osc frequency yet. I was using 33pF capacitors with
oscillator and replaced them with 15pF - no noticeable change in
accuracy!? I'm planning to test it with another oscillator now.
______________
1. You appear to have the dread "quoted printable" set. Advise you un-set
if possible (may be caused by your ISP).
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
2. That accuracy is FAR to bad for a crystal oscillator. They won't get
that bad even if you pay them overtime rates.
1 second in 4 minutes is about 0.4% - a ceramic resonator will do better
than that short term.
You can expect 10 to 100 ppm or a second in 3 to 30 hours.
Sherlock Holmes tells us that therefore the code is wrong! (probably :-) )
Most probable cause is that you haven't allowed for the time spent in the
ISR when reloading the counter.
If so the clock will be slow by about
(time in ISR)/(Time between interrupts).
Best trick is to ADD a constant negative amount to the counter at each IRQ
so that it then increments up to the trip point. This works no matter how
late you do the addition (as long as your ISR exits in less than one IRQ
period).
eg
Counter IRQs at 0
Timeout desired every 250 counts
IRQ_to_here:
misc interrupt code
....
Counter = Counter - 250
RETI
RM
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspam
.....mitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@084142
by
Tauno Siitam
> You appear to have the dread "quoted printable" set
What does it mean? I'll look into it...
> Sherlock Holmes tells us that therefore the code is wrong!
> (probably :-) )
Code is wrong! ;-)
> Most probable cause is that you haven't allowed for the time
> spent in the ISR when reloading the counter.
No, that's not it. I chose TMR2 where there is no need to reload any
counters. Compare value PR2 is loaded only once when initializing
interrupts.
But datasheet says: "Timer2 increments from 00h until it matches PR2 and
then resets to 00h on the next increment cycle."
So, instead of PR2 value 250 I should use 249.
Am I right?
Tauno
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUT
TakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@090637
by
Larry Bradley
|
What sort of PIC are you using? I've been playing with an '877, where
timer1 has a built in oscillator. I used a 32768 Hz watch xtal, and get
timer overflow every 2 seconds. By preloading the timer, you can get other
values, or by polling the counter you can measure time in 1/32768 ths of a
second.
larry
At 03:41 PM 11/26/2002 +0200, you wrote:
{Quote hidden}> > You appear to have the dread "quoted printable" set
>
>What does it mean? I'll look into it...
>
> > Sherlock Holmes tells us that therefore the code is wrong!
> > (probably :-) )
>
>Code is wrong! ;-)
>
> > Most probable cause is that you haven't allowed for the time
> > spent in the ISR when reloading the counter.
>
>No, that's not it. I chose TMR2 where there is no need to reload any
>counters. Compare value PR2 is loaded only once when initializing
>interrupts.
>
>But datasheet says: "Timer2 increments from 00h until it matches PR2 and
>then resets to 00h on the next increment cycle."
>
>So, instead of PR2 value 250 I should use 249.
>
>Am I right?
>
>Tauno
>
>--
>
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email
listserv
spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
Larry Bradley
Orleans (Ottawa), Ontario, CANADA
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspam
mitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@091443
by
Olin Lathrop
> Sherlock Holmes tells us that therefore the code is wrong! (probably
:-) )
> Most probable cause is that you haven't allowed for the time spent in
the
> ISR when reloading the counter.
> If so the clock will be slow by about
>
> (time in ISR)/(Time between interrupts).
He is using timer 2 with the hardware period register, not timer 0.
You're right though about adding into timer 0 when using it to divide the
clock by other than 256. Also take into account the number of cycles
timer 0 stops when written to.
Back to the original problem. One possibility is he is setting PR2 to 250
instead of 249. I would have given more detail before, but my reply
looked messy enough due to his insistance on using quoted printable.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspam
mitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@123733
by
Bob Bullock
|
Your theory seems correct so it's either hardware or software. If
hardware, the most common problem would be using a series cut crystal
instead of a parallel cut. To check the software use the Microchip
simulator. Set a break point in the interrupt routine where you increment
your 1 ms counter, run to the break point, open the stopwatch and reset it,
run to next break point. you should be within a cycle of 1000, run it a few
times more to be sure of the behavior.
Even though I have an ICE2000, I test as much of the code as I can during
development with the simulator first.
Bob Bullock
Embedded Systems Consultant (currently available)
At 07:44 AM 11/26/2002 -0500, you wrote:
{Quote hidden}> >>
>I'm running PIC with 4MHz crystal oscillator and I've been trying to
>implement a clock using TMR2 interrupt. I initialized TMR2 with
>prescaler 4, postscaler 1:1 and period 250. So, I'm getting interrupts
>every millisecond. When a counter inside ISR reaches 1000 I increment
>seconds and zero the counter. Am I right so far?
><<
>
>Yep. I've done this many times. Your clock should be as accurate as your
>crystal.
>
> >>
>Anyway, clock lags
>behind about a second in 4 minutes.
><<
>
>There is something seriously wrong here. Either your crystal isn't what you
>think it is (is it specified for parallel operation?), or you have a bug
>that missing some ticks.
>
>
>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014,
http://www.embedinc.com
>
>--
>
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email
RemoveMElistservTakeThisOuT
mitvma.mit.edu with SET PICList DIGEST in the body
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGone
mitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@145151
by
Andrew Warren
Tauno Siitam <TakeThisOuTPICLISTEraseME
spam_OUTmitvma.mit.edu> wrote:
> I initialized TMR2 with prescaler 4, postscaler 1:1 and period 250.
> ....
> clock lags behind about a second in 4 minutes. IMHO, the error is
> too big to fix it only in software. So there must be something else
> wrong.
Your humble opinion is almost certainly wrong.
"About a second in 4 minutes" is the same as 1 in 250. 250 is
your period, so your software is probably off by one somewhere.
-Andy
=== Andrew Warren -- RemoveMEaiw
TakeThisOuTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseME
.....mitvma.mit.edu with SET PICList DIGEST in the body
2002\11\26@220523
by
Bob Ammerman
2002\11\27@061829
by
Russell McMahon
> To get a period of 250 out of TMR2 you set the PR2 register to 249!
And bingo, Bob's your uncle.
251/250 too long = 1 in 250 = 1 extra second per 4 minutes 10 seconds.
QED.
I think Bob, and Andrew Warren with a more general take on the same thing,
have hit the nail on the head.
RM
> > > I initialized TMR2 with prescaler 4, postscaler 1:1 and period 250.
> > > ....
> > > clock lags behind about a second in 4 minutes. IMHO, the error is
> > > too big to fix it only in software. So there must be something else
> > > wrong.
> >
--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspam
spam_OUTmitvma.mit.edu
2002\11\27@081449
by
Tauno Siitam
> To get a period of 250 out of TMR2 you set the PR2 register to 249!
Well, thanks, I'll never forget it now. After doing some extensive
measurements I managed to trim osc freq to 3.99999MHz. But measuring
TMR2 interrupt rate gave me a result of 1000.074Hz!? How do you explain
that? I trust my measuring devices were right. How can it be faster than
1000Hz? What am I missing now?
Tauno
[OT]: I'm still in the middle of explaining to our Exchange admin why I
don't want quoted-printable encoding applied to my outgoing messages and
there isn't anything I can do myself except send my messages under
another environment. Sorry 'bout that...
--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspam
EraseMEmitvma.mit.edu
2002\11\27@095305
by
Bob Ammerman
2002\11\27@100111
by
Bob Ammerman
If you are measuring your OSC frequency with a probe directly on the OSC pin
then you will be loading it. When you remove the probe the frequency will
change.
I suggest you trim your OSC by measusing the TMR2 rate at 1000 Hz.
Note: Don't expect too much accuracy out of your run-of-the-mill crystal
based oscillator. You will get significant drift over time, temperature, and
I believe supply voltage.
Bob Ammerman
RAm Systems
{Original Message removed}
2002\11\27@102702
by
Dave Gomez
2002\11\27@143852
by
Mike Singer
Tauno Siitam wrote:
> [OT]: I'm still in the middle of explaining to our
> Exchange admin why I don't want quoted-printable
> encoding applied to my outgoing messages and
> there isn't anything I can do myself except send
> my messages under another environment. Sorry 'bout that...
May be MSDN article Q278134:
"How Outlook Applies Encoding to Plain Text Messages"
could help your Exchange admin.
Mike.
--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestKILLspam
spammitvma.mit.edu
2002\11\27@164247
by
Mike Singer
|
Bob Ammerman wrote:
> Note: Don't expect too much accuracy out of your
> run-of-the-mill crystal based oscillator. You will get
> significant drift over time, temperature, and I believe
> supply voltage.
"...and I believe supply voltage" - Bob, two weeks ago
I've received few PIC16F871 from local Microchip folks
(http://www.microchip.com.ua) . Also received crystals from
them for these PICs. Crystals were 20 MHz without any
additional information.
If I were Olin, I'd rather just stick them to these PICs. :-)
Look at his posting:
"Re: [PIC]: Serial resistor for the oscillator of a PIC16F876"
on 2002-07-09 :
> > The point is that I need to know some suitable value
> > for the serial RESISTOR
> I always use 0Ohms. Where did you get the idea from
> to put a resistor there anyway? I don't recall ever seeing
> a resistor in any Microchip documentation.
But I asked local Microchip folks about crystals'
parameters. They sent me datasheet from witch I've
found out that crystals were
Jauch Quartz HC49/U4H SS4 0.1 mW max drive level!
From Microchip AN826 Crystal Oscillator Basics:
Power dissipation of the crystal can be computed by
P = E^2 / R1 where E is rms voltage across the crystal.
R1 is known to be about max 100 Ohm at 20 Mhz.
So aprox max P would be 2v^2 / 2 / 100 Ohm = 20 mW.
Too much for 0.1 mW max drive level crystal.
Of course, "You will get significant drift over time..." :-)
...........................
Mike.
Correct me if I'm wrong, please.
--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request
RemoveMEmitvma.mit.edu
2002\11\27@170502
by
Spehro Pefhany
|
At 11:45 PM 11/27/02 +0300, you wrote:
{Quote hidden}>Bob Ammerman wrote:
> > Note: Don't expect too much accuracy out of your
> > run-of-the-mill crystal based oscillator. You will get
> > significant drift over time, temperature, and I believe
> > supply voltage.
>
>"...and I believe supply voltage" - Bob, two weeks ago
>I've received few PIC16F871 from local Microchip folks
>(
http://www.microchip.com.ua) . Also received crystals from
>them for these PICs. Crystals were 20 MHz without any
>additional information.
> If I were Olin, I'd rather just stick them to these PICs. :-)
>Look at his posting:
>"Re: [PIC]: Serial resistor for the oscillator of a PIC16F876"
>on 2002-07-09 :
> > > The point is that I need to know some suitable value
> > > for the serial RESISTOR
> > I always use 0Ohms. Where did you get the idea from
> > to put a resistor there anyway? I don't recall ever seeing
> > a resistor in any Microchip documentation.
>
> But I asked local Microchip folks about crystals'
>parameters. They sent me datasheet from witch I've
>found out that crystals were
>
>Jauch Quartz HC49/U4H SS4 0.1 mW max drive level!
>
> From Microchip AN826 Crystal Oscillator Basics:
>Power dissipation of the crystal can be computed by
>
>P = E^2 / R1 where E is rms voltage across the crystal.
>
>R1 is known to be about max 100 Ohm at 20 Mhz.
Use 75% of the maximum R value from the crystal datasheet.
{Quote hidden}>So aprox max P would be 2v^2 / 2 / 100 Ohm = 20 mW.
>
>Too much for 0.1 mW max drive level crystal.
>
>Of course, "You will get significant drift over time..." :-)
>
>...........................
>
>Mike.
>Correct me if I'm wrong, please.
Right as rain, Mike. That's an upper bound, but the point is that
it's probably WAY over 100 microwatts. When you're whacking a
Stradivarius with a sledge-hammer you can't expect it to stay in tune.
Best regards,
Spehro Pefhany --"it's the network..." "The Journey is the reward"
RemoveMEspeff
spamBeGoneinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@
spam_OUTmitvma.mit.edu
2002\11\27@180811
by
Mike Singer
2002\11\27@181501
by
Spehro Pefhany
2002\11\27@220726
by
Dale Botkin
2002\11\28@041841
by
Tauno Siitam
> Note: Don't expect too much accuracy out of your
> run-of-the-mill crystal based oscillator.
> You will get significant drift over time,
> temperature, and I believe supply voltage.
How large drift can I expect to be caused by temperature changes? I left
my clock running last night and it was ahead 1 second after 3 hours and
then stayed behind 4 seconds during next 6 hours. If the room
temperature day/night change caused such a drift, what can you expect
from extreme conditions in a rally car where temperature can change from
-20C in the winter to +60C under the sun in the summer!? I'm starting to
believe that using some kind of temperature controlled osc is a must in
my case...
Tauno
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2002\11\28@044026
by
Claudio Tagliola
Maybe a bit offbeat here, but isn't there a possibility to hook up a GPS
receiver to
sync with that time signal? If you're into rally racing, other GPS info may
be mighty interesting as well.
Regards,
Claudio
-----Oorspronkelijk bericht-----
How large drift can I expect to be caused by temperature changes? I left
my clock running last night and it was ahead 1 second after 3 hours and
then stayed behind 4 seconds during next 6 hours. If the room
temperature day/night change caused such a drift, what can you expect
from extreme conditions in a rally car where temperature can change from
-20C in the winter to +60C under the sun in the summer!? I'm starting to
believe that using some kind of temperature controlled osc is a must in
my case...
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2002\11\28@120930
by
Chris Hunter
Whenever I've needed significant time / frequency accuracy, I've always used
an off-air frequency standard. We have a couple of MF transmitters in the
UK with spectacular stability, and these are easily frequency multiplied or
divided to whatever you need. However, in MOST instances, a standard rock
is accurate enough!
Chris
{Original Message removed}
2002\11\29@020703
by
Brooke Clarke
|
Hello:
I'm now working on a precision clock where hopfully the initial frequency offset, temperature effects and aging will be corrected. I'm using a 20 MHz (or 10 MHz) unit oscillator because it saves a pin on the
12F675. Some typical data are:
26 deg C 19,999,740 Hz
55 deg C 19,999,600 Hz
70 deg C 19,999,650 Hz
Have Fun,
Brooke Clarke, N6GCE
http://www.precisionclock.com
{Quote hidden}> How large drift can I expect to be caused by temperature changes? I left
> my clock running last night and it was ahead 1 second after 3 hours and
> then stayed behind 4 seconds during next 6 hours. If the room
> temperature day/night change caused such a drift, what can you expect
> from extreme conditions in a rally car where temperature can change from
> -20C in the winter to +60C under the sun in the summer!? I'm starting to
> believe that using some kind of temperature controlled osc is a must in
> my case...
>
> Tauno
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
'[PIC]: Clock accuracy'
2003\02\07@112050
by
Ren
There are a couple of different approaches for accurate timing. Maxim/Dallas
makes a time keeping chip with a built in battery. The other alternative is
to get a 32.768k crystal and a divider to derive seconds.
{Original Message removed}
2003\02\07@123921
by
Olin Lathrop
> When a counter inside ISR reaches 1000 I increment
> seconds and zero the counter. Am I right so far?
Yes, but you are using a 16 bit counter for the 1000 milliseconds, right?
> Anyway, clock lags
> behind about a second in 4 minutes. IMHO, the error is too big to fix it
> only in software. So there must be something else wrong. I'm guessing
> 4MHz isn't 4MHz accurately enough. I don't have an oscilloscope and I've
> not measured the osc frequency yet. I was using 33pF capacitors with
> oscillator and replaced them with 15pF - no noticeable change in
> accuracy!? I'm planning to test it with another oscillator now.
Are you sure the crystal is specified for parallel resonance application?
That would make it off a little, but not enough to see on a scope. You
pretty much need a frequency counter or take longer term measurements to
notice the difference.
> But I wanted to ask is it possible to design accurate clock using this
> approach?
You can get as accurate as the crystal.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@143302
by
Robert Rolf
|
Counting from 0 to 1000 is dividing by 1001 NOT 1000. Over 4 minutes
that's an error of 240/1000 =1/4 second. Since it's a error in your
constant, it is easily fixed in software. Use 999 as your boundary.
The vast majority of these sorts of problems are due to using the
wrong divisor.
There were several threads last year on doing highly accurate time counting
using the timer and software corrections for frequency errors. (residual
accumulation).
Robert
Olin Lathrop wrote:
{Quote hidden}>
> > When a counter inside ISR reaches 1000 I increment
> > seconds and zero the counter. Am I right so far?
>
> Yes, but you are using a 16 bit counter for the 1000 milliseconds, right?
>
> > Anyway, clock lags
> > behind about a second in 4 minutes. IMHO, the error is too big to fix it
> > only in software. So there must be something else wrong. I'm guessing
> > 4MHz isn't 4MHz accurately enough. I don't have an oscilloscope and I've
> > not measured the osc frequency yet. I was using 33pF capacitors with
> > oscillator and replaced them with 15pF - no noticeable change in
> > accuracy!? I'm planning to test it with another oscillator now.
>
> Are you sure the crystal is specified for parallel resonance application?
> That would make it off a little, but not enough to see on a scope. You
> pretty much need a frequency counter or take longer term measurements to
> notice the difference.
>
> > But I wanted to ask is it possible to design accurate clock using this
> > approach?
>
> You can get as accurate as the crystal.
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014,
http://www.embedinc.com
>
> --
>
http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See
http://www.piclist.com/#topics
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@150822
by
michael brown
|
> I'm running PIC with 4MHz crystal oscillator and I've been trying to
> implement a clock using TMR2 interrupt. I initialized TMR2 with
> prescaler 4, postscaler 1:1 and period 250. So, I'm getting
> interrupts every millisecond. When a counter inside ISR reaches 1000
> I increment seconds and zero the counter. Am I right so far? Anyway,
> clock lags behind about a second in 4 minutes. IMHO, the error is too
> big to fix it only in software. So there must be something else
> wrong. I'm guessing 4MHz isn't 4MHz accurately enough. I don't have
> an oscilloscope and I've not measured the osc frequency yet. I was
> using 33pF capacitors with oscillator and replaced them with 15pF -
> no noticeable change in accuracy!? I'm planning to test it with
> another oscillator now.
Are you moving a 250 to PR2 or 249? 249 is the correct value to use not 250.
michael brown
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@151027
by
michael brown
On Friday 07 February 2003 01:29 pm, you wrote:
> Counting from 0 to 1000 is dividing by 1001 NOT 1000. Over 4 minutes
> that's an error of 240/1000 =1/4 second. Since it's a error in your
> constant, it is easily fixed in software. Use 999 as your boundary.
I respectfully disagree. If, when the loop ctr = 1000, he resets it to 0. Then the next pass thru will be incremented to one. On the pass that increments to 1000, that will be the 1000'th itteration. As long as he increments and then checks the count, he will get it right.
> The vast majority of these sorts of problems are due to using the
> wrong divisor.
I think he's loading PR2 with 250 instead of 249. Same story, different twist. ;-)
michael brown
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@155543
by
Robert Rolf
|
michael brown wrote:
> On Friday 07 February 2003 01:29 pm, you wrote:
> > Counting from 0 to 1000 is dividing by 1001 NOT 1000. Over 4 minutes
> > that's an error of 240/1000 =1/4 second. Since it's a error in your
> > constant, it is easily fixed in software. Use 999 as your boundary.
>
> I respectfully disagree. If, when the loop ctr = 1000, he resets it to
> 0. Then the next pass thru will be incremented to one. On the pass
Right.
> that increments to 1000, that will be the 1000'th itteration. As long
> as he increments and then checks the count, he will get it right.
I've always found it more efficient to load the upper bound and then
count down to zero. Then you're not having to do a multibyte compare, just
a test for zero. And only test the high byte for zero if the low byte is
zero too (as part of your 'borrow' code).
That way you're checking the upper byte 256 times less often.
> > The vast majority of these sorts of problems are due to using the
> > wrong divisor.
>
> I think he's loading PR2 with 250 instead of 249. Same story, different
> twist. ;-)
That's his problem. 1/250 * 240 seconds = .96 seconds, nearly the error
he saw.
Robert
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@162906
by
Olin Lathrop
> Are you moving a 250 to PR2 or 249? 249 is the
> correct value to use not 250.
If you'd like to avoid this type of mistake in the future, check out my
TIMER2_USEC and TIMER2_SETUP_INTR macros in STD.INS.ASPIC at
http://www.embedinc.com/pic. TIMER2_USEC takes the desired timer 2 period
in microseconds and automatically computes the prescaler, period, and
postscaler values. TIMER2_SETUP_INTR takes these values, generates an
assebly error if they are invalid, and sets up the timer 2 hardware to
generate the periodic interrupt. The off by one characteristic of the PR2
register is hidden inside TIMER2_SETUP_INTR. In other words, you specify
the period (assuming you don't let TIMER2_USEC compute it automatically)
as 250, but it writes 249 to the PR2 register.
Click on the SOFTWARE DOWNLOADS link at the bottom of the page to download
the complete PIC build environment that these macros are a part of.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@164742
by
Andrew Warren
Guys...
This thread (and the others to which Ren is replying today) is SIX
MONTHS OLD.
The problem was solved back then (the one-second-in-four-minutes
inaccuracy was correctly identified by one of us as an off-by-one
error in a 250-count timer), and doesn't need to be revisited again.
PLEASE check the dates on the messages to which you're replying, and
let's not fill the list with endless regurgitations of discussions
we've already had.
Thanks.
-Andy
=== Andrew Warren -- EraseMEaiw
@spam@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@164943
by
Larry Bradley
|
part 1 5626 bytes content-type:text/plain; charset="us-ascii"; format=flowedI had the same problem - I wanted a time-of-day clock that was quite
accurate - at least as good as my watch!
I first tried using a 32768 watch xtal on the T1OSC ports - worked well -
but poor accuracy.
I then used the 20 mHz xtal and timer1 set up to roll over every 50,000
counts, giving a 10 msec interrupt rate. Still poor accuracy.
The xtals used for PICs typically are accurate to 50 ppm at 25 deg C. In 24
hours, there are 24*60*60=86,400 seconds. 50 ppm is 1 part in 20,000 - 4
seconds per day.
Your results are far worse than this, so something else is wrong.
I'll attach a file showing what I did -the main program is written in
PicBasicPro, but with the interrupt routine in assembler - you should be
able to get the idea. In the assembler routine, the Picbasic variables are
prefixed with an underscore.
Preloading Timer1 (a 16 bit timer) while the timer is running can get you
into grief, so I turned off the timer while preloading the low byte (the
high byte won't change in that short a time), then turned it back on again.
I then compensate in the preload constant for the time the timer was disabled.
As well, there is some latency from the time the interrupt occurs until you
actually start to do the preload - in other words, the timer count is not
zero when you actually start to preload. So rather than just loading in the
preload value , I add it existing timer value.
And when I tested the timer, I found some errors, so I adjusted the preload
by another correction constant.
All of this gets the beast to be as accurate as the xtal.
I checked this out by having a test program read the time from my PC, which
I have synced to the atomic clocks on the internet (I'm using Win2000,
which can do this) and comparing the PC. Comparing the two times over a 24
hour period let me adjust the correction constant to get the time as
accurate as possible. But since one count is 1 part in 50,000 (the nominal
preload value), it still wasn't as accurate as I wanted.
So I added some code to do additional compensation. I ran the test for
several days, and determined the difference in times. I then
calculated how many minutes it took for the timer error to be 10
milliseconds. The compensation code adds 10 milliseconds every "comp_mins"
minutes, (in my case, the timer ran slow by 10 msec every 15 minutes).
I later changed from getting the time from my PC to getting the time from
my GPS - that made the testing easier, since the GPS sends out the time
every second EXACTLY - I could measure over a shorter period of time. I
managed to get the clock to be within a couple of 10's of milliseconds over
7 days.
But you don't need to connect it to a PC - you can just note the PC's time,
and the PICs time. Then 24 hours later do it again, figure out the
correction, and away you go. To do this, the PC MUST be synced to the
atomic time, since the PC clock will be out a few seconds per day. You can
also just use your watch or a clock.
The code is based on a 20 mHz xtal. If you use a 4 mHz xtal and the same
preload constant (nominally 50,000) you will get an interrupt every 50
msecs, not every 10 msecs, so you will have to change things for that.
I hope this helps a bit.
Larry
At 10:17 AM 2/7/2003 -0600, you wrote:
>There are a couple of different approaches for accurate timing. Maxim/Dallas
>makes a time keeping chip with a built in battery. The other alternative is
>to get a 32.768k crystal and a divider to derive seconds.
>
>{Original Message removed}
part 2 8171 bytes content-type:text/plain; charset="us-ascii"
@ device hs_osc,wdt_off
DEFINE __16F877 1 ' Required for PM assembler
DEFINE OSC 20
DEFINE DEBUG_REG PORTB
DEFINE DEBUG_BIT 7
DEFINE DEBUG_BAUD 9600
DEFINE DEBUG_MODE 1
DEFINE DEBUGIN_REG PORTB
DEFINE DEBUGIN_BIT 6
DEFINE DEBUGIN_MODE 1
DEFINE LCD_DREG PORTD
DEFINE LCD_DBIT 4
DEFINE LCD_RSREG PORTC
DEFINE LCD_RSBIT 6
DEFINE LCD_EREG PORTC
DEFINE LCD_EBIT 7
DEFINE LCD_BITS 4
DEFINE LCD_LINES 2
DEFINE LCD_COMMANDUS 2000
DEFINE LCD_DATAUS 50
DEFINE INTHAND timerint
wsave VAR BYTE $7f system ; In COMMON memory on a '877A or a '628
'wsave1 VAR BYTE $C0 system
'wsave2 VAR BYTE $140 system
'wsave3 VAR BYTE $1c0 system
ssave VAR BYTE bank0 system
psave VAR BYTE bank0 system
' Timer use:
'
'
' Timer1 variables & Constants
TimerSetup CON %00000001 'no prescaler ; enable; int osc (20/4 = 5 mHz
TimerRegister VAR T1CON
TimerOverflow VAR PIR1.0
TimerCount VAR TMR1
' Time 0f day accumulator
tod_seconds VAR BYTE bank0
tod_minutes VAR BYTE bank0
tod_hours VAR BYTE bank0
tod_10msec VAR BYTE bank0
' Counter for clock correction
' The number of hours after which we add or subtract one second
tod_compensation VAR BYTE bank0
comp_mins CON 15
btn_time VAR WORD bank0
t1 VAR BYTE
t2 VAR WORD
hours VAR BYTE
MINs VAR BYTE
secs VAR BYTE
msecs VAR BYTE
GoTo start
Asm
; W,STATUS and PCLATH have been saved already
interval equ 50000
correction equ -8
preload equ 65536 - interval + 4 + correction
preloadH equ preload >> 8
preloadL equ preload & 0x00FF
timerint
bcf STATUS,RP0 ; bank 0
btfss PIR1,TMR1IF ; Timer interrupt?
GoTo intdone ;no
bcf PIR1,TMR1IF ; Turn off timer overflow flag
; Set timer so it interruts every 10 millisecond
; This requires presetting counter to 65536 - 50000
; However, the timer is disabled for "k" instruction cycles while we
; set up the preload, so if we enable it, when it interrupts again
; the interval will be "k" cycles too long. Thus we need to subtract
; "k" counts from the interval, or add "k" counts to the preload
; PRELOAD = 65536 + k
;
; We also need to apply a correction based on measurement of the time
; Also, by the time we get to the code to turn off the timer,
; "m" counts have elapsed due to instructions run bewteen the
; time the interrupt went off till we stop the timer
; "m" is the value in TMR1L at the instant we stop the timer
; If we ignore this, and just preload to 10 ms, the next interrupt
; will be "m" counts to late - the interval will be too long.
; Thus we need to subtract "m" from the interval, or ADD "m"
; to the preload
; Thus PRELOAD = 65536 - 50000 + k + m
bcf T1CON,TMR1ON ; Turn off timer
movf TMR1L,w ; Add current value of timer low byte
addlw preloadL ; and the low byte of the preload
movwf TMR1L ; and save back into timer low byte
bsf T1CON,TMR1ON ; Turn on timer
; We can put this outside the timer disable code, since the
; high byte can't roll over in the short interval from enabling
; it to setting the high byte
; High byte is 0 on interrupt
; Add 1 if the low byte add caused a carry
; then add in the high byte preload
btfsc STATUS,C ; If carry set from low byte add,
incf TMR1H ; add 1 to timer high byte
movf TMR1H,w ; Add timer high byte
addlw preloadH ; and preloadf high byte
movwf TMR1H ; and save into timer high byte
; Bump 10 msec counter; if 100 of these, then we have 1 second
movlw 1
addwf _tod_10msec,f
movlw 100
subwf _tod_10msec,w
btfss STATUS,C
GoTo intdone
clrf _tod_10msec ;zero
; Increment seconds
movlw 1
addwf _tod_seconds,f
movlw 60
subwf _tod_seconds,w
btfss STATUS,C
GoTo intdone
clrf _tod_seconds ; >= 60: set to 0
; Increment minutes
; Decrement and test the compensation counter
decfsz _tod_compensation
GoTo timer2 ; not zero - carry on
; Compensation counter is zero - reload
movlw _comp_mins
movwf _tod_compensation
; Now add one 10msec count
; 10Msec, seconds are zero at this point, otherwise we wouldn't be here
; so all we need to do is load the 10msec counter with +1
movlw 1
addwf _tod_10msec,f
timer2
movlw 1
addwf _tod_minutes,f
movlw 60
subwf _tod_minutes,w
btfss STATUS,C
GoTo intdone
clrf _tod_minutes
; Increment hours
movlw 1
addwf _tod_hours,f
movlw 24
subwf _tod_hours,w
btfss STATUS,C
GoTo intdone
clrf _tod_hours
intdone
; return from interrupt
; restore w, pclasth, adn status
movf psave,w
movwf pclath
swapf ssave,w
movwf status
swapf wsave,f
swapf wsave,w
retfie
EndAsm
greenled VAR PORTD.3
redled VAR PORTD.2
start_d VAR BYTE
start_h VAR BYTE
start_m VAR BYTE
start_s VAR BYTE
start_ms VAR BYTE
delta_sec VAR BYTE
delta_min VAR BYTE
delta_hours VAR BYTE
delta_t VAR WORD
delta_m VAR WORD
day VAR BYTE
start:
Clear
High redled
Low greenled
Output PORTB.0
Debug 13,10,"Initializing"
Pause 1000
' Set up timer
TimerCount = 15542 ' Initialize for 10 msec interrupt
'Debug 13,10,"Set Time:"
'DebugIn [wait(27),DEC2 tod_hours,DEC2 tod_minutes,DEC2 tod_seconds,DEC2 tod_10msec,skip 2]
'Debug 13,10
LCDOut $fe,1 'clear lcd
PIE1.0 = 1 'Enable timer1 ints
INTCON.6 = 1 'Enable peripheral ints
INTCON.7 = 1 'Enable global interuupts
tod_compensation = comp_hours
' Set the time initially
DebugIn [wait(27),DEC2 start_d, DEC2 start_h,DEC2 start_m,DEC2 start_s,DEC2 start_ms,skip 2]
tod_hours = start_h
tod_minutes = start_m
tod_seconds = start_s
tod_10msec = start_ms/10
TimerRegister = TimerSetup ' Start timer one
LCDOut $fe,$80,DEC2 Start_d,"/",DEC2 start_h,":",DEC2 start_m,":",DEC2 start_s
LCDOut $fe,$80+$40,DEC2 tod_hours,":",DEC2 tod_minutes,":",DEC2 tod_seconds
loop:
' Read time
DebugIn 1000,timeout,[wait(27),DEC2 day,DEC2 hours,DEC2 mins,DEC2 secs,DEC3 msecs,skip 2]
' Compare PIC time to PC time
' and compute correction factor
delta_sec = secs - tod_seconds
delta_min = mins - tod_minutes
delta_hours = hours - tod_hours
delta_t = delta_sec + 60 * delta_min + 3600 * delta_hours
delta_m = msecs/10 - tod_10msec
Toggle redled
Toggle greenled
'Pause 999
'Debug DEC2 tod_hours,DEC2 tod_minutes,DEC2 tod_seconds,DEC2 tod_10msec,13,10
'Debug 13,10,DEC t1," ",DEC 65535 - t2 + 1
timeout:
LCDOut $fe,$80,DEC2 day,"/",DEC2 start_h,":",DEC2 start_m,":",DEC2 start_s
LCDOut $fe,$80+$40,DEC2 tod_hours,":",DEC2 tod_minutes,":",DEC2 tod_seconds,".",DEC2 tod_10msec
LCDOut $fe,$80+$40+13,DEC2 day,"/",DEC2 hours,":",DEC2 mins,":",DEC2 secs
LCDOut $fe,$80+12,DEC5 delta_t,".",DEC2 delta_m
GoTo loop
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
part 3 2 bytes
-
2003\02\07@172936
by
Olin Lathrop
> Guys...
>
> This thread (and the others to which Ren is replying today) is SIX
> MONTHS OLD.
>
> The problem was solved back then (the one-second-in-four-minutes
> inaccuracy was correctly identified by one of us as an off-by-one
> error in a 250-count timer), and doesn't need to be revisited again.
>
> PLEASE check the dates on the messages to which you're replying, and
> let's not fill the list with endless regurgitations of discussions
> we've already had.
Wow, I had no idea this thread was that old. I didn't notice the date.
But I only did replies, so how did such an old message end up appearing
recently? Did some mail system clean out a dusty old buffer? Sounds
rather implosible.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@174845
by
Andrew Warren
|
Olin Lathrop <@spam@PICLISTspam_OUT
.....mitvma.mit.edu> wrote (quoting me):
> > This thread (and the others to which Ren is replying today) is
> > SIX MONTHS OLD.
>
> Wow, I had no idea this thread was that old. I didn't notice the
> date. But I only did replies, so how did such an old message end
> up appearing recently? Did some mail system clean out a dusty old
> buffer? Sounds rather implosible.
Olin:
A MACHINE didn't make the messages appear now; a person named Ren
did. For reasons we may never understand, he's replying today to
piclist messages that are many months old. Here's the start of one
of his messages; look at the date on the quoted message to which he's
replying:
Ren <spamBeGonePICLISTEraseME
mitvma.mit.edu> wrote:
> There are a couple of different approaches for accurate
> timing. Maxim/Dallas makes a time keeping chip with a built
> in battery. The other alternative is to get a 32.768k crystal
> and a divider to derive seconds.
>
> {Original Message removed}
2003\02\07@182659
by
Olin Lathrop
> A MACHINE didn't make the messages appear now; a person named Ren
> did. For reasons we may never understand, he's replying today to
> piclist messages that are many months old.
What a bozo! Just when the REPLY-TO address problem was fixed and you
thought replying was idiot proof, up pops a better idiot.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2003\02\07@200717
by
Reginald Neale
>
>I checked this out by having a test program read the time from my PC, which
>I have synced to the atomic clocks on the internet (I'm using Win2000,
>which can do this) and comparing the PC. Comparing the two times over a 24
>hour period let me adjust the correction constant to get the time as
>accurate as possible. But since one count is 1 part in 50,000 (the nominal
>preload value), it still wasn't as accurate as I wanted.
If you have a WWV receiver with audio out, and an oscilloscope with
an expanded time base, there is a quick way to check drift.
Use the 1-second tick from your clock to trigger the scope. View the
output from your receiver on the scope with the expanded time base.
You can see changes of milliseconds/hour very easily. The expansion
further amplifies the rate of change.
Reg Neale
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
More... (looser matching)
- Last day of these posts
- In 2003
, 2004 only
- Today
- New search...