Matthias,
On 08/20/2015 09:55 PM, Matthias Jelen wrote:
Dear John & Magnus,
thank you very much for your detailed explanation. I realize that the
averaging topic is much more complex than I thought - it certainly gives
me something to think about :-) I never thought in terms of noise
bandwith in this application, thanks for putting me on this track.
You are welcome. Your question was a good opportunity to explain.
It seems that the simplest and safest way to get meaningfull results is
to hook up two mixers and a hand full of opamps and comparators.
Which isn't that easy. You will reduce the slew-rate of your signal in
the mix-down process, and that converts white noise into white phase
noise, which reduces the benefit of the lower frequency achieves. To
overcome this you need to gain yourself out of the situation. That
works, but it is a bit messy than just tossing in a mixer or two.
To learn more, I think the best way would be to put the counter into its
fast binary mode and acquire 1k time interval samples per second. That
would give me loads of data to play with and it would be easy to try out
how different averaging schemes affect the result.
This is actually a very good idea.
Won't do much for ADEV other than confidence intervals, but is good for
MDEV in lowering the front-end noise to be able to measure things.
I´ll have to read and think some more :-)
Experiment, analyze, test theories etc. is how we all learn. :)
Cheers,
Magnus
Cheers,
Matthias
Am 19.08.2015 um 21:52 schrieb Magnus Danielson:
Dear Mathias,
On 08/19/2015 06:40 PM, Matthias Jelen wrote:
Hello,
I´ve got a question concerning ADEV-measurements.
I´m measuring the 15 MHz output of a KS-24361 with my SR-620 with it´s
internal (Wenzel) OCXO using Timelab. For the first shot I used the
counters frequency mode with 1s gatetime. ADEV at tau=1s turned out to
be arounf 2E-11, which fits the 20 ps single shot resolution of the
SR-620 nicely.
To overcome this limitation without setting up a DMTD system, I used the
counter as TIC, feeding 1 kHz (derived from the counter´s reference) to
the start channel, the 15 MHz to the stop channel and put the counter
into average mode / 1k samples. This gives me one averaged result per
second.
The idea was that this shouldn´t change the measurement itself, because
like in frequency mode with 1s gate time I get the averaged value over
one second, but I expected trigger noise etc. to be averaged out to a
certain amount. I have to watch out for phase wraps, but as the two
frequencys are quite equal, this is not a big issue here.
As expected, ADEV at tau=1s got much better, it is now in the 4E-12
area, which sound reasonable.
What makes me wonder is the fact that result are significantly better
now at longer taus (10..100s) also, despite of the fact that also in
frequency mode these result were well aboce the noise floor (2E-12 @ 10s
and so on...).
So, is it a good idea to use this kind of averaging, or am I overlooking
something which turns the numbers better than they really are? I´m
pretty sure I am not the first one to try this...
I´m looking forward to your comments.
OK, averaging or filtering of data before ADEV processing is tricky,
as it filters the data. Whenever you do that, you actually convert
your measurement from an ADEV measure to something else. If you do
proper post-processing, this something else can have known properties
and thus we can relate the amplitude of the curve to amplitude of
various noise sources, as it will cause biasing from the ADEV properties.
The reason you get better results is because the ADEV response on
white noise depends on the measurement system bandwidth (see Allan
deviation wikipedia page), and by averaging you do reduce the bandwidth.
Sometimes when you do this, you loose the gain as you increase the
tau, since the dominant frequency will lower and become more and more
into the pass-band of the fixed bandwidth filter you created. What you
see is that it flattens out to the length of the average before
lowering down, as if there was no filtering, so you have only achieved
a gain in skewed value for very short taus, but then no gain at all
for longer taus, so no real gain.
This was realized in 1980-1981 and in 1981 an article was published in
which they realized that they can change the bandwidth along-side the
change of tau, so that the gain remains. This became the modified
Allan deviation (MDEV), and was inspired by the methods for improving
frequency measures for lasers as presented by J.J. Snyder in 1980 and
1981. J.J. Snyder was doing what you proposes, averaging of blocks,
and then extended this in software, and this became a direct
inspiration for the MDEV development, which does a pre-averaging over
tau before processing through ADEV, and this combined is the MDEV.
Doing TIC averaging and then continue the processing with MDEV
processing should produce a proper MDEV curve, unless my tired brain
does not miss out on details. If you then analyze it as a MDEV (rather
than ADEV) then you use the values properly. MDEV have the benefit
that white phase noise drops by tau^-1.5 rather than the ADEV tau^-1,
and starting with the SR-620 means you for fairly low taus hit actual
measurement noise. The averaging makes this trip from tau0 of 1 ms in
your setup.
So, you can go down this route, but you need to be careful to ensure
that you have done the processing correctly enough that you get the
results that can be interpreted properly.
Oh, as you average, phase-unwrapping becomes "interesting". :)
Cheers,
Magnus
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
