[time-nuts] GPSDO time constant

[Poul-Henning Kamp]

In message <4965DECE.3060004 at xtra.co.nz>, Bruce Griffiths writes:
>Hej Magnus
>
>Magnus Danielson wrote:
>
>How exactly can one measure the resultant performance or even select the
>optimum time constant and damping factor if one doesn't have a quieter
>reference?
>Can one really resort to some sort of N cornered hat?

I experimented with that, and you can actually get pretty far with
simpler standalone means such as periodograms of zero crossings.

My theory behind this is that the noise (of all kinds) is basically
gaussian or other symmetric distributions.

Consequently, the offset between your oscillator and the reference
should also have a symmetric distribution of sign, subject to well
known random "paradoxes" like the fact that repeatedly rolling 6
with dice doesn't prove you cheat, you might just be very very
lucky.

I have not fully developed this lead, and would welcome others
to experiement and improve on it, it takes more patience and
stability than my lap can muster when it must also work for my
salary.

The way I autotune the timeconstant of the PLL in NTPns is based
on this lack of zero-crossings of the offset from the reference input:

The first sign that a PLL has been torqued to hard is that the
reference input is not able to steer the oscillator adequately and
you can detect this very early, by monitoring how long runs you have
where the offset from the reference stays the same sign: the runs
on one side will get longer and more frequent than on the other
side.

You can also tell that the timeconstant is too short, because
the runs are not long enough, indicating that the PLL follows
the reference signal more aggresively than it need.

Look in the main/pllmath.c file of NTPns to see my current
implementation. (http://phk.freebsd.dk/phkrel/).

One of my NTP servers use the same GPS PPS to steer the PRS10 Rb
and for the NTP data feed, so the NTPns should obviously end up
with a zero frequency error, since the PRS10 takes care of that.

Consequently the PLL keeps stretching the timeconstant of the
software PLL, until it had identified a 2e-18 rounding error
in the frequency estimation code in the kernel.

The third order code on the other hand, does not seem to do me
much good yet, but maybe I simply don't have good enough kit for
that to be dominant.

The experiements I would propose requires that you can get hold
of the reference/oscillator difference signal somehow, and
then what you want to do is simply record runs of these values
for various timeconstants and damping factors.

The run them through a statistical package, or possibly even
the DIEHARD tests, and see how different timeconstants score,
the ones where the offset looks most random are optimal.

Have fun :-)

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.