Forums

Variations on XTAL clock frequency

Started by Unknown February 19, 2005
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