Re: [time-nuts] GPSDO control loops and correcting quantization error
djl@montana.com said:
Michael: Actually implementing a 16 bit DAC to its 1-bit minimum resolution
will be headache enough. You will gain a real education in good grounding
practice, shielding, power supply stability and noise, and other Murphy
intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that
tune.
The trick for this application is that you don't need full accuracy over the
full range of the DAC. All you need is roughly linear and stable around the
operating point. The PLL will take care of any offset. Any gain error is
just a minor change to the overall gain.
This thread started with "16 bit PWM DAC". I think that matches the
requirements.
I would expect a problem area would be filtering the PWM output. Anything
you don't filter out will turn into close in spikes. It might be fun to try
to measure them.
64K/72 MHz is about 1 ms. 32bits at 72 MHz is 60 seconds.
Has anybody compared DDS style DACs with PWM? The idea is to spread the
pulses out to make the filtering easier. Instead of 1111100000, you would
get to work with 1010101010
--
These are my opinions. I hate spam.
On Fri, 14 Sep 2012 15:08:53 -0700, Hal Murray
hmurray@megapathdsl.net wrote:
djl@montana.com said:
Michael: Actually implementing a 16 bit DAC to its 1-bit minimum resolution
will be headache enough. You will gain a real education in good grounding
practice, shielding, power supply stability and noise, and other Murphy
intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that
tune.
The trick for this application is that you don't need full accuracy over the
full range of the DAC. All you need is roughly linear and stable around the
operating point. The PLL will take care of any offset. Any gain error is
just a minor change to the overall gain.
One thing you sure want is a DAC that is monotonic. Differential
nonlinearity larger than the least significant bit can cause some
rather peculiar servo loop problems.
My 2.5nS TIC? Very simple: a 400MHz counter start-stop gated with the two
signal to compare. I have published here the VHDL code for it few months
ago. Really nothing new but simple and useful for a 35-40nS GPSDO PPS
output from an OCXO. The Rb PPS wondering is actually under evaluation
against the Z3815A.
On Sat, Sep 15, 2012 at 12:08 AM, Hal Murray hmurray@megapathdsl.netwrote:
djl@montana.com said:
Michael: Actually implementing a 16 bit DAC to its 1-bit minimum
resolution
will be headache enough. You will gain a real education in good grounding
practice, shielding, power supply stability and noise, and other Murphy
intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that
tune.
The trick for this application is that you don't need full accuracy over
the
full range of the DAC. All you need is roughly linear and stable around
the
operating point. The PLL will take care of any offset. Any gain error is
just a minor change to the overall gain.
This thread started with "16 bit PWM DAC". I think that matches the
requirements.
I would expect a problem area would be filtering the PWM output. Anything
you don't filter out will turn into close in spikes. It might be fun to
try
to measure them.
64K/72 MHz is about 1 ms. 32bits at 72 MHz is 60 seconds.
Has anybody compared DDS style DACs with PWM? The idea is to spread the
pulses out to make the filtering easier. Instead of 1111100000, you would
get to work with 1010101010
--
These are my opinions. I hate spam.
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.
I would expect a problem area would be filtering the PWM output. Anything
you don't filter out will turn into close in spikes. It might be fun to try
to measure them.
64K/72 MHz is about 1 ms. 32bits at 72 MHz is 60 seconds.
Has anybody compared DDS style DACs with PWM? The idea is to spread the
pulses out to make the filtering easier. Instead of 1111100000, you would
get to work with 1010101010
Hal,
The Z3801A 16-bit DAC is dithered at 102.4 Hz and LP filtered. Details and plots:
http://leapsecond.com/pages/z3801a-efc/
/tvb
I did some experiments with a charge-transfer D/A and at least as far
as I can see, that has the potential to go beyond 30 bits.
The key observation is, as others have pointed out, that we only really
care about relative local linearity, the PLL loop will take care of
everything else.
What I did was take a large-ish low-leakage capacitor and put a voltage
follower after it, to drive the EFC pin.
The PLL loop, implemented in software, controlled two fet-switches
which would deliver positive or negative pulses to the capacitor
through matched resistors.
The software involvement allows for trivial calibration of any
unbalance between the switches & resistors, and even, if you manage
to measure and model it, I didn't, the capacitors leakage current.
By controlling the length of the pulses, you can get incredibly small
"steps" in your output voltage while retaining a wide dynamic range.
The neat thing is that you do not need a particularly precise or stable
reference voltage for this design.
Ideally you would want to drive the switches with constant current
sources, but if you put an 10bit ADC on the voltage followers output,
so you know the approximate voltage over the capacitor, it is trivial
to model the charge delivered per unit time in software.
At the time I had not read the HPJ article about the 3458A, and if
I do it again, there are several tricks from there I would employ:
Balanced pulses to linearize switch-noise and multiple drivers of
different strengths for faster capture.
--
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.
Hal Murray wrote:
djl@montana.com said:
Michael: Actually implementing a 16 bit DAC to its 1-bit minimum resolution
will be headache enough. You will gain a real education in good grounding
practice, shielding, power supply stability and noise, and other Murphy
intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that
tune.
The trick for this application is that you don't need full accuracy over the
full range of the DAC. All you need is roughly linear and stable around the
operating point. The PLL will take care of any offset. Any gain error is
just a minor change to the overall gain.
This thread started with "16 bit PWM DAC". I think that matches the
requirements.
I would expect a problem area would be filtering the PWM output. Anything
you don't filter out will turn into close in spikes. It might be fun to try
to measure them.
64K/72 MHz is about 1 ms. 32bits at 72 MHz is 60 seconds.
Has anybody compared DDS style DACs with PWM? The idea is to spread the
pulses out to make the filtering easier. Instead of 1111100000, you would
get to work with 1010101010
Using a synchronous filter for the PWM DAC eases the additional
filtering required considerably.
24 bit resolution is readily achieved by combining the outputs of a pair
of PWM sources sharing a single synchronous filter.
Bruce
On 09/15/2012 12:08 AM, Hal Murray wrote:
djl@montana.com said:
Michael: Actually implementing a 16 bit DAC to its 1-bit minimum resolution
will be headache enough. You will gain a real education in good grounding
practice, shielding, power supply stability and noise, and other Murphy
intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that
tune.
The trick for this application is that you don't need full accuracy over the
full range of the DAC. All you need is roughly linear and stable around the
operating point. The PLL will take care of any offset. Any gain error is
just a minor change to the overall gain.
This thread started with "16 bit PWM DAC". I think that matches the
requirements.
I would expect a problem area would be filtering the PWM output. Anything
you don't filter out will turn into close in spikes. It might be fun to try
to measure them.
64K/72 MHz is about 1 ms. 32bits at 72 MHz is 60 seconds.
Has anybody compared DDS style DACs with PWM? The idea is to spread the
pulses out to make the filtering easier. Instead of 1111100000, you would
get to work with 1010101010
PWM has the fantastic power of putting most energy into the lowest
frequency, which makes analog filtering extra hard, so you need to move
the bandwidth down or use higher degrees filter for a good filter slope.
The filter bandwidth puts an upper limit to the PLL bandwidth.
I've done a inverse PWM spectrum modulation, which isn't all that hard,
and it has significant improvements over PWM.
Another approach is to use the sigma-delta approach which smooths the
frequency spikes out to noise.
Cheers,
Magnus
Hi
If the objective is to build a GPSDO that needs a 32 bit D/A as opposed to a 16 to 20 bit part, there are some things you have to consider.
The output of your GPS has jitter on it. How much jitter is a "that depends" sort of thing, but there's always more jitter than on the output of a good OCXO or Rb. The idea is to get the short term stability of the OCXO or Rb and the long term stability of the GPS. To do that, you are going to set the cross over between the GPS and OCXO at some magic point. Exactly where depends on the actual noise plots of your OCXO and your GPS. With a good DOCXO you can easily have a cross over out in the 1,000 to 5,000 second range. With a Rb the cross over is likely to be in the 100,000 to 200,000 second range. If it's closer in you degrade the short term stability of the OCXO or Rb.
If the cross over is at 100,000 seconds, everything that happens quicker than 100,000 seconds is ignored by the PLL. Stuff that happens more slowly than 100,000 seconds is corrected by the PLL. No, it's not exactly a brick wall, but it does fundamentally work that way.
What ever happens with the DAC quicker than the cross over, passes straight through to the OCXO or Rb. In the case of a 100,000 second cross over, daily temperature cycling in the lab winds up as short term instability and is not corrected by the PLL. Hourly cycles (think HVAC cycles) very much will show up as short term issues that are not corrected. If indeed 32 bits matters, then instability at the 32 bit level will show up. Indeed temperature is not the only issue, noise on the DAC output is also a concern. Johnson noise is one source, there are others.
No free lunch…
Bob
On Sep 15, 2012, at 3:36 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
I did some experiments with a charge-transfer D/A and at least as far
as I can see, that has the potential to go beyond 30 bits.
The key observation is, as others have pointed out, that we only really
care about relative local linearity, the PLL loop will take care of
everything else.
What I did was take a large-ish low-leakage capacitor and put a voltage
follower after it, to drive the EFC pin.
The PLL loop, implemented in software, controlled two fet-switches
which would deliver positive or negative pulses to the capacitor
through matched resistors.
The software involvement allows for trivial calibration of any
unbalance between the switches & resistors, and even, if you manage
to measure and model it, I didn't, the capacitors leakage current.
By controlling the length of the pulses, you can get incredibly small
"steps" in your output voltage while retaining a wide dynamic range.
The neat thing is that you do not need a particularly precise or stable
reference voltage for this design.
Ideally you would want to drive the switches with constant current
sources, but if you put an 10bit ADC on the voltage followers output,
so you know the approximate voltage over the capacitor, it is trivial
to model the charge delivered per unit time in software.
At the time I had not read the HPJ article about the 3458A, and if
I do it again, there are several tricks from there I would employ:
Balanced pulses to linearize switch-noise and multiple drivers of
different strengths for faster capture.
--
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 437C6604-20A5-4E05-BE99-9E26B01D80B7@rtty.us, Bob Camp writes:
If indeed 32 bits matters, then instability at the 32 bit level will show up.
[...]
No free lunch
Absolutely agree there.
My point was merely that the requirements for the DAC after a
software-PLL are very narrow and specific, compared the the quality
metrics of DAC's in general, and that low cost methods are available
to meet those needs, so there is no need to spend a fortune on a
general X bit DAC, if cheaper special purpose one will do.
One of the advantages of the charge-transfer DAC concept is that
there is only thermal noise for a stable output, there is no reference
voltage which can suffer from tempco or noise bleed-through.
You'll have the tempco of your integration capacitor to deal with,
but already around 16-20 bits you will be ovenizing everything anyway.
The noise on EFC voltage changes can be given an almost arbitrary high
frequency spectrum which will filter out long before it reaches the
EFC input of the OCXO or Rb.
In steady state, my experiment fired a single 40nsec pulse every
some seconds, and I never managed to detect these pulses on the
output of the voltage follower, because the integration capacitor
is a glorified low-pass filter.
Even at high update rates, it would be possible to use a PRNG to
spread out the spectrum of the update noise.
--
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
The real answer is that you don't need anything near 32 bits. Anything with a <1.0x10^-13 AVAR isn't going to have much of a tuning range on the EFC. 22 bits will do just fine for a 1 ppm EFC range part with 1.0 x10^-12 at 1 second. With that sort of sensitivity you will have a very hard time getting the voltage into the OCXO without a gotcha right at the terminals, unless the unit has a fully isolated EFC input. That rules out roughly 99.99% of all OCXO's.
Bob
On Sep 15, 2012, at 3:12 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message 437C6604-20A5-4E05-BE99-9E26B01D80B7@rtty.us, Bob Camp writes:
If indeed 32 bits matters, then instability at the 32 bit level will show up.
[...]
No free lunch
Absolutely agree there.
My point was merely that the requirements for the DAC after a
software-PLL are very narrow and specific, compared the the quality
metrics of DAC's in general, and that low cost methods are available
to meet those needs, so there is no need to spend a fortune on a
general X bit DAC, if cheaper special purpose one will do.
One of the advantages of the charge-transfer DAC concept is that
there is only thermal noise for a stable output, there is no reference
voltage which can suffer from tempco or noise bleed-through.
You'll have the tempco of your integration capacitor to deal with,
but already around 16-20 bits you will be ovenizing everything anyway.
The noise on EFC voltage changes can be given an almost arbitrary high
frequency spectrum which will filter out long before it reaches the
EFC input of the OCXO or Rb.
In steady state, my experiment fired a single 40nsec pulse every
some seconds, and I never managed to detect these pulses on the
output of the voltage follower, because the integration capacitor
is a glorified low-pass filter.
Even at high update rates, it would be possible to use a PRNG to
spread out the spectrum of the update noise.
--
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.
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?
/tvb
----- Original Message -----
From: "Bob Camp" lists@rtty.us
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Saturday, September 15, 2012 9:46 AM
Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi
If the objective is to build a GPSDO that needs a 32 bit D/A as opposed to a 16 to 20 bit part, there are some things you have to consider.
The output of your GPS has jitter on it. How much jitter is a "that depends" sort of thing, but there's always more jitter than on the output of a good OCXO or Rb. The idea is to get the short term stability of the OCXO or Rb and the long term stability of the GPS. To do that, you are going to set the cross over between the GPS and OCXO at some magic point. Exactly where depends on the actual noise plots of your OCXO and your GPS. With a good DOCXO you can easily have a cross over out in the 1,000 to 5,000 second range. With a Rb the cross over is likely to be in the 100,000 to 200,000 second range. If it's closer in you degrade the short term stability of the OCXO or Rb.
If the cross over is at 100,000 seconds, everything that happens quicker than 100,000 seconds is ignored by the PLL. Stuff that happens more slowly than 100,000 seconds is corrected by the PLL. No, it's not exactly a brick wall, but it does fundamentally work that way.
What ever happens with the DAC quicker than the cross over, passes straight through to the OCXO or Rb. In the case of a 100,000 second cross over, daily temperature cycling in the lab winds up as short term instability and is not corrected by the PLL. Hourly cycles (think HVAC cycles) very much will show up as short term issues that are not corrected. If indeed 32 bits matters, then instability at the 32 bit level will show up. Indeed temperature is not the only issue, noise on the DAC output is also a concern. Johnson noise is one source, there are others.
No free lunch…
Bob
Agreed. The DAC resolution only needs to be a little better than the short-term noise of the OCXO. For example, there's no point at all stepping the DAC by 1e-13 if the OCXO's own noise is on the order of 1e-11 or 1e-12. On the other hand, what you want to avoid is having the DAC/EFC increase the short-term noise of the OCXO. Sadly this seems to happen a lot. Just measure the stability of your favorite GPSDO with and without the DAC/EFC operating.
I've not seen graphs but I assume there's also a cross-over where DAC resolution/noise as a function of update rate meets OCXO stability as a function of tau.
/tvb
----- Original Message -----
From: "Bob Camp" lists@rtty.us
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Saturday, September 15, 2012 1:41 PM
Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi
The real answer is that you don't need anything near 32 bits. Anything with a <1.0x10^-13 AVAR isn't going to have much of a tuning range on the EFC. 22 bits will do just fine for a 1 ppm EFC range part with 1.0 x10^-12 at 1 second. With that sort of sensitivity you will have a very hard time getting the voltage into the OCXO without a gotcha right at the terminals, unless the unit has a fully isolated EFC input. That rules out roughly 99.99% of all OCXO's.
Bob
In message 5C1BBD844F6145969FE8A4785FEE490A@pc52, "Tom Van Baak" writes:
Has anyone on the list done work optimizing the timing accuracy rather than
the frequency stability?
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.
--
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.
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?
/tvb
Hi
If your definition of timing accuracy is "within 100 ns of GPS time ten minutes after lock" then a faster crossover is a better idea. A faster loop will track GPS better. If your GPS noise is on the order of 10 ns, your time error will be pretty low. An example: 100s loop and 10 ns GPS, => 1x10^-10 noise.
If your definition of timing accuracy is "best short term stability plot" then picking a long crossover is the way to do it. You want the PLL to only kick in once it's going to do no harm to the noise signature. An example: 10,000s loop and 10 ns GPS => 1x10^-12 noise.
If your GPS noise is lower / higher, the numbers obviously will change accordingly. If your GPS noise is dimensioned in one set of units and your OCXO noise in another set of units, that's going to require a units conversion (pk-pk != rms != 3 sigma etc).
Bob
On Sep 16, 2012, at 12:40 AM, Tom Van Baak tvb@LeapSecond.com 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?
/tvb
----- Original Message -----
From: "Bob Camp" lists@rtty.us
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Saturday, September 15, 2012 9:46 AM
Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi
If the objective is to build a GPSDO that needs a 32 bit D/A as opposed to a 16 to 20 bit part, there are some things you have to consider.
The output of your GPS has jitter on it. How much jitter is a "that depends" sort of thing, but there's always more jitter than on the output of a good OCXO or Rb. The idea is to get the short term stability of the OCXO or Rb and the long term stability of the GPS. To do that, you are going to set the cross over between the GPS and OCXO at some magic point. Exactly where depends on the actual noise plots of your OCXO and your GPS. With a good DOCXO you can easily have a cross over out in the 1,000 to 5,000 second range. With a Rb the cross over is likely to be in the 100,000 to 200,000 second range. If it's closer in you degrade the short term stability of the OCXO or Rb.
If the cross over is at 100,000 seconds, everything that happens quicker than 100,000 seconds is ignored by the PLL. Stuff that happens more slowly than 100,000 seconds is corrected by the PLL. No, it's not exactly a brick wall, but it does fundamentally work that way.
What ever happens with the DAC quicker than the cross over, passes straight through to the OCXO or Rb. In the case of a 100,000 second cross over, daily temperature cycling in the lab winds up as short term instability and is not corrected by the PLL. Hourly cycles (think HVAC cycles) very much will show up as short term issues that are not corrected. If indeed 32 bits matters, then instability at the 32 bit level will show up. Indeed temperature is not the only issue, noise on the DAC output is also a concern. Johnson noise is one source, there are others.
No free lunch…
Bob
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 CE93652A-1DA6-48E3-9883-D7616AC24A78@rtty.us, Bob Camp writes:
Bob,
There's one thing makes me scratch my head here: Why do you keep
arguing like the timeconstant cannot be changed dynamically ?
I use a very aggresive timeconstants initially, to quickly get the
phase offset under control, and then I ramp up the timeconstant in
order to reduce phase noise of the GPS, until I hit something which
looks like the "Allan-intercept" (as Dave Mills calls it).
It' won't take long time for us to agree that the timeconstant
is a tradeoff between phase and frequency error, but just because
it is called a "timeconstant" doesn't mean we cannot change it.
--
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 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.
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
Hi
The time constant can indeed be changed dynamically, that's what is often done.
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.
Bob
On Sep 16, 2012, at 9:49 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message CE93652A-1DA6-48E3-9883-D7616AC24A78@rtty.us, Bob Camp writes:
Bob,
There's one thing makes me scratch my head here: Why do you keep
arguing like the timeconstant cannot be changed dynamically ?
I use a very aggresive timeconstants initially, to quickly get the
phase offset under control, and then I ramp up the timeconstant in
order to reduce phase noise of the GPS, until I hit something which
looks like the "Allan-intercept" (as Dave Mills calls it).
It' won't take long time for us to agree that the timeconstant
is a tradeoff between phase and frequency error, but just because
it is called a "timeconstant" doesn't mean we cannot change it.
--
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 50560A58.5010607@rubidium.dyndns.org, Magnus Danielson writes:
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.
No, not really.
The reason I went with the "statistical control" approach was exactly
to not be confused or mislead by environmental or other factors: I
wanted a PLL which on its own would adapt to circumstances on its
own, while still maximizing the hold-over time in case of GPS loss,
and all in all it has worked very well.
So far I have seen it cope admirably with an OCXO which went from
indoors to outdoors environment in the middle of winter, a PRS10
which gradually ran out of steam and only locked 40% of the time and
various other odd-ball events, so I think I'm justified in saying
that it does a pretty good job for autonomous and even unattended
operation.
It's certainly not perfect, but it is painfully obvious that the
adaptive PLL based on statical control heuristics is much more
resilient than a fixed or hand-tuned PLL.
I've been trying to find an excuse for giving NTPns an overhaul,
(PTP is a leading candidate for this) to get a chance to iron out
the kinks I have spotted over the last 10 years, but so far
life keeps me busy with other interesting stuff.
--
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.