Re: [time-nuts] GPSDO control loops and correcting quantization error
Hi
By far the most common approach to optimizing these is the "measure it and see" approach.
- measure the noise out of the GPS ( must be done no matter what)
- measurer the noise of the specific OCXO (again must be done)
- guess at a cross over
- try it and measure the result.
- step and repeat 3 and 4 until exhaustion sets in
Indeed converting the data to phase noise rather than ADEV helps the guess process. You can go a bit crazy with math to get a better first guess. Unless you measure what you get, you won't find all the silly little things you forgot to put into your math model.
If you simply try a dynamic tune approach, you never really get to an optimum point. You need a "better than" reference to let you know where you are. You can keep pushing out the time constant and watching with just a GPS and OCXO, but you never really know when to stop.
Bob
On Sep 16, 2012, at 11:47 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message 5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, "Tom Van Baak" writes:
Yes, timing accuracy has been my main focus and in general I have been
using integration times on the low side of 10000 seconds for that,
but it depends a lot on the OCXO/Rb and environment.
The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL
for optimal time stability, and it does a surprisingly good job at it.
Are there papers that talk about how to optimize for best timing or best
frequency or (no free lunch) some compromise combination of the two?
The only writings I am aware of, is what Dave Mills has written and
the PLL code in NTPns, but I havn't followed this closely in the last
10 years, so do check for newer writings.
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.
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.
If you also have the allan variance between the steered source and
a 3rd, better, source, the task is pretty trivial: Minimize the
area below that curve.
But if you do that on the curve you have, you don't optimize, you
pessimize, since the lowest area, is with a timeconstant of zero.
Going the other direction and maximizing the area is no good either
and trying to balance the area around some pivot related to the
present PLL timeconstant does not converge in my experience.
What I did instead was to (badly) reinvent Shewarts ideas for testing
if the phase residual is under "statistical process control":
I increase the timeconstant if the phase residual has too frequent
zero-crossings and loosen it if they happen too seldom.
Having read a lot more about statistical process control, since I
built those NTP servers for the Air Traffic Control 10 years ago,
I would leverage more of the theory and heuristics developed in
process control. (3sigma violations, length of monotonic direction
etc. etc.)
--
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.
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.
In message ACD158CA-D76C-4A8B-B77D-4FA691D0B50B@rtty.us, Bob Camp writes:
The purpose of my examples was to keep things simple and look at
the "running condition" of the loop rather than it's performance
while it settles down.
But what is "running condition" ?
I see my PLL adjust to thermal conditions during summer (A/C) and
winter (heating) and even to GPS constellation changes...
--
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 3A001267-52DE-4EE9-B6EE-6638FB270C06@rtty.us, Bob Camp writes:
Hi
By far the most common approach to optimizing these is the "measure
it and see" approach.
- measure the noise out of the GPS ( must be done no matter what)
- measurer the noise of the specific OCXO (again must be done)
- guess at a cross over
- try it and measure the result.
- step and repeat 3 and 4 until exhaustion sets in
Indeed.
What I've done is to automate that, using the zero-crossing
frequency of the residual as input.
If you simply try a dynamic tune approach, you never really get
to an optimum point.
For the stuff I did, hitting the optimum point exactly from the
beginning, was not nearly as important as getting close to the
optimum point when circumstances changed.
But with that being said: Even in the "ideal scientific" setting,
I think my approach is not only valid, I think it is one of the
most efficient ones, because you don't need a 3rd reference to
measure against.
If you have a 3rd (& better) reference, by all means use it, but
if all you have is a GPSDO, my method delivers better results than
I have seen from anything else.
--
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.
Great dialog, One thing I have seen is the Allan intercept almost always has a "knee". If you wanted the best possible GPS quartz reference developing a variable Allan intercept would allow this knee to be moved and then mathematically removed during a gated measurement.
Allowing to effectively see behind he knee offering lower uncertainty in this important area.
Thomas Knox
Date: Sun, 16 Sep 2012 19:20:24 +0200
From: magnus@rubidium.dyndns.org
To: time-nuts@febo.com
Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote:
In message5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, "Tom Van Baak" writes:
Yes, timing accuracy has been my main focus and in general I have been
using integration times on the low side of 10000 seconds for that,
but it depends a lot on the OCXO/Rb and environment.
The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL
for optimal time stability, and it does a surprisingly good job at it.
Are there papers that talk about how to optimize for best timing or best
frequency or (no free lunch) some compromise combination of the two?
The only writings I am aware of, is what Dave Mills has written and
the PLL code in NTPns, but I havn't followed this closely in the last
10 years, so do check for newer writings.
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 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.
You need to treat the data as loose and tight PLL measure, depending on
what you look for. There is loads of calibration issues, covered in
literature.
If you also have the allan variance between the steered source and
a 3rd, better, source, the task is pretty trivial: Minimize the
area below that curve.
But if you do that on the curve you have, you don't optimize, you
pessimize, since the lowest area, is with a timeconstant of zero.
Going the other direction and maximizing the area is no good either
and trying to balance the area around some pivot related to the
present PLL timeconstant does not converge in my experience.
What I did instead was to (badly) reinvent Shewarts ideas for testing
if the phase residual is under "statistical process control":
I increase the timeconstant if the phase residual has too frequent
zero-crossings and loosen it if they happen too seldom.
Having read a lot more about statistical process control, since I
built those NTP servers for the Air Traffic Control 10 years ago,
I would leverage more of the theory and heuristics developed in
process control. (3sigma violations, length of monotonic direction
etc. etc.)
It's a complex field, and things like temperature dependencies helps to
confuse you.
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.
Hi
The basic assumption is that this is a lab gizmo and that there is indeed a static adev (or very low frequency phase noise) plot for the OCXO (or Rb). The other assumption is that this plot is quite good (say decreasing or flat to >10,000 seconds).
IF that's all true, then the "running condition" is the pll loop frequency / time constant / cross over that does not degrade that adev (or phase noise) plot with noise from the GPS.
Bob
On Sep 16, 2012, at 1:56 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message ACD158CA-D76C-4A8B-B77D-4FA691D0B50B@rtty.us, Bob Camp writes:
The purpose of my examples was to keep things simple and look at
the "running condition" of the loop rather than it's performance
while it settles down.
But what is "running condition" ?
I see my PLL adjust to thermal conditions during summer (A/C) and
winter (heating) and even to GPS constellation changes...
--
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.
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.
Hi
The "knee" is a basic artifact of the cross over in the noise of one (say the OCXO) to the noise of the other (say the GPS). It's one of those things you can reduce, but never eliminate completely. The noise of the combined pair will always be slightly worse than the best of the two when they are in the cross over region.
Bob
On Sep 16, 2012, at 2:58 PM, Tom Knox actast@hotmail.com wrote:
Great dialog, One thing I have seen is the Allan intercept almost always has a "knee". If you wanted the best possible GPS quartz reference developing a variable Allan intercept would allow this knee to be moved and then mathematically removed during a gated measurement.
Allowing to effectively see behind he knee offering lower uncertainty in this important area.
Thomas Knox
Date: Sun, 16 Sep 2012 19:20:24 +0200
From: magnus@rubidium.dyndns.org
To: time-nuts@febo.com
Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote:
In message5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, "Tom Van Baak" writes:
Yes, timing accuracy has been my main focus and in general I have been
using integration times on the low side of 10000 seconds for that,
but it depends a lot on the OCXO/Rb and environment.
The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL
for optimal time stability, and it does a surprisingly good job at it.
Are there papers that talk about how to optimize for best timing or best
frequency or (no free lunch) some compromise combination of the two?
The only writings I am aware of, is what Dave Mills has written and
the PLL code in NTPns, but I havn't followed this closely in the last
10 years, so do check for newer writings.
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 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.
You need to treat the data as loose and tight PLL measure, depending on
what you look for. There is loads of calibration issues, covered in
literature.
If you also have the allan variance between the steered source and
a 3rd, better, source, the task is pretty trivial: Minimize the
area below that curve.
But if you do that on the curve you have, you don't optimize, you
pessimize, since the lowest area, is with a timeconstant of zero.
Going the other direction and maximizing the area is no good either
and trying to balance the area around some pivot related to the
present PLL timeconstant does not converge in my experience.
What I did instead was to (badly) reinvent Shewarts ideas for testing
if the phase residual is under "statistical process control":
I increase the timeconstant if the phase residual has too frequent
zero-crossings and loosen it if they happen too seldom.
Having read a lot more about statistical process control, since I
built those NTP servers for the Air Traffic Control 10 years ago,
I would leverage more of the theory and heuristics developed in
process control. (3sigma violations, length of monotonic direction
etc. etc.)
It's a complex field, and things like temperature dependencies helps to
confuse you.
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.
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.
In message BAY162-W9FFF4214C4DE8FD1752F3DF960@phx.gbl, Tom Knox writes:
Great dialog, One thing I have seen is the Allan intercept almost
always has a "knee". If you wanted the best possible GPS quartz
reference developing a variable Allan intercept would allow this
knee to be moved and then mathematically removed during a gated
measurement.
Allowing to effectively see behind he knee offering lower uncertainty
in this important area.
I did try a spectral approach before I settled on the current approach,
because I foresaw the precence of 12 and 24 hour periodicities, but
while good on the paper and post-factum, I never managed to get it to
autoestimate reliably in real-time.
If you can find the paper about the algorithm timing.com was founded
on, you will find much interesting fodder therein, but my
reimplementation of their algorithem only worked for Rb's I could
never get it to do anything usable for OCXOs.
--
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 2DEA9396-95EB-4092-A443-A72350CC1D19@rtty.us, Bob Camp writes:
The basic assumption is that this is a lab gizmo and that there
is indeed a static adev (or very low frequency phase noise) plot
for the OCXO (or Rb).
Bob,
I think this is where the premier-league differs from the
amateurs-leagues in the time-nuts competition :-)
I suspect that the majority of GPSDO's on this mailinglists do
not have access to a independent frequency standard good enough to
make that measurement, much less a temperature controlled environment.
Yes, in a lab environment, you can measure and adjust it once and
for all, or at least once for every few years.
The rest of us may find it easier to have a PLL that auto-optimizes
so that we don't have to waste our limited time-nut time on
recalibrating our house-standard.
--
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
…but endless testing for minimal return is what being a Time Nut is all about ….
Bob
On Sep 16, 2012, at 3:39 PM, "Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
In message 2DEA9396-95EB-4092-A443-A72350CC1D19@rtty.us, Bob Camp writes:
The basic assumption is that this is a lab gizmo and that there
is indeed a static adev (or very low frequency phase noise) plot
for the OCXO (or Rb).
Bob,
I think this is where the premier-league differs from the
amateurs-leagues in the time-nuts competition :-)
I suspect that the majority of GPSDO's on this mailinglists do
not have access to a independent frequency standard good enough to
make that measurement, much less a temperature controlled environment.
Yes, in a lab environment, you can measure and adjust it once and
for all, or at least once for every few years.
The rest of us may find it easier to have a PLL that auto-optimizes
so that we don't have to waste our limited time-nut time on
recalibrating our house-standard.
--
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.
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 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