On 09/16/2012 11:47 PM, Poul-Henning Kamp wrote:
In message<505642f5.1000...@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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
