[time-nuts] GPSDO control loops and correcting quantizationerror

[Magnus Danielson]

On 09/16/2012 11:47 PM, Poul-Henning Kamp wrote:
> 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.

EAL is a paper scale and not a locked loop thing. You get different 
properties as well as different abilities.

>> A strict FLL would have the differentiated [...]
>
> Uhm, sorry, that sounds like rubbish to me.

I think you misunderstood my wording in that case.

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

The FLL uses a frequency detector rather than a phase detector, if you 
have a phase detector response you can get your frequency error by 
differentiation. Does that make you disagree wildly?

> 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.

Strange, as I have seen many FLLs having properties like this in both 
books and papers.

It is not uncommon in GPS receivers to both produce a Phase and a 
frequency detection, and then use a combined FLL/PLL topology with PI 
properties for tracking, and then let software trim the various gains.

Chapter 5.3, 5.4 and 5.5 of Elliott Kaplan "Understanding GPS principles 
and applications" (second edition, I can look up the chapters for first 
edition if needed) illustrates what I mean.

You can naturally do FLLs in first-degree (proportional scaling), second 
degree (PI or smoothing filter) or higher.

> 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.

Many users of the (in)famous 4046 has been using both since its 
inception, and the concept was not new at the time. Not saying it is 
anywhere close to optimum performance, but PLL and FLL in analogue 
hardware have been done with slide-ruler level of design.

> 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.
>

There are many ways to steer things. BIPM does EAL and then TAI for many 
reasons, among other that many clocks is just stable but not very 
accurate. Only a handful of clocks contribute to the phase of TAI, but 
around 350 contribute to the stability of EAL.

Cheers,
Magnus