[time-nuts] Averaging effects

[Magnus Danielson]

On 12/28/2010 01:37 AM, John Miles wrote:
>
>>> 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.

Actually, I ended up feeding a 10 kHz signal into the ARM1 input and 
then let the 5 MHz sines hit the Ch1 and Ch2 inputs.

The 5 MHz + 7 dBm sine signal has a limited slew-rate, so this puts some 
extra stress on the inputs compared to a slew-rate optimized signal. 
However, all the involved counters gets the same signal.

> 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.

Instead of arming measurement blocks (which the HP5372A can) you arm 
each individual measurement. For this to be really useful you need an 
arming controller.

The DTS 2070C can do 15000 samples per second. This is comparable to the 
HP5372A, but in the high performance mode the HP5372A can do 
measurements only 75 ns away while normal performance take 100 ns. The 
time-saving done is about avoiding storing away the upper part of 
counters into the 8192 long event memory.

>>> 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.

Hmm. True. My reasoning to trim the oscillators close was to avoid phase 
wrapping.

If I only could get the TS-105A to output data on the serial port as I 
would expect it to do, it would be nice to be able to use that one as a 
TimeLab source too. :)

Cheers,
Magnus