[time-nuts] Modified Allan Deviation and counter averaging

Magnus Danielson magnus at rubidium.dyndns.org
Fri Jul 31 06:45:08 UTC 2015


Hi James,

On 07/30/2015 06:34 PM, James Peroulas wrote:
> My understanding is that MVAR(m*tau0) is equivalent to filtering the phase
> samples x(n) by averaging m samples to produce x'(n)
> [x'(n)=1/m*(x(n)+x(n+1)..x(n+m-1))] and then calculating AVAR for
> tau=m*tau0 on the filtered sequence. Thus, MVAR already performs an
> averaging/ lowpass filtering operation. Adding another averaging filter
> prior to calculating MVAR would seem to be defining a new type of stability
> measurement.

Yes, fhat's how MVAR works.

> Not familiar with the 5370... Is it possible to configure it to average
> measurements over the complete tau0 interval with no dead time between
> measurements? Assuming the 5370 can average 100 evenly spaced measurements
> within the measurement interval (1s?), calculating MVAR on the captured
> sequence would produce MVAR(m*.01)) for m being a multiple of 100. i.e.,
> tau0 here is actually .01, not 1, but values for MVAR(tau) for tau's less
> than 1s are not available.

The stock 5370 isn't a great tool for this. The accelerator board that 
replaces the CPU and allows for us to add algorithms, makes the counter 
hardware much more adapted for this setup.

> Shouldn't the quantization/ measurement noise power be easy to measure?
> Can't it just be subtracted from the MVAR plot? I've done this with AVAR in
> the past to produce 'seemingly' meaningful results (i.e. I'm not an expert).

You can curve-fit an estimation of that noise and "remove" it from the 
plot. For lower taus the confidence intervals will suffer in practice.

> I calculated the PSD of x(n) and it was clear where the measurements were
> being limited by noise (flat section at higher frequencies). From this I
> was able to estimate the measurement noise power.

It is. Notice that some of it is noise and some is noise-like 
systematics from the quantization.

> AVAR_MEASURED(tau)=AVAR_CUT(tau)+AVAR_REF(tau)+AVAR_MEAS(tau)
>
> i.e. The measured AVAR is equal to the sum of the AVAR of the clock under
> test (CUT), the AVAR of the reference clock, and the AVAR of the
> measurement noise. If the reference clock is much better than the CUT
> AVAR_REF(tau) can be ignored. AVAR_MEAS(tau) is known from the PSD of x(n)
> and can be subtracted from AVAR_MEASURED(tau) to produce a better estimate
> of AVAR_CUT(tau).
>
> Depending on the confidence intervals of AVAR_MEASURED(tau) and the noise
> power estimate, you can get varying degrees of cancellation. 10dB of
> improvement seemed quite easy to obtain.

Using the Lambda counter approach, filtering with the average blocks of 
Modified Allan Variance, makes the white phase noise slope go 1/tau^3 
rather than 1/tau^2 as it is for normal Allan Variance. This means that 
the limiting slope of the white noise will cut over to the actual noise 
for lower tau. so that is an important tool already there. Also, it 
achieves it with known properties in confidence intervals. Using the 
Omega counter approach, you can get further improvements by about 1.25 
dB, which is then deemed optimal as the Omega counter method is a linear 
regression / least square method for estimating the frequency samples 
and then those is used for AVAR processing.

The next trick to pull is to do cross correlation of two independent 
channels, so that their noise does not correlate. This can help for some 
of it, but systematics can become a limiting factor.

Cheers,
Magnus

>
> James
>
>
> Message: 7
>> Date: Tue, 28 Jul 2015 21:51:07 +0000
>> From: Poul-Henning Kamp <phk at phk.freebsd.dk>
>> To: time-nuts at febo.com
>> Subject: [time-nuts] Modified Allan Deviation and counter averaging
>> Message-ID: <2884.1438120267 at critter.freebsd.dk>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> 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 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



More information about the Time-nuts_lists.febo.com mailing list