[time-nuts] GPSDO control loops and correcting quantizationerror

Poul-Henning Kamp phk at phk.freebsd.dk
Sun Sep 16 21:47:23 UTC 2012


In message <505642F5.1000101 at rubidium.dyndns.org>, Magnus Danielson writes:
>On 09/16/2012 10:30 PM, Poul-Henning Kamp wrote:

>A good PI-based PLL actually combines the FLL and PLL domains [...]

But it is the phase correction that doubles the (absolute) magnitude
of the frequency noise, by "overcompensating" frequency errors in
order to catch up with the integrated phase error they have caused.

Optimal frequency stability will always be at the expense of 
phase offset.

I belive this is the main rationale behind the EAL timescale.

>A strict FLL would have the differentiated [...]

Uhm, sorry, that sounds like rubbish to me.

A FLL corrects by the average of the change of phase per unit of
time, and that's that:

If your phase changes by one microsecond in 1000 seconds, you tweak
the frequency 1e-9 in the appropriate direction.

There is no (D)ifferential and no (P)roportional term in a FLL,
only the (I)ntegral term used to calculate that average.

With all that said, when you are doing things in software, you *can*
have both:  Steer the local osc by FLL to get optimal frequency
(and thus hold-over), and estimate and compensate for the phase
error in software.

I tried that with a PRS10:  I disabled it's internal PLL and instead
used the serial port to apply FLL corrections, and let software
deal with the random-walk phase offset.

In theory that should have roughly doubled the hold-over performance
but in practice I could not get a statistical significance due
to more significant effects such as drift.

A second order FLL might be able to solve that, but the swing-in
of that was far longer than the relevant "tune in" spec.

And that is essentially what timing.com's algorithm for clock
discipline does for Cs's:  Steer the individual Cs' to optimal
frequency and keep track of the phase error by other means.

-- 
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_lists.febo.com mailing list