Variations on XTAL clock frequency

On Sat, 19 Feb 2005 18:38:17 -0000, dplatt@radagast.org (Dave Platt)
wrote:

>The PPS pulses are infrequent enough, and subject to enough jitter,
>that the drivers will need to do a fairly significant amount of
>low-pass filtering before using the pulse information to calibrate the
>internal clock.

Not true.  You can buy a GPS receiver that produces 1 PPS with hardly
any jitter at all.  By using a PLL, a high-quality frequency standard
can and has been made.  You don't need a lot of low-pass filtering in
that PLL.



-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

>>The PPS pulses are infrequent enough, and subject to enough jitter,
>>that the drivers will need to do a fairly significant amount of
>>low-pass filtering before using the pulse information to calibrate the
>>internal clock.
>
>Not true.  You can buy a GPS receiver that produces 1 PPS with hardly
>any jitter at all.  By using a PLL, a high-quality frequency standard
>can and has been made.  You don't need a lot of low-pass filtering in
>that PLL.

Well, from what I've heard and read... it depends.

For one thing, different GPS receivers have different amounts of
jitter in their PPS pulses.  Some (e.g. the Oncore series) are quite
good, while others have a larger amount of variation in timing.  This
seems to be due to software/firmware design in the GPS receivers'
controllers.  In his discussion on GPS-disciplined oscillators at the
site I mentioned, Brooks Shera notes that many GPS receivers' PPS
pulses are too jittery to use as a source for PLL-disciplining a good
oscillator.

For another thing... most PCs don't have special-purpose PLL or other
capture hardware to "catch" the exact timing of the PPS signal.
Simple approaches usually seem to involve hooking up the PPS line to a
parallel-port pin, to a serial-port CD pin, etc. and generating an
interrupt.  The interrupt service routine then captures the
processor's high-resolution clock value.  With most operating systems,
there can be a large amount of jitter in the time needed to enter the
ISR, depending on what other interrupt or kernel activity is taking
place.  If your PC is down deep in the network card's interrupt
service routine and is handling heavy amounts of packet traffic, it
could require many microseconds, or in some cases a millisecond or
more, to enter the serial/parallel port ISR and sample the CPU clock.
This source of jitter is likely to be much greater than the jitter in
the GPS PPS pulse itself.

Since the original poster asked about the timing error "between PPS
pulses" and didn't mention the use of special-purpose low-jitter
capture hardware, my guess is that this CPU/OS-induced jitter may very
well be relevant to the problem.

-- 
Dave Platt <dplatt@radagast.org>                                   AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
  I do _not_ wish to receive unsolicited commercial email, and I will
     boycott any company which has the gall to send me such ads!

On Sat, 19 Feb 2005 20:09:32 -0000, dplatt@radagast.org (Dave Platt)
wrote:

>>>The PPS pulses are infrequent enough, and subject to enough jitter,
>>>that the drivers will need to do a fairly significant amount of
>>>low-pass filtering before using the pulse information to calibrate the
>>>internal clock.
>>
>>Not true.  You can buy a GPS receiver that produces 1 PPS with hardly
>>any jitter at all.  By using a PLL, a high-quality frequency standard
>>can and has been made.  You don't need a lot of low-pass filtering in
>>that PLL.
>
>Well, from what I've heard and read... it depends.
>
>For one thing, different GPS receivers have different amounts of
>jitter in their PPS pulses...

I agree.  I tried to make a high-quality frequency standard using a
Sandpiper GPS receiver.  The 1-PPS output was very low jitter on one
edge but very high jitter on the opposite edge.  Probably a flip-flop
was being reset by software.  I started out using the wrong edge and
couldn't understand why my loop was so unstable.  When I switched to
the other edge, then everything worked out fine.  This was
special-purpose hardware, not just a digital input pin on a PC, so I
agree also that unless you have special-purpose hardware, you really
can't do much with that low-jitter pulse.


-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

<Sunwaesh> wrote in message 
news:4217214a$0$1998$afc38c87@news.optusnet.com.au...
> Jerry G.,
>
> Thank you for your valuable  answer.
> In a project I need to have time synchronization between a set of 
> computers where some of them are networked together on a LAN (no internet) 
> and some others are running stand alone. I am planning to use the 
> one-pulse-per-second (1PPS) signal from the GPS receivers. The networked 
> computers will have one GPS receiver and all the other stand alone 
> computers will have their own GPS receivers. GPS receivers will generate 
> 1PPS signals to interrupt the computers to set their internal time clocks. 
> Applications will use the computer timer (get the time of the day). I want 
> to model (some how, but I do not know how) the probable variation that a 
> computer clock may have between 1PPS signals.
>
> Would anyone comment/argue/recommend/suggest/propose how one can model the 
> variation on a PC clock frequency ?

The Answer is that without knowing a whole lot of Factors (temperature of 
the crystal oscillator, specs of the oscillator etc) it is not easy to model 
or estimate the accuracy of a PC's internal clock beyond 'adequate for most 
scenarios' If accuracy is required a better clock is required.

The Clock source from the GPS (if properly locked and implemented by the GPS 
manufacturer) should be close to a Cesium clock in terms of accuracy and 
will be several orders of Magnitude ( around 1 part in 1*10^12) better than 
the clock from the PC which will be around 100 Parts per million if the 
Temperature is kept constant at around 25c

A few links FYI
http://www.beaglesoft.com/stsystarcardspecs.htm#StarSync
http://www.gpsclock.com
http://www.aelcrystals.co.uk/ 

mc wrote:

> > surprised if the clocking frequency in a home PC machine is
drifting about
> > 1% to 2%. As long as everything keeps properly synchronized there
will be
>
> That would be a gigantic drift for even a very cheap crystal.  I
think
> 1/10,000 is more typical of what would be a large drift from a
low-quality
> crystal.

The battery-powered RTC clock is frequently VERY inaccurate, though.
For reasons I've never had explained to me, they almost always have a
trimcap on that xtal. Their Q/C processes to set that trimcap appear to
be FUBAR.

larwe@larwe.com wrote:
> mc wrote:
> 
>>> surprised if the clocking frequency in a home PC machine is
>>> drifting about 1% to 2%. As long as everything keeps properly
>>> synchronized there will be 
>> 
>> That would be a gigantic drift for even a very cheap crystal.  I
>> think 1/10,000 is more typical of what would be a large drift from a
>> low-quality crystal.
> 
> The battery-powered RTC clock is frequently VERY inaccurate, though.
> For reasons I've never had explained to me, they almost always have a
> trimcap on that xtal. Their Q/C processes to set that trimcap appear
> to be FUBAR.

What trimcap? I've never seen one in a PC RTC circuit and, golly, does
it need it!


-- 
Graham W   http://www.gcw.org.uk/ PGM-FI page updated, Graphics Tutorial
WIMBORNE   http://www.wessex-astro-society.freeserve.co.uk/ Wessex
Dorset UK  Astro Society's Web pages, Info, Meeting Dates, Sites & Maps
Change 'news' to 'sewn' in my Reply address to avoid my spam filter.

> > The battery-powered RTC clock is frequently VERY inaccurate,
though.
> > For reasons I've never had explained to me, they almost always have
a
> > trimcap on that xtal. Their Q/C processes to set that trimcap
appear
>
> What trimcap? I've never seen one in a PC RTC circuit and, golly,
does
> it need it!

Maybe your motherboard collection differs from mine. But every board
I've owned (except some of the laptops) has had a trimcap.

Mystery why they bother to put such fine-tuning on there, since it is
very common to get as much as 10 seconds drift per day!

<larwe@larwe.com> wrote in message 
news:1109016257.420847.117250@f14g2000cwb.googlegroups.com...
>
>> > The battery-powered RTC clock is frequently VERY inaccurate,
> though.
>> > For reasons I've never had explained to me, they almost always have
> a
>> > trimcap on that xtal. Their Q/C processes to set that trimcap
> appear
>>
>> What trimcap? I've never seen one in a PC RTC circuit and, golly,
> does
>> it need it!
>
> Maybe your motherboard collection differs from mine. But every board
> I've owned (except some of the laptops) has had a trimcap.
>
> Mystery why they bother to put such fine-tuning on there, since it is
> very common to get as much as 10 seconds drift per day!

I would not have expected an un-trimmed Crystal to drift more than 100 Parts 
per Million or 86.4 mS per day, the Laptop I am using at the moment is still 
within a Second of the Talking clock and I set it 3-4 Months ago.
I am sure I would have noticed if Clocks on any PC's I used were losing or 
gaining 10 Seconds a day 

Richard Freeman wrote:

> <larwe@larwe.com> wrote in message 
> news:1109016257.420847.117250@f14g2000cwb.googlegroups.com...
> 
>>>>The battery-powered RTC clock is frequently VERY inaccurate,
>>
>>though.
>>
>>>>For reasons I've never had explained to me, they almost always have
>>
>>a
>>
>>>>trimcap on that xtal. Their Q/C processes to set that trimcap
>>
>>appear
>>
>>>What trimcap? I've never seen one in a PC RTC circuit and, golly,
>>
>>does
>>
>>>it need it!
>>
>>Maybe your motherboard collection differs from mine. But every board
>>I've owned (except some of the laptops) has had a trimcap.
>>
>>Mystery why they bother to put such fine-tuning on there, since it is
>>very common to get as much as 10 seconds drift per day!
> 
> 
> I would not have expected an un-trimmed Crystal to drift more than 100 Parts 
> per Million or 86.4 mS per day, the Laptop I am using at the moment is still 
> within a Second of the Talking clock and I set it 3-4 Months ago.
> I am sure I would have noticed if Clocks on any PC's I used were losing or 
> gaining 10 Seconds a day 

You're fortunate...
I've only had one laptop out of 4 that didn't drift in time too much.
My current one loses about 4 seconds per day., my previous one
gained about 2 seconds per day.
The PC battery-backed-up clock system was 'adequate' when it was
created back in the mid 1980's, but unfortunately that part of
the PC architecture hasn't changed much since then.

"Richard Freeman"
>
> I would not have expected an un-trimmed Crystal to drift more than 100 
> Parts per Million or 86.4 mS per day,


**  100 ppm  =  1 part in 10,000.

A day has 24 x 60 x 60 seconds or  86,400 seconds.

 So a 100 pm error is 8.64 seconds !!!

 You are only 1000 times out.


>the Laptop I am using at the moment is still within a Second of the Talking 
>clock and I set it 3-4 Months ago.


**  Sure -  drift is nearly all due the tempco of the crystal.

If the AVERAGE temp value is steady from day to day then there is virtually 
no DRIFT.

There may well be fixed setting error though.


> I am sure I would have noticed if Clocks on any PC's I used were losing or 
> gaining 10 Seconds a day


**  The tempco drift is only a few ppm  *per degree C* for most crystals, 
over the range from 10 to 35 C.

 The indoor temp averaged over a month varies only a few degrees compared 
with the previous or next month.

So, the month to month variation should be maybe  +/- 10ppm or  0.86 
seconds.

Seems about right to me.



...............   Phil