[time-nuts] GPSDO TC

Poul-Henning Kamp phk at phk.freebsd.dk
Thu Jan 8 18:26:48 EST 2009

>> So what is optimum... from control theory we learn, that with an even
>> better model of your system, you can push performance to the edge! But
>> you always loose robustness in doing that. 

One thing to remember: control theory is akin to a taxinomy which
has only "elephants" and "non elephants", in that sense that
non-linear control theory is not widely taught and generally
considered an evil to stay away from at all cost.

Traditional PLL methods are inherently linear and consequently
limited in what they can do, but you can achive suprisingly good
results by combining a classical PLL with non-linear higher modes
or mode switches.

You can of course, in the absense of solid theory for what you
are attempting, also get it horribly wrong, as in the NTP PLL :-)

But the machine-control and robotics community has finally realized
that to get machines to "have the moves" they have to abandon
classical control theory, drop the poles and zeros of the plane
and instead build physical predictive models.  The first area
to pick up on this big time were disk drive arm actuators, which
are nowhere near a simple differential equation any more.

And timekeeping lends itself well to experiment with this,
not the least because getting it wrong doesn't smash anything
valuable :-)

For instance, one thing to think about in the context of GPSDO's
is that in addition to the PPS signal, we also have all the
other information.

For intance it would make sense to loosen the PLL a bit when
satellites enter and leave the solution, because that often moves
the GPS signal a few nanoseconds abrubtly, which is enough to
throw most PLLs into thinking you had a phase jump.

There is also the complex 12h signal in most GPS receivers PPS,
should that be notched out of the PLL so that it will not react
to offsets that have a 12h period ?  (obviously only in stationary

So many things to try, so little time...


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.

More information about the time-nuts mailing list