[time-nuts] Modified Allan Deviation and counter averaging

[John Miles]

> 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