LP oscillator losing time

[Jim McBride]

I seem to be losing about 12 seconds per day using a 32768 xtal with
the recommended caps for timer one. I would expect and accuracy of
around 20ppm or better which would be less than 2 secs per day. Any suggestions?

[SherpaDoug]

Look at the drive power. Make sure you are not overdriving the crystal. See if the crystal manufacturer has a recommended circuit.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[PCM programmer]

This AppNote on Dallas Semi's Real Time Clock chips
has some tips on the reasons why RTCs run fast or slow.
http://pdfserv.maxim-ic.com/en/an/app58.pdf

[Guest]

Crystals have a certain degree of inaccuacy and they can drift. I assume you mean that it loses 12 seconds every day.

Check the manufacturer's frequency/temperature curve. What's the temp the crystal sees in service. The function is not linear. Check it out and you may be surprised how far the frequency is off at only 10 F - 15 F away from the roll-over temp.

Do other crystals or production units units drift the same?

The overdriving hint was good. This can often be the cause. The 32KHz don't like being pushed around.

Check out the Dallas TCXO. The specs are incredible. Consider changing to it if cost is little factor (laboratory or industrial instruments.) I consulted for a company that uses these in a widget that needs accurate time and all production units checked out at less than +-0.000 seconds per day. (Yes, less than a millisecond per day. Yes, I know what I'm talking about. They used a high-end HP counter and a GPS-sourced clock tick to record drift over 24 hours to screen units.) The units are video/audio program controllers for automated broadcast studios.

[Guest]

I know this is evil of me. I admit it. But if a batch of crystals all lost about 12 seconds of time in a circuit, and were to be used at room temperature, you might consider adding a millisecond every few seconds to tweak it back to 0 ppm error. Depends on the application, time, use, customer, if engineering manager has pointy hair, etc.

[Mark]

Maybe the crystal is just fine and the problem resides in software. Long interrupt routines or disabling them for a long period could cause problems. Maybe try testing with a very simple problem that does nothing more than generate the clock.

[rnielsen]

I hope I'm correct in saying this but, if you are using one of the timers, that uses an 8 bit register, it will count to 255 and then roll over. If you used the number 255 in your timing calculation you will lose one count each roll over because it takes 256 counts to roll over and cause an interrupt. This might be the culprit of your lost seconds.

Ronald

[ljbeng]

Jim McBride,

I recently tried this and saw the exact same results. What did you do to correct this? I tried software fixed but I still saw significant drift. Thanks.

[dyeatman]

Without seeing your code we cant really do anything but guess how you are keeping time. Are you using interrupts, delays or just loop counters?

I used interrupts and had some drift but it was consistantly the same amount. I then adjusted the interrupt code, similar to what was mentioned above, and fixed the problem.

To actually make the adjustments I first set up a 10ms timer interrupt for my main RTC timing. In the interrupt I toggled a single output pin which I monitored with a scope. I then adjusted my code until the scope showed exactly 10ms time intervals. I then had a drift of less than 1 second per day. This might work for you.

The longer the interval you can monitor and adjust with the scope (100ms, 500ms or 1000ms for example) the more accurate your result will be. To verify mine I also set up a one second output pin and monitored that with the scope.

BTW, when I was done I simply put NOPs in for the same number of machine cycles the pin toggle statement required (from the listing) to maintain my accuracy.

[ljbeng]

[Mark]

Is the PIC running at 32.768KHz?

Take a look at this

[ljbeng]

I have a 32768 on pins 12,13 running timer1 and I am using the 4.0 MHz internal oscillator for the main program. All the code in the timer1 interrupt routine should be executed at 1MHz speed which is 30x faster than timer1 can increment from the 32768 crystal. Or am I wrong on this? It seems to me, when the first line in the timer1 ISR is executed, the 32768 crystal should not be able to increment timer1 for another 30 instructions.

[Mark]

Did ya try my code example????????????

@4MHz each instruction takes 1us. At 32KHz timer1 will increment at about 30us. Depending on you other interrupts it takes time to process the interrupts. This is probably less than 30us. The interrupt fires and grabs the timer1 value. Now there is about 17 instructions to add 0x8000 to the "stored" timer value. During this time, I suspect that the timer value is incremented. However, the add routine doesn't get this increment so it actually loses 1 tick or 30us. Over a day, that will be about 2.6 seconds. I'd try my suggestion. Clearly you should be able to see how much more efficient it is!

[Guest]

[Mark]

I just did a test where I sped up the timer1 int by a factor of 128. This introduced the error at 128 times the normal rate. From my calculations, you should lose about 33ms over a 20 minute period. 128 times this is about 4.68 seconds. I ran a test over a 20 minute period and lost about 5 seconds. I then tried the example that I posted. After running 1 hr, there is still no loss of time as verified by my daughter's office Shrek clock from Burger King!