[time-nuts] Commercial software defined radio for clockmetrology

Magnus Danielson magnus at rubidium.dyndns.org
Mon Aug 1 00:41:14 EDT 2016


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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>


More information about the time-nuts mailing list