Searching \ for '[PIC]: Clock accuracy' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=clock
Search entire site for: 'Clock accuracy'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Clock accuracy'
2002\11\26@070547 by Tauno Siitam

flavicon
face
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_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@074605 by Olin Lathrop

face picon face
>>
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 .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@075234 by Kevin A. Benedict

picon face
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 listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@080304 by Russell McMahon

face
flavicon
face
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 .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@084142 by Tauno Siitam

flavicon
face
> 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_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@090637 by Larry Bradley

flavicon
face
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}

Larry Bradley
Orleans (Ottawa), Ontario, CANADA

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@091443 by Olin Lathrop

face picon face
> 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 KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@123733 by Bob Bullock

flavicon
face
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}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@145151 by Andrew Warren

flavicon
face
Tauno Siitam <TakeThisOuTPICLISTEraseMEspamspam_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 -- RemoveMEaiwspamTakeThisOuTcypress.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 listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\11\26@220523 by Bob Ammerman

picon face
To get  a period of 250 out of TMR2 you set the PR2 register to 249!

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Andrew Warren" <EraseMEaiwspamCYPRESS.COM>
To: <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU>
Sent: Tuesday, November 26, 2002 2:57 PM
Subject: Re: [PIC]: Clock accuracy


{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\11\27@061829 by Russell McMahon

face
flavicon
face
> 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-requestSTOPspamspamspam_OUTmitvma.mit.edu


2002\11\27@081449 by Tauno Siitam

flavicon
face
> 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-requestSTOPspamspamEraseMEmitvma.mit.edu


2002\11\27@095305 by Bob Ammerman

picon face
Just wondering: why am I so many people's uncle?

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Russell McMahon" <KILLspamapptechspamBeGonespamPARADISE.NET.NZ>
To: <EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU>
Sent: Wednesday, November 27, 2002 6:07 AM
Subject: Re: [PIC]: Clock accuracy


{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\11\27@100111 by Bob Ammerman

picon face
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

flavicon
face
On 11/27/02 7:49 AM, "Bob Ammerman" <.....rammermanspam_OUTspamADELPHIA.NET> wrote:

> Just wondering: why am I so many people's uncle?
>
> Bob Ammerman
> RAm Systems

I don't know Uncle Bob, didn't want to get into your personal life on the
Piclist.


lol
dg

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu


2002\11\27@143852 by Mike Singer

picon face
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-requestKILLspamspamspammitvma.mit.edu


2002\11\27@164247 by Mike Singer

picon face
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-requestspamRemoveMEmitvma.mit.edu


2002\11\27@170502 by Spehro Pefhany

picon face
At 11:45 PM 11/27/02 +0300, you wrote:
{Quote hidden}

Use 75% of the maximum R value from the crystal datasheet.

{Quote hidden}

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"
RemoveMEspeffspamspamBeGoneinterlog.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@spamspam_OUTmitvma.mit.edu


2002\11\27@180811 by Mike Singer

picon face
Spehro Pefhany wrote:
> ... When you're whacking a Stradivarius with a sledge-hammer
> you can't expect it to stay in tune.

  I googled with this phrase, but did find nothing.
Who is the author of it, could you tell, please?

  Mike.

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspammitvma.mit.edu


2002\11\27@181501 by Spehro Pefhany

picon face
At 01:10 AM 11/28/02 +0300, you wrote:
>Spehro Pefhany wrote:
> > ... When you're whacking a Stradivarius with a sledge-hammer
> > you can't expect it to stay in tune.
>
>    I googled with this phrase, but did find nothing.
>Who is the author of it, could you tell, please?

C'est moi.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffEraseMEspaminterlog.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
RemoveMEpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2002\11\27@220726 by Dale Botkin

flavicon
face
On Wed, 27 Nov 2002, Spehro Pefhany wrote:

> When you're whacking a Stradivarius with a sledge-hammer you can't
> expect it to stay in tune.

OK, that one makes it into my witty quotes file.

8-)

Dale

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu


2002\11\28@041841 by Tauno Siitam

flavicon
face
> 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

picon face
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

flavicon
face
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

flavicon
face
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}

--
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
picon face
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

face picon face
> 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

picon face
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}

--
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

picon face
> 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

picon face
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

picon face
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

face picon face
> 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

flavicon
face
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 -- EraseMEaiwspam@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

flavicon
face
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

face picon face
> 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

flavicon
face
Olin Lathrop <@spam@PICLISTspam_OUTspam.....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 <spamBeGonePICLISTEraseMEspammitvma.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

face picon face
> 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

picon face
>
>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...