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.
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.
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/
Its a little more complicated than that.
The measured ADEV depends on the associated filter bandwidth (typically
for 1Hz sampling one uses a low pass (for the phase fluctuations) filter
bandwidth of 0.5Hz or less).
When one uses a time interval counter the counter input system noise
bandwidth may be as high as 100MHz (5370A/B) or 500MHz or more (DTS2070)
whereas the crystal oscillator buffer amp (principal source of OCXO
white phase noise floor) may have a somewhat lower bandwidth. The time
interval counter method severely undersamples the phase noise spectrum
leading to aliasing effects.
Averaging of this type creates a low pass filter that will reduce the
system noise to a large extent whilst not greatly affecting the
measurement as the equivalent filter bandwidth will still be much larger
than 0.5Hz and the equivalent filter response is far from ideal.
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? A couple of days warm-up will
be enough so that the frequency drift over just 10 minutes can
be safely removed in software. JohnM -- is there a linear trend
removal option to TimeLab that works on the freq series just like
works on the time (phase) series?
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? How does the DTS input
isolation spec compare to say a TSC 51xxA?
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.
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!).
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.
/tvb
Bruce
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
