[time-nuts] Averaging effects

[John Miles]

> > What GPIB data rate did you actually get for the 10 kHz trace?
> > When JohnM ran the same test on my 2070C it was closer to
> > 0.74 s instead of 1.0 s. I'm wondering if you found a way to
> > get your DTS pacing more accurately.

Note that Magnus is running a very different test -- I was selecting 10K
averages with 10 MHz on both inputs and letting the counter's ~0.7-sec
processing overhead determine the tau0 interval, whereas he is feeding a
lower rate to the START channel so that the counter will average samples
taken at regular intervals within the tau0 period.

There appears to be no way to get the counter to average a burst of
successive samples between arming intervals, which is really what you want.

> > JohnM -- is there a linear trend
> > removal option to TimeLab that works on the freq series just like
> > works on the time (phase) series?
>
> Should be there.

Indirectly.  If you want to flatten the frequency trace, you can remove the
quadratic trend from the phase trace with ctrl-q.

> >> A peculiar effect is that to make good readings for low-tau values I
> >> need to trim the oscillators to be very near each other. Otherwise
> >> there will be a polution of the lower taus compared to my selected
> >> good plots. This polution and the slope is insensitive to any drift
> >> rate compensation, so Hadamard analysis does not help.

This is likely caused by phase wrapping, which is incompatible with
averaging.  The counter can't average readings like 96 97 98 99 ... 01 02 ns
and come out with anything meaningful.  You'll have to use sample size=1 if
your sources are likely to phase-wrap during the measurement.

-- john, KE5FX