Hi Kevin,
Sorry for jumping into the thread somewhat late, but I am away on a
music festival, spending my vacation working.
I think some of what I would like to point out has already been covered,
somewhat indirectly.
When you measure ADEV, white phase modulation and flicker phase
modulation both depend on the bandwidth of the input channel. This is
known already from David Allan's article in Feb 1966. One peculiarity in
there, that I discussed with him as I met him at the IFCS 2016, is that
the white phase modulation is assumed to be a block filter, and he said
that it reflects the counters that they had at that time.
Anyway, any averaging you will do will affect the white and flicker
phase modulations, but not white and flicker frequency modulations.
When you filter, you will inflict a bias in the values, but the
bandwidth is the main cause of bias for white and flicker phase
modulation. It turns out that also the frequency modulations is affected
by filtering, which comes as no surprise. This makes ADEV a tricky
business as you get biases to "true ADEV".
What is "true ADEV"? Well, ADEV is a method to estimate noise amplitudes
using counters, simply because at the time, phase noise systems simply
did not have enough frequency resolution to be useful for atomic clocks.
The definition gives the relationship between the noise level and the
ADEV value for that particular noise-type.
Any number of reasons to deviate from the ADEV values cause biases, and
this in itself is not a problem if the bias can be characterized and
compensated for, which is what the bias functions do. The pre-filtering
that MDEV does is just a tau-long phase sample average prior to the ADEV
step, and this causes a bias between the MDEV and ADEV functions,
different between the different noise-types, but the bias functions is
known. The use of bias functions is usually where most people fail.
Now, it was known in the beginning that ADEV values should always be
given with the channel bandwidth, and the assumed assumption there is
that it is a brick-wall filter as expected from time interval counters,
delivering phase samples, or possibly frequency samples which is just a
post-processing of the phase samples. The annotation of bandwidth got
lost over time, and we can assume that it is f_h=1/(2T) due to Nyquist.
Let's now consider two averaging methods, one where we average all
samples over a second and another when we use a classic one-pole
low-pass filter and sample the output. The average will have the assumed
brick-wall property, as if the counter measured at 1 s tau, but
obviously the white phase modulation noise is being averaged down and so
will flicker phase modulation noise be to some degree, which is already
in their formulas. For the low-pass filter, you will get the bandwidth
aspect, which will behave similar, but as the slope behaves, it will sum
up the noise differently as you integrate over frequency, so it will
provide a different answer, in fact, the ADEV response and hence bias
function has not been established in published work, and as I have asked
around fellow researchers, only one has made some scrap note
calculations during the PhD thesis time and David Allan knows that Fred
Walls was working on it, as they had their offices next to each other at
NBS/NIST in Boulder, but it is not known if the notes every survived.
What we do know is what was hinted before, if you produce samples at
high enough rate compared to your lowest analysis tau, then the bias
will be small enough to not be a practical matter. For telecom
measurements for instance, the highest sample tau is 1/30 of the lowest
analysis tau in order to avoid this bias. The standard is very
well-written in this regard, as it then provides a practical solution
while allowing for many different types of implementation of the
measurement, while keeping the implementation type from coloring the
result too much, as the comparability of results is important.
Another aspect of box-car averaging or any form of averaging is also
that sub-sampling can suffer from aliasing problems, and neither box-car
averaging or single-pole filters have very good anti-aliasing
properties, so higher degree filters is needed, it's just that well, we
don't have their bias functions.
A fascinating set of additional biases can be found in counters using
various averaging techniques, and then output data which may or may not
be overlapping. Not all off them can be used to produce proper ADEV or
MDEV, some may be used to produce proper values, but only if their
overlapping output is treated like overlapping for the tau they average
over and processed properly, but when not it produces biases. I see this
regularly enough in poster sessions among others. Several tools fail to
handle such overlapping output properly.
In the end "true ADEV" values is tricky business, and mostly because it
is not very well understood. I've spent much time learning to do it
properly, digging deeper and deeper and I'm not happy of the situation.
There is more research to be done, it is not only an engineering aspect
remaining, still after 50 years.
Cheers,
Magnus
On 07/31/2016 01:08 AM, Tom Van Baak wrote:
SDRs sample at high rates. The slowest the USRP N2x0 can sample is just under
200Ksps.
Hi Kevin,
I don't have an easy answer for you. BobC / BruceG / MagnusD / JohnM / EnricoR
can shed light on this. But I support your effort to figure out how to obtain
real truth from a massive oversampled data set.
If you feel uneasy that ADEV statistics might lie, see:
http://leapsecond.com/pages/adev-avg/
ADEV is always a tricky, since the measurement bandwidth is not always
specified, or how that bandwidth is implemented. Both the front-end h/w design
and any embedded s/w manipulation of raw data will distort (bias) the
statistics. Distortion itself is not a show-stopper, as long as you can
properly model it and back it out. But it seems the challenge is knowing how
valid the model is, and if model itself depends on the noise type.
/tvb
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.