'Crystal Error [OT]'
While working on a 16f84 lcd clock project, I have been encountering timing
errors of up to 32 seconds per day. I thought my interrupt routine was
faulty, but after recalculating the timing, concluded it was not. As a last
resort, I measured the crystal frequency with a hand held Ramsey CT-2000.
It reported 4.00157MHz, an error of 0.04%, or 34 seconds/day. The reported
frequency would closly match my real-world results of ~32 seconds gained
per day, but the CT-2000 is uncalibrated, so the error indicated could be
coincidence. Another crystal measured out at half the error, and yet
another at a slightly higher error than the first.
This is a solderless-breadboarded experiment with no caps on the crystal,
run at room temp. Are these figures within the expected norms, or is my
circuit configuration causing the crystal to oscillate off-freq? 32
seconds/day is obviously unacceptable.
> This is a solderless-breadboarded experiment with no caps on the crystal,
> run at room temp. Are these figures within the expected norms, or is my
> circuit configuration causing the crystal to oscillate off-freq? 32
> seconds/day is obviously unacceptable.
The Xtals will (should) oscillate at their nominal frequency as long as they
are terminated as per their specs. Different Xtals are cut for different
You are lucky that they oscillate at all without loading caps. The caps are
To find the correct value, you can work backwards by listening to the Xtal
on a good coms reciever and adjust the caps to give the nominal frequency.
Then measure the caps.
Well, that did it - I had no idea it would make that much difference. I
have been under the impression that the caps were primarily for startup
purposes, but I see now that's not the entire story. FWIW, 33pF brought it
to 3.999987MHz according to the counter or -102 seconds/year. That's
workable, and it adds to my confidence that the Ramsey counter is at least
close to being right-on.
At 09:58 AM 1/16/00 +1100, you wrote:
You also might consider allowing the software to trim the timing. Most
clock code AFAIK has the ability to discard or add time at periodic
intervals, to make up for the speed of the xtal being off. You could even
make a self-calibrating clock which would look at the time difference when
you re-set it. If the time difference was less than, say, a half-hour, it
would assume that you were not setting it for the first time, but were just
re-setting to correct for accumulated error. Then, by keeping track of how
much time it looses or gains between settings, it could trim its timing.
At 04:47 PM 1/15/00 -0700, you wrote:
>Well, that did it - I had no idea it would make that much difference. I
>have been under the impression that the caps were primarily for startup
>purposes, but I see now that's not the entire story. FWIW, 33pF brought it
>to 3.999987MHz according to the counter or -102 seconds/year. That's
>workable, and it adds to my confidence that the Ramsey counter is at least
>close to being right-on.
| Sean Breheny
| Amateur Radio Callsign: KA3YXM
| Electrical Engineering Student
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
cornell.edu ICQ #: 3329174 shb7
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
More... (looser matching)
- Last day of these posts
- In 2000
, 2001 only
- New search...