Post by thread:[PIC]: Clock accuracy

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

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

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

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

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

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 listservspam_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@listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

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

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 RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spamBeGonelistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

Tauno Siitam <TakeThisOuTPICLISTEraseMEspam_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 -- RemoveMEaiwTakeThisOuTcypress.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

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" <EraseMEaiwCYPRESS.COM> To: <RemoveMEPICLISTEraseMEEraseMEMITVMA.MIT.EDU> Sent: Tuesday, November 26, 2002 2:57 PM Subject: Re: [PIC]: Clock accuracy {Quote hidden}> Tauno Siitam <RemoveMEPICLISTspam_OUTKILLspammitvma.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 -- RemoveMEaiwTakeThisOuTspamcypress.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 EraseMElistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

> 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-requestSTOPspamspam_OUTmitvma.mit.edu

> 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-requestSTOPspamEraseMEmitvma.mit.edu

Just wondering: why am I so many people's uncle? Bob Ammerman RAm Systems ----- Original Message ----- From: "Russell McMahon" <KILLspamapptechspamBeGonePARADISE.NET.NZ> To: <EraseMEPICLISTEraseMEMITVMA.MIT.EDU> Sent: Wednesday, November 27, 2002 6:07 AM Subject: Re: [PIC]: Clock accuracy {Quote hidden}> > 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 > @spam@piclist-unsubscribe-request@spam@spam_OUTmitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestKILLspammitvma.mit.edu

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}

On 11/27/02 7:49 AM, "Bob Ammerman" <.....rammermanspam_OUTADELPHIA.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.....TakeThisOuTmitvma.mit.edu

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-requestKILLspamspammitvma.mit.edu

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-requestRemoveMEmitvma.mit.edu

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" RemoveMEspeffspamBeGoneinterlog.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

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-requestspammitvma.mit.edu

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" speffEraseMEinterlog.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-requestEraseMEspam_OUTmitvma.mit.edu

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-requestRemoveMEEraseMEmitvma.mit.edu

> 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

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

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}

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

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}

> 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

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

> 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

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

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

> 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

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

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 -

> 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

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 <spamBeGonePICLISTEraseMEmitvma.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}

> 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

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