[time-nuts] Averaging effects

[Magnus Danielson]

Hi Tom,

On 12/27/2010 06:29 PM, Tom Van Baak wrote:
>> I've used various arming rates to the DTS-2070C from 1 Hz to 10 kHz
>> and also varied the averaging block size accordingly such that I will
>> get one reading every second.
>
> That's a very nice plot; textbook perfect. Thanks for posting it.

Thanks. It took some time. However, the drift rate limit would converge 
better if I bothered to make longer measurements. THAT would be text-book.

It is still kind of a mash-up. I consider the rigging a quick-and-dirty 
setup which just asks for improvements. It will just have to do for now.

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

I haven't made very qualitative measures on the actual data-rate. I've 
been kind of lazy on that aspect. However, while I do know that this 
dead-time creates biases the averaging effect would be greater and 
anyway be illustrated so I thought that I could move the data rate issue 
somewhat out of the focus for a while. It is interesting when I want to 
make qualitative measures.

Operating with bursts to create a breathing pause for the CPU to do the 
processing will avoid the dead-time. For lower rates this will not be an 
issue.

>> There is a downside to this approach which should be understood, it
>> will also averaging out the white noise of the DUTs.
>
> Correct. A similar white noise effect can happen if you average
> the raw data itself. See the plot at the bottom of:
> http://www.leapsecond.com/pages/adev-avg/

I've done block-averaging on the raw-data.

>> The V-shape of the curves comes from the white-noise limit slope (low
>> taus) and the drift-rate limit (high taus). I have not performed any
>> drift rate compensation and the OSA 8600 has only been heated a few
>> days, so the drift is still a bit high.
>
> Did they flatten out with HDEV?

Yes, but it only handles the first degree effect, but since the drift is 
not a linear frequency ramp, the remaining effect will break through 
HDEV eventually.

Also, the quadratic fit which John has in there will suffer the same 
issue. If the drift is a bad fit for second degree phase curve, then it 
will eat through eventually.

> A couple of days warm-up will be enough so that the frequency drift
> over just 10 minutes can be safely removed in software.

Indeed. I quite intentionally did not remove the drift in this case. 
Since I kept the raw and un-processed datafiles I can go back and try 
different compensation approaches, but for this case it was not my 
intention to show the effect of various drift compensation methods but 
to show the effect of averaging, so I left it out.

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

>> 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.
>
> Have you tried better isolation between the two BVA and
> the DTS to make sure it isn't that?

Haven't checked.

> How does the DTS input
> isolation spec compare to say a TSC 51xxA?

Haven't checked.

Lack of isolation could lead to injection locking, which would affect 
the results, but the effect of that would be a gain of 3 dB and be 
better for close-in noise, however this is below the signal levels I've 
measured here. The averging effects is much more significant.

>> I have not been able to pin-point how this frequency offset effect
>> really works with ADEV, but currently I suspect it has something to do
>> with quantization and averaging... but I haven't had time to verify that.
>
> Yes, this sounds plausible. I suspect the DTS2070 (or HP5370
> or SR620) will give better looking (though not necessarily more
> truthful) results if you hit the very same interpolator bin on every
> sample. I can send you examples of this.

Please do. I'm about to run the same setup on SR620 and CNT90. I've 
already done some other counters.

> Do you think this might be happening in your case? If so
> you might be able to make it even more visible if you use
> one of the BVA as the ext ref to the DTS. Or use the same
> BVA for both inputs (or all three inputs!).

I could do some experiments like that.

> Some cheaper counters avoid this effect with clock dithering.
> Or you essentially get dithering for free with any lesser grade
> DUT. But in this experiment you're using two BVA and a DTS
> so there is almost no noise to begin with. I would think this is
> very test setup you would use for exposing an interpolator
> in-a-rut effect if that is what you were trying to do.

It was not my main task, but I can get some nice runs if I want to. I 
have about 14,5 ps RMS jitter due to the 5 MHz sine signals hits the DTS 
inputs without slew-rate shaping.

I'll do some more burst averaging experiments with the HP5372A.

Using John Miles TimeLab helps me a lot. I think he is well aware of my 
usage with the run of emails passing between us. Today I found two 
undocumented keys for instance. His support is very valuable.

Cheers,
Magnus