Modified Allan Deviation and counter averaging
Sorry this is a bit long-ish, but I figure I'm saving time putting
in all the details up front.
The canonical time-nut way to set up a MVAR measurement is to feed
two sources to a HP5370 and measure the time interval between their
zero crossings often enough to resolve any phase ambiguities caused
by frequency differences.
The computer unfolds the phase wrap-arounds, and calculates the
MVAR using the measurement rate, typically 100, 10 or 1 Hz, as the
minimum Tau.
However, the HP5370 has noise-floor in the low picoseconds, which
creates the well known diagonal left bound on what we can measure
this way.
So it is tempting to do this instead:
Every measurement period, we let the HP5370 do a burst of 100
measurements[*] and feed the average to MVAR, and push the diagonal
line an order of magnitude (sqrt(100)) further down.
At its specified rate, the HP5370 will take 1/30th of a second to
do a 100 sample average measurement.
If we are measuring once each second, that's only 3% of the Tau.
No measurement is ever instantaneous, simply because the two zero
crossings are not happening right at the mesurement epoch.
If I measure two 10MHz signals the canonical way, the first zero
crossing could come as late as 100(+epsilon) nanoseconds after the
epoch, and the second as much as 100(+epsilon) nanoseconds later.
An actual point of the measurement doesn't even exist, but picking
with the midpoint we get an average delay of 75ns, worst case 150ns.
That works out to one part in 13 million which is a lot less than 3%,
but certainly not zero as the MVAR formula pressume.
Eyeballing it, 3% is well below the reproducibility I see on MVAR
measurements, and I have therefore waved the method and result
through, without a formal proof.
However, I have very carefully made sure to never show anybody
any of these plots because of the lack of proof.
Thanks to Johns Turbo-5370 we can do burst measurements at much
higher rates than 3000/s, and thus potentially push the diagonal
limit more than a decade to the left, while still doing minimum
violence to the mathematical assumptions under MVAR.
[*] The footnote is this: The HP5370 firwmare does not make triggered
bust averages an easy measurement, but we can change that, in
particular with Johns Turbo-5370.
But before I attempt to do that, I would appreciate if a couple of
the more math-savy time-nuts could ponder the soundness of the
concept.
Apart from the delayed measurement point, I have not been able
to identify any issues.
The frequency spectrum filtered out by the averaging is waaaay to
the left of our minimum Tau.
Phase wrap-around inside bursts can be detected and unfolded
in the processing.
Am I overlooking anything ?
--
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 “simple” way to see what this does is to plug your sampling approach
into the DSP world and see what sort of filter it creates. Put another way - would you
use this to make a lowpass filter? If so how good a filter would it be?
At least with a hand wave, I would not deliberately use this process as a lowpass. Since
it averages, it does have lowpass properties. Until you get to the point that you are averaging
a cycle, it’s not got much of a lowpass. It’s a discontinuous boxcar, you likely will get
a few zeros in the passband around the width of your sample window.
Now the question: Does this lowpass (crummy though it is) impact your noise? Well sure, to some
degree it does. The big way it would is if those zeros (which probably aren’t as deep as you might think) line
up with a messy spike in your noise.
So where are the zeros? If you take 100 samples of a 100 ns period waveform, your boxcar is
10 us wide. Expect zeros (or at least dips) at 100KHz XN. Move the samples up to 1,000 and your
dips are at 10 KHz X N. I’d suggest that most “normal noise” spectra are going to look pretty much
the same with and without what’s been taken away.
Now, take it up to 10% of the total 1 second window and you are at 10Hz. Those zeros are going
to mess with your spectra and likely will impact your 1 second MVAR or AVAR or whatever.
All that assumes you are taking a reading every cycle with the uber-5370. If you are doing it old school,
your sampling process will wrap the noise spectrum a bit. That’s going to make the analysis a bit more
messy.
Bob
On Jul 28, 2015, at 5:51 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
Sorry this is a bit long-ish, but I figure I'm saving time putting
in all the details up front.
The canonical time-nut way to set up a MVAR measurement is to feed
two sources to a HP5370 and measure the time interval between their
zero crossings often enough to resolve any phase ambiguities caused
by frequency differences.
The computer unfolds the phase wrap-arounds, and calculates the
MVAR using the measurement rate, typically 100, 10 or 1 Hz, as the
minimum Tau.
However, the HP5370 has noise-floor in the low picoseconds, which
creates the well known diagonal left bound on what we can measure
this way.
So it is tempting to do this instead:
Every measurement period, we let the HP5370 do a burst of 100
measurements[*] and feed the average to MVAR, and push the diagonal
line an order of magnitude (sqrt(100)) further down.
At its specified rate, the HP5370 will take 1/30th of a second to
do a 100 sample average measurement.
If we are measuring once each second, that's only 3% of the Tau.
No measurement is ever instantaneous, simply because the two zero
crossings are not happening right at the mesurement epoch.
If I measure two 10MHz signals the canonical way, the first zero
crossing could come as late as 100(+epsilon) nanoseconds after the
epoch, and the second as much as 100(+epsilon) nanoseconds later.
An actual point of the measurement doesn't even exist, but picking
with the midpoint we get an average delay of 75ns, worst case 150ns.
That works out to one part in 13 million which is a lot less than 3%,
but certainly not zero as the MVAR formula pressume.
Eyeballing it, 3% is well below the reproducibility I see on MVAR
measurements, and I have therefore waved the method and result
through, without a formal proof.
However, I have very carefully made sure to never show anybody
any of these plots because of the lack of proof.
Thanks to Johns Turbo-5370 we can do burst measurements at much
higher rates than 3000/s, and thus potentially push the diagonal
limit more than a decade to the left, while still doing minimum
violence to the mathematical assumptions under MVAR.
[*] The footnote is this: The HP5370 firwmare does not make triggered
bust averages an easy measurement, but we can change that, in
particular with Johns Turbo-5370.
But before I attempt to do that, I would appreciate if a couple of
the more math-savy time-nuts could ponder the soundness of the
concept.
Apart from the delayed measurement point, I have not been able
to identify any issues.
The frequency spectrum filtered out by the averaging is waaaay to
the left of our minimum Tau.
Phase wrap-around inside bursts can be detected and unfolded
in the processing.
Am I overlooking anything ?
--
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.
If the burst rate is high enough the interpolators will no longer be able to maintain phase lock, the question is how high a burst rate is feasible without losing lock?
Bruce
On Wednesday, 29 July 2015 9:51 AM, Poul-Henning Kamp <phk@phk.freebsd..dk> wrote:
Sorry this is a bit long-ish, but I figure I'm saving time putting
in all the details up front.
The canonical time-nut way to set up a MVAR measurement is to feed
two sources to a HP5370 and measure the time interval between their
zero crossings often enough to resolve any phase ambiguities caused
by frequency differences.
The computer unfolds the phase wrap-arounds, and calculates the
MVAR using the measurement rate, typically 100, 10 or 1 Hz, as the
minimum Tau.
However, the HP5370 has noise-floor in the low picoseconds, which
creates the well known diagonal left bound on what we can measure
this way.
So it is tempting to do this instead:
Every measurement period, we let the HP5370 do a burst of 100
measurements[*] and feed the average to MVAR, and push the diagonal
line an order of magnitude (sqrt(100)) further down.
At its specified rate, the HP5370 will take 1/30th of a second to
do a 100 sample average measurement.
If we are measuring once each second, that's only 3% of the Tau.
No measurement is ever instantaneous, simply because the two zero
crossings are not happening right at the mesurement epoch.
If I measure two 10MHz signals the canonical way, the first zero
crossing could come as late as 100(+epsilon) nanoseconds after the
epoch, and the second as much as 100(+epsilon) nanoseconds later.
An actual point of the measurement doesn't even exist, but picking
with the midpoint we get an average delay of 75ns, worst case 150ns.
That works out to one part in 13 million which is a lot less than 3%,
but certainly not zero as the MVAR formula pressume.
Eyeballing it, 3% is well below the reproducibility I see on MVAR
measurements, and I have therefore waved the method and result
through, without a formal proof.
However, I have very carefully made sure to never show anybody
any of these plots because of the lack of proof.
Thanks to Johns Turbo-5370 we can do burst measurements at much
higher rates than 3000/s, and thus potentially push the diagonal
limit more than a decade to the left, while still doing minimum
violence to the mathematical assumptions under MVAR.
[*] The footnote is this: The HP5370 firwmare does not make triggered
bust averages an easy measurement, but we can change that, in
particular with Johns Turbo-5370.
But before I attempt to do that, I would appreciate if a couple of
the more math-savy time-nuts could ponder the soundness of the
concept.
Apart from the delayed measurement point, I have not been able
to identify any issues.
The frequency spectrum filtered out by the averaging is waaaay to
the left of our minimum Tau.
Phase wrap-around inside bursts can be detected and unfolded
in the processing.
Am I overlooking anything ?
--
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.
Apart from the delayed measurement point, I have not been able
to identify any issues.
The frequency spectrum filtered out by the averaging is waaaay to
the left of our minimum Tau.
Phase wrap-around inside bursts can be detected and unfolded
in the processing.
Am I overlooking anything ?
I think this is basically a valid thing to do, under specific conditions. It works well with the Wavecrest DTS boxes, which can take several thousand samples per second and distill them down to a single TI reading. I've observed good agreement between ADEV plots taken with the DTS2070 and direct-digital analyzers down to the ~2E-12 level at t=1s.
The main caveat is that the burst of averaged readings needs to take up a very small portion of the tau-zero interval, as you point out, to keep the averaging effects out of the visible portion of the plot. This might not be a very big problem with MDEV but it is definitely an issue with ADEV.
The second thing to watch for is even more important: while the host software (TimeLab, Stable32, etc.) can handle phase wraps that occur between counter readings, the sub-reading averaging algorithm in the counter will not. Phase wraps in the middle of a burst will corrupt the data badly, and I don't see any reliable way to detect and unfold them after the fact.
So if John's firmware can handle intra-burst phase wraps before returning each averaged reading to the software, it could be a big win. Otherwise this technique should be confined to cases where two extremely stable sources are being compared with no possibility of phase wraps. It would be a good way to keep an eye on the short-term behavior of a pair of Cs or GPS clocks, for instance.
-- john, KE5FX
Miles Design LLC
Good morning,
On 07/28/2015 11:51 PM, Poul-Henning Kamp wrote:
Sorry this is a bit long-ish, but I figure I'm saving time putting
in all the details up front.
The canonical time-nut way to set up a MVAR measurement is to feed
two sources to a HP5370 and measure the time interval between their
zero crossings often enough to resolve any phase ambiguities caused
by frequency differences.
The computer unfolds the phase wrap-arounds, and calculates the
MVAR using the measurement rate, typically 100, 10 or 1 Hz, as the
minimum Tau.
However, the HP5370 has noise-floor in the low picoseconds, which
creates the well known diagonal left bound on what we can measure
this way.
One of the papers that I referenced in my long post on PDEV has a nice
section on that boundary, worth reading.
So it is tempting to do this instead:
Every measurement period, we let the HP5370 do a burst of 100
measurements[*] and feed the average to MVAR, and push the diagonal
line an order of magnitude (sqrt(100)) further down.
At its specified rate, the HP5370 will take 1/30th of a second to
do a 100 sample average measurement.
If we are measuring once each second, that's only 3% of the Tau.
No measurement is ever instantaneous, simply because the two zero
crossings are not happening right at the mesurement epoch.
If I measure two 10MHz signals the canonical way, the first zero
crossing could come as late as 100(+epsilon) nanoseconds after the
epoch, and the second as much as 100(+epsilon) nanoseconds later.
An actual point of the measurement doesn't even exist, but picking
with the midpoint we get an average delay of 75ns, worst case 150ns.
That works out to one part in 13 million which is a lot less than 3%,
but certainly not zero as the MVAR formula pressume.
Eyeballing it, 3% is well below the reproducibility I see on MVAR
measurements, and I have therefore waved the method and result
through, without a formal proof.
However, I have very carefully made sure to never show anybody
any of these plots because of the lack of proof.
Thanks to Johns Turbo-5370 we can do burst measurements at much
higher rates than 3000/s, and thus potentially push the diagonal
limit more than a decade to the left, while still doing minimum
violence to the mathematical assumptions under MVAR.
The Turbo-5370 creates an interesting platform for us to play with, indeed.
[*] The footnote is this: The HP5370 firwmare does not make triggered
bust averages an easy measurement, but we can change that, in
particular with Johns Turbo-5370.
But before I attempt to do that, I would appreciate if a couple of
the more math-savy time-nuts could ponder the soundness of the
concept.
You rang.
Apart from the delayed measurement point, I have not been able
to identify any issues.
The frequency spectrum filtered out by the averaging is waaaay to
the left of our minimum Tau.
Phase wrap-around inside bursts can be detected and unfolded
in the processing.
Am I overlooking anything ?
You will get an improvement in your response, yes, but it will not pan
out as you would like it to. What you create is, just as with the Lambda
and Omega counters, a pre-filter mechanism that comes before the ADEV or
MDEV filtering prior to squaring. The filtering aims at filtering out
white noise or (systematic) noise behaving like white noise. The
filtering method was proposed by J.J. Snyder in 1980 for laser
processing and further in his 1981 paper, published at the same time as
Allan et al published the MDEV/MVAR paper that is directly inspired by
Snyders work. Snyder shows that rather than getting a MVAR slope of
1/tau^2 you get a slope of 1/tau^3 for the ADEV estimation. This slope
change comes from the changing of the system bandwidth, as the tau
increases rather than the classical method of having a fixed system
bandwidth and then process ADEV on that. MDEV/MVAR uses a "software
filter" to alter the system bandwidth along with tau, and thus provide a
fix for the 15 year hole of not being able to separate white and flicker
phase noise that Dave Allan was so annoyed with.
Anyway, the key point here is that the filter bandwidth changes with
tau. The form of discussions we have had on Lambda (53132) and Omega
(CNT-90) counters and the hockey-puck response they create is because
they have a fixed pre-filtering bandwidth. What you proposes is a
similar form of weighing mechanism providing a similar type of filtering
mechanism and a similar fixed pre-filtering bandwidth and thus causing a
similary type of response. Just as with the Lambda and Gamma counters,
using MDEV rather than ADEV does not really heal the problem, since for
longer taus, you observe signals in the pass-band of the fixed
low-pass-filter and your behavior have gone back to the behavior of the
ADEV or MDEV of the counter without the filtering mechanism. This is the
unescapable fact.
To solve this, you will have to build a pre-filtering mechanism that
allows itself to be extended to any multiple of tau as your processing
continues. You can do this, but you need to learn to respect the rules
of the game. You can do this on the Turbo 5370 too, it's actually a
great platform for it. One way is to do a Lambda counter collection,
just as in the J.J.Snyder paper, which is to just accumulate phase
measures into blocks of m0 samples, being m0tau0 long. These blocks can
later be combined to create longer blocks of any multiple of m0tau0,
and preserving the filtering behavior as the m1 multiple forms
m1m0tau0. If you want to do the same for a Omega counter, you will
also have to collect another the sum of a weigted series. The correct
extension of these blocks form the correct MDEV/MVAR estimator, and the
correct extension of blocks for a Omega style response can form the
correct PDEV/PVAR estimator.
So, rather than doing the burst-processing that you propose, I propose
that you create a series of say 1000 samples per block, evenly dispersed
out with the tau0, and then combine them properly in post-processing to
form the MDEV/MVAR estimator. This is fairly straight-forward.
Attempting the PDEV/PVAR will give you 3/4 of the white noise (that is
-1.25 dB) but the same slope, and the ways to build and combine the
values for multiple taus have not yet been published in a peer-review form.
Now, going back to the white-noise slope, it consists of two things,
actual sum of white noise mainly hitting the limiter stage, converting
it into white noise phase modulation, and also the counter resolution
and thus time-quantization as being played by the phases of the two
clocks being compared. As you take N number of samples and average over
a period of time, for the white noise part the distribution over time
does not care, as the white phase noise does by definition not correlate
to each other, so for that filtering, bursting it or spreading it evenly
does not care. However, for the clock signals interacting with the
counter resolution (avoiding all higher order terms here), it is a
systematic noise and not a random noise, so the way the sample points is
distributed does interact with the systematic noise. Essentially, our
increased average capability for resolution comes from us essentially
finding out how many cycles it takes for counter phase to jump between
two nearby states. There exists many Nyquist wrappings of this, but
that's essentially what we do to beat this noise. It's similar to the
delay-line of the 5371/5372 or for that mater the beat note of the 5370.
The way you distribute your sampling does care, as the burst one will
only provide this service to beat notes having a length being a multiple
to the length of the beat, so for it to do that for lower frequencies,
you want it as long as possible, which means you want it evenly
distributed over the block.
This is a bitch to understand, as the ADEV/MDEV/PDEV stuff needs to be
understood both in time and frequency plane. Even very well established
scientists have come clean about them messing it up. Many just look on
slopes and think it is random noise, rather than separating random noise
and systematic noise behaviors. Averaging methods can sometimes kill
those two birds with one stone, but you need to understand how it does
it for both cases to apply the stone properly. What I propose is a sane
way of applying the stone, and we can trace it back to peer-reviewed
papers even and feel confident about the results.
This topic is in fact so messed up, I think some of what I described is
not seen properly expressed in peer-reviewed papers. I do hope you did
learn something from this little comment.
Cheers,
Magnus
Very much looking forward to some insight on this method - I've done
pretty much the same experiment with an E1740A (48.8ps resolution); trigger
from a z3805A PPS, start TI measurement on the first rising edge of the
z3805A 10Mhz (on channel 1) following the trigger, stop the TI measurement
on (i.e.) the 30th rising edge on whatever signal is on channel 2. Capture
100 samples gap-free every trigger, and average as described. It is
severely bandwidth-limited by the GPIB interface as to the number of
samples that can be collected on a "per second basis", but the E1740A can
store up to ~500k samples, so it can all be batch processed after the
measurement is complete. It will be very interesting to see if the method
has any merit.
Ole
On Tue, Jul 28, 2015 at 11:51 PM, Poul-Henning Kamp phk@phk.freebsd.dk
wrote:
Sorry this is a bit long-ish, but I figure I'm saving time putting
in all the details up front.
The canonical time-nut way to set up a MVAR measurement is to feed
two sources to a HP5370 and measure the time interval between their
zero crossings often enough to resolve any phase ambiguities caused
by frequency differences.
The computer unfolds the phase wrap-arounds, and calculates the
MVAR using the measurement rate, typically 100, 10 or 1 Hz, as the
minimum Tau.
However, the HP5370 has noise-floor in the low picoseconds, which
creates the well known diagonal left bound on what we can measure
this way.
So it is tempting to do this instead:
Every measurement period, we let the HP5370 do a burst of 100
measurements[*] and feed the average to MVAR, and push the diagonal
line an order of magnitude (sqrt(100)) further down.
At its specified rate, the HP5370 will take 1/30th of a second to
do a 100 sample average measurement.
If we are measuring once each second, that's only 3% of the Tau.
No measurement is ever instantaneous, simply because the two zero
crossings are not happening right at the mesurement epoch.
If I measure two 10MHz signals the canonical way, the first zero
crossing could come as late as 100(+epsilon) nanoseconds after the
epoch, and the second as much as 100(+epsilon) nanoseconds later.
An actual point of the measurement doesn't even exist, but picking
with the midpoint we get an average delay of 75ns, worst case 150ns.
That works out to one part in 13 million which is a lot less than 3%,
but certainly not zero as the MVAR formula pressume.
Eyeballing it, 3% is well below the reproducibility I see on MVAR
measurements, and I have therefore waved the method and result
through, without a formal proof.
However, I have very carefully made sure to never show anybody
any of these plots because of the lack of proof.
Thanks to Johns Turbo-5370 we can do burst measurements at much
higher rates than 3000/s, and thus potentially push the diagonal
limit more than a decade to the left, while still doing minimum
violence to the mathematical assumptions under MVAR.
[*] The footnote is this: The HP5370 firwmare does not make triggered
bust averages an easy measurement, but we can change that, in
particular with Johns Turbo-5370.
But before I attempt to do that, I would appreciate if a couple of
the more math-savy time-nuts could ponder the soundness of the
concept.
Apart from the delayed measurement point, I have not been able
to identify any issues.
The frequency spectrum filtered out by the averaging is waaaay to
the left of our minimum Tau.
Phase wrap-around inside bursts can be detected and unfolded
in the processing.
Am I overlooking anything ?
--
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.