[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