[LinuxPPS] DCF77-PPS

Hal V. Engel hvengel at astound.net
Wed Nov 12 21:15:28 CET 2008


On Wednesday 12 November 2008 05:45:51 Remco den Besten wrote:
> > I think that +-1ms is about as much as you can expect from this type of
> > setup.
> > I think that there is some variation in the propagation delay because of
> > variability in the propagation path.  I would think that since DCF77 and
> > WWVB
> > propagate via ground waves that this should give better results than
> > using HF
> > time broadcasts like the 10MHz, 15Mhz or 20Mhz WWVA or WWVH signals since
> > the
> > propagation path will be more consistent.  I read some where that using
> > WWVA
> > or WWVH about the best you could do was around +-20ms.
>
> Correct. Therefore I am happy to have reached the boundaries of precision
> concerning
> this type of reference :-)
>
> > In fact the frequency curves are basically inverted which is something I
> > would
> > not expect.   The other thing that is inverted is the direction of the
> > frequency correction.
>
> I tried to find out what you meant, but what do you mean with
> 'basically inverted' ?

By inverted I mean that if you look at the frequency plots of these two 
machines that the slopes of the plots go in the opposite directions at any 
given point in time.  When one has a positive slop (goes up from left to 
right) the other is negative (goes down from left to right). This indicates 
that the oscillators on these machines have significantly different Theta 
angles for the cut through the crystal.  

See http://www.ieee-uffc.org/freqcontrol/quartz/vig/vigcateg.htm for some 
example plots of freq. vs. temperature for different Theta angles for AT cut 
crystals.  All of them have an inflection point near 25C with a Theta angle of 
0 having the flattest plots near the inflection point.  If you compare the 
plot for a crystal with a Theta angle >0 to one where the Theta angle is <0 
these will have slopes that go in the opposite directions through most of the 
temperatures that you would expect to encounter inside a computer (IE. 20C to 
50C).   I think this is what is happening with the two oscillators in your 
machines. 

Since computer/motherboard manufacturers in general are using the cheapest 
oscillators that they can get it is not surprising that these vary 
considerably and that the Theta angle of the individual samples can be 
significantly different.   I suspect that it is sort of a luck thing that some 
machines end up with crystals that have a freq. vs. temp plot that has a low 
slop in the normal operating range of the machine.  But modern machines also 
have higher temperatures under the hood and this pushes the normal operating 
temperature of the oscillator higher where the (absolute) slop of the curve 
will be greater and I suspect in most cases this is now well above the 
inflection point in the freq. vs. temp. curve which likely makes things more 
difficult for ntpd to deal with particularly in cases where the Theta angle  
is father from 0.  

>
> > The oscillator on ntp2.remco.org appears to be the most stable of the
> > lot. Is
> > this because the room temperature is more stable where it is located or
> > is this because this machine happens to have an oscillator that is not as
> > temperature sensitive?  In any case I suspect that this machine will give
> > very
> > good results with the OnCore GPS.
>
> It is an old machine with a 'pit' (as far as I could ascertain it is a
> hardware timer, related to
> the system clock (mostly 14.31818 MHz divided bij 12)) timer. So, indeed I
> am curious
> how this machine behaves with a GPS-locked PPS. The machine is located in
> another location
> by the way. We'll find out (hopefully) this weekend :-)
>
> > The lithium frequency curve is very similar to freebsd.   Are these
> > located in
> > the same room?
>
> Yes, helium, lithium and freebsd are in the same room.
> For the 'FreeBSD machine': with the same hardware, using LinuxPPS, I got
> similar plots like helium. The same hardware,
> using 'FreeBSD-PPS', yields a more stable and smooth result.
>
> Linux apperantly has another PLL-concept than FreeBSD.
>
> I was even thinking of building a machine with Linux 2.4 and the 'old'
> PPSkit to see how it behaves.
>
> Or.. on other words: what to do to not only have the flags 2001 while
> syncing, but 2107, like FreeBSD
> or the PPS-kit?
>
> remco at helium [/home/remco]> ntpdc -c kern
> pll offset:           -1.5981e-06 s
> pll frequency:        18.051 ppm
> maximum error:        0.002751 s
> estimated error:      1e-06 s
> status:               2001  pll nano
> pll time constant:    4
> precision:            1e-09 s
> frequency tolerance:  500 ppm
> remco at helium [/home/remco]> ntpdc -c kern freebsd
> pll offset:           1.568e-07 s
> pll frequency:        -52.625 ppm
> maximum error:        0.00324 s
> estimated error:      2e-06 s
> status:               2107  pll ppsfreq ppstime ppssignal nano
> pll time constant:    4
> precision:            1e-09 s
> frequency tolerance:  496 ppm
> pps frequency:        -52.625 ppm
> pps stability:        0.012 ppm
> pps jitter:           1.356e-06 s
> calibration interval: 256 s
> calibration cycles:   48319
> jitter exceeded:      76374
> stability exceeded:   0
> calibration errors:   318
> remco at helium [/home/remco]>
>

Are things like ppsfreq, ppstime and ppssignal things that need to be 
implemented in glibc like STA_NANO?

Hal



More information about the LinuxPPS mailing list