Re: [time-nuts] GPSDO control loops and correcting quantization error
On 9/16/12 10:20 AM, Magnus Danielson wrote:
On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote:
Dave Mills coined the term "allan intercept" as the cross over of
the two sources allan variances and it's a good google search for
his relevant papers.
I'm not entirely sure his rule of thumb for regulating to that point
is mathematically sound& precise, but the concept itself is certainly
valid, even if you have to compensate for the timeconstant of the
PLL you use to regulate to that point.
Well, what is being used is phase-noise intercept. Conceptually a
similar intercept point will be available in Allan variance. However, as
you shift between noise-variants, the Allan (and Modified Allan)
variance has different scaling factor to the underlying phase noise
amplitudes. The danger of using the Allan variance variant is that you
get a bias in position compared to the phase-noise plots cross-overs.
However, the concept is essentially the same, and the relative slopes is
the same. You get in the right neighbourhood thought.
The concept has been in use in the phasenoise world of things, so you
would need to search the phase-noise articles to find the real source.
It's been used to generate stable high-frequency signals.
The analysis of PLL based splicing of ADEV curves is tricky, and I have
not seen any good comprehensive analysis even if the general concept is
roughly understood. The equivalent on phase-noise is however well
understood and leaves no magic too it.
I'm not sure that the theory of phase noise intercepts, in practical
systems, is actually used. It seems that everyone I've talked to uses
the theory to "get in the ballpark" and then does simulations at the
design review, and ultimately, builds it and tests, and then tweaks the
implementation to optimize (especially if the loop closure is
implemented digitally in software/FPGA)
When talking real high performance, there's so many confounding error
factors that it's not like you can build what theory says and hit the
mark. The actual noise distributions follow the Leeson model in
general, but have lumps and bumps, and there's always narrow band
oddities (power supply filtering, noise from switching power converters,
etc.)
Let's face it, real high performance source design has a lot of art and
craft in it. You can't get to that point without sound engineering, but
that last order of magnitude is all about suck it and see.
I spent a lot of time with the code in NTPns, to try to get that PLL
to converge on the optimum, and while generally good, it's not perfect.
The basic problem is that the data you have available for autotuning,
is the allan variance between your input and your steered source.
It's a complex field, and things like temperature dependencies helps to
confuse you.
Ain't that the truth..
And then, there's proving that what you built is actually doing what you
claim. State of the art sources require beyond state of the art
verification methods...
It's easy to write a spec for, say, incremental Allan Dev of 1E-16 at
some tau. A bit harder to test at a constant frequency. Now throw in a
varying frequency (say, because of temperature variation or Doppler)..
In message 34D5C3CE-6B3D-4944-996A-7637373B2857@gmail.com, Dennis Ferguson wr
ites:
I'm not sure there could be a difference between the goals of
frequency accuracy and time accuracy that would effect that time
constant.
It does.
A PLL more or less corresponds to an "PI" regulation, where a FLL
only needs to have the "I" term.
Because you don't have the interaction between the P and I terms,
the I-timeconstant can be longer.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
On 09/16/2012 10:28 PM, Jim Lux wrote:
On 9/16/12 10:20 AM, Magnus Danielson wrote:
On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote:
Dave Mills coined the term "allan intercept" as the cross over of
the two sources allan variances and it's a good google search for
his relevant papers.
I'm not entirely sure his rule of thumb for regulating to that point
is mathematically sound& precise, but the concept itself is certainly
valid, even if you have to compensate for the timeconstant of the
PLL you use to regulate to that point.
Well, what is being used is phase-noise intercept. Conceptually a
similar intercept point will be available in Allan variance. However, as
you shift between noise-variants, the Allan (and Modified Allan)
variance has different scaling factor to the underlying phase noise
amplitudes. The danger of using the Allan variance variant is that you
get a bias in position compared to the phase-noise plots cross-overs.
However, the concept is essentially the same, and the relative slopes is
the same. You get in the right neighbourhood thought.
The concept has been in use in the phasenoise world of things, so you
would need to search the phase-noise articles to find the real source.
It's been used to generate stable high-frequency signals.
The analysis of PLL based splicing of ADEV curves is tricky, and I have
not seen any good comprehensive analysis even if the general concept is
roughly understood. The equivalent on phase-noise is however well
understood and leaves no magic too it.
I'm not sure that the theory of phase noise intercepts, in practical
systems, is actually used. It seems that everyone I've talked to uses
the theory to "get in the ballpark" and then does simulations at the
design review, and ultimately, builds it and tests, and then tweaks the
implementation to optimize (especially if the loop closure is
implemented digitally in software/FPGA)
When talking real high performance, there's so many confounding error
factors that it's not like you can build what theory says and hit the
mark. The actual noise distributions follow the Leeson model in
general, but have lumps and bumps, and there's always narrow band
oddities (power supply filtering, noise from switching power converters,
etc.)
Let's face it, real high performance source design has a lot of art and
craft in it. You can't get to that point without sound engineering, but
that last order of magnitude is all about suck it and see.
I agree, but my point was that "Allan intercept" might be an attempt for
the "phase-noise intercept" which is better understood. Then again, as
always there are other things to consider.
Looking single-mindedly on Allan deviation or phase-noise plots will
make you loose other details, like systematic features and their
tracking, the systematic errors of the loop, the hold-over properties of
the loop and track-in properties etc. etc.
I am also amazed when comparing the resolution to ADEV noise. They have
different properties when you changes tau, and also if you want to make
it work very well, lowering added noise should be important, no? Only in
economic "balanced" designs would roughly equal noises be used.
I spent a lot of time with the code in NTPns, to try to get that PLL
to converge on the optimum, and while generally good, it's not perfect.
The basic problem is that the data you have available for autotuning,
is the allan variance between your input and your steered source.
It's a complex field, and things like temperature dependencies helps to
confuse you.
Ain't that the truth..
And then, there's proving that what you built is actually doing what you
claim. State of the art sources require beyond state of the art
verification methods...
True that.
It's easy to write a spec for, say, incremental Allan Dev of 1E-16 at
some tau. A bit harder to test at a constant frequency. Now throw in a
varying frequency (say, because of temperature variation or Doppler)..
... or varying phase...
It seems like much effort goes into the noise aspect, but not enough on
the systematics... and how those interact for varying degrees of tau.
Cheers,
Magnus
On 09/16/2012 10:30 PM, Poul-Henning Kamp wrote:
In message34D5C3CE-6B3D-4944-996A-7637373B2857@gmail.com, Dennis Ferguson wr
ites:
I'm not sure there could be a difference between the goals of
frequency accuracy and time accuracy that would effect that time
constant.
It does.
A PLL more or less corresponds to an "PI" regulation, where a FLL
only needs to have the "I" term.
Because you don't have the interaction between the P and I terms,
the I-timeconstant can be longer.
The balance between P and I is important to establish the damping of
your PI regulator.
A good PI-based PLL actually combines the FLL and PLL domains by
differentiating the phase detector and feeding that through a scaling
into the integrator, adding to the phase-detector scaled by the I
factor. That way you can get very good pull-in properties which then
gently goes over to PLL properties. When PLL lock is achieved the FLL
scale-factor can be removed, as it only contributes noise.
A strict FLL would have the differentiated phase scaled and added into
the frequency steering, after the PI-regulators integrator. This D term
would set the frequency right, but the integrator would not learn the
frequency as quick and there would be tracking errors until it learns.
This differentiated phase aided integrator solves the bad pull-in
behaviour for the case when the reference signal and the oscillators
signal is far apart.
Cheers,
Magnus
On 16 Sep, 2012, at 16:30 , Poul-Henning Kamp wrote:
In message 34D5C3CE-6B3D-4944-996A-7637373B2857@gmail.com, Dennis Ferguson wr
ites:
I'm not sure there could be a difference between the goals of
frequency accuracy and time accuracy that would effect that time
constant.
Note that the "that time constant" referred to here, the topic of
the message I was responding to, was explicitly a PLL time constant.
If you have decided to use a PLL as your control discipline I think
you end up with the same time constant whether your goal is accurate
frequency or accurate time since, with a PLL, these end up being
the same problem.
It does.
A PLL more or less corresponds to an "PI" regulation, where a FLL
only needs to have the "I" term.
Because you don't have the interaction between the P and I terms,
the I-timeconstant can be longer.
This sounds right. As I said, if you pick a control discipline other
than a PLL, as might be advantageous to do if your concern is solely
with accurate frequency, then the optimum might be different. If you
are using a PLL in both cases, however, then the problems are
essentially the same.
Dennis Ferguson
In message 505642F5.1000101@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@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.
In message AD054298-F656-477F-9FB1-5D48C1B07C31@gmail.com, Dennis Ferguson wr
ites:
If you
are using a PLL in both cases, however, then the problems are
essentially the same.
Well, not quite: Depending on the stiffness of your PLL, you can
minimize phase error at the cost of frequency error or frequency
error at the cost of phase error, and either is a valid engineering
decision depending which of the two are more important to you.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
HI
In some cases, the difference can be your definition of "time accuracy". If short term GPS time is what you are worried about, then indeed that's a different beast than a 30 day plot against your direct line to USNO.
Bob
On Sep 16, 2012, at 4:12 PM, Dennis Ferguson dennis.c.ferguson@gmail.com wrote:
On 16 Sep, 2012, at 00:40 , Tom Van Baak wrote:
I worry in your example about the long cross-over time. This may be ideal for frequency stability, but probably is not good for time accuracy. If one is using the GPSDO as a timing reference, I would think a shorter time constant will keep the rms time error down. Has anyone on the list done work optimizing the timing accuracy rather than the frequency stability?
I'm not sure there could be a difference between the goals of
frequency accuracy and time accuracy that would effect that time
constant. The time error is the time integral of the frequency
error, so anything which manages to minimize the frequency error
of the oscillator (both the magnitude of the error and its
duration) will also minimize the time error. The time constant
is selected to be the minimum value which makes it probable that
the frequency or time error you have measured (for a PLL the data
are time errors) is in fact an error that the oscillator has
made rather than an artifact of the noise in the measurement
system.
There might be a difference in the best control action to take to
optimally achieve each of those goals. In particular if your goal
is frequency accuracy the best control action in response to the
measurement of a frequency error might be to correct that error,
i.e. to minimize the frequency error once you know you have one.
If your goal is time accuracy, however, then the response to a
measured frequency error is going to be to intentionally make a
frequency error in the other direction for a while to correct the
accumulated time error. In this case, though, it seems to me
that by selecting a PLL as the control discipline (rather than, say,
a FLL) you've already made the decision to take control actions
which ensure time accuracy.
Dennis Ferguson
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.
On 09/16/2012 11:47 PM, Poul-Henning Kamp wrote:
In message505642F5.1000101@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
On 09/16/2012 11:51 PM, Poul-Henning Kamp wrote:
In messageAD054298-F656-477F-9FB1-5D48C1B07C31@gmail.com, Dennis Ferguson wr
ites:
If you
are using a PLL in both cases, however, then the problems are
essentially the same.
Well, not quite: Depending on the stiffness of your PLL, you can
minimize phase error at the cost of frequency error or frequency
error at the cost of phase error, and either is a valid engineering
decision depending which of the two are more important to you.
Sometimes such compromises is the only way to go, but sometimes you may
consider to raise your system complexity. One such thing is to increase
the PLL degree. There are many tools in the toolbox.
Another example is the OCXO oven control. A typical OCXO oven tries to
quickly steer back the temperature. During the little temperature trip,
the oscillator will have the wrong frequency, but as the oven settles
again, it will be more or less back where you started. Trouble is, often
you have only gone above or below frequency, so the integral of that
frequency error is a phase-shift. oups. Hope your application wasn't
phase-stability sensitive... I have seen only one vendor address this
issue, complete with graphs showing the phase-creep over several
temperature cycles, and yes... a typical oven shifts phase with a
residual error after a full temperature cycle of ambient temperature,
since the errors doesn't cancel completely.
While this example may not be spot on to the point Poul-Henning is
making, it can be used as a good illustration that frequency stability
goal and phase stability goals isn't necessarily the same.
Going back to the PLL, with a tight PLL, you track in errors quickly.
This looks good as you then track in phase errors and the time error as
it accumulates doesn't become large. On the other hand, when doing this
you need to steer your frequency wider in order to more quickly track in
that phase error. A looser PLL will track in errors more sluggishly, and
hence will use less frequency deviations for track-in, but with the
downside that the frequency errors will remain longer and the time error
will become larger. These are the systematic reactions to phase and
frequency steps and ramps. The degree of the system will also change
these parameters.
It is also important to remember that changes in the reference and
changes within the loop gets low-passed and high-passed (respectively)
by the loop bandwidth. A temperature shift on the locked oscillator will
be a typical in-loop effect which gets high-passed.
Then there is the background noise processes to consider, but we spend
so much time on them already.
Cheers,
Magnsu