[time-nuts] Commercial software defined radio for clockmetrology

[Magnus Danielson]

Hi Kevin,

The problem that some of what I described is dispersed over so many 
papers with small snippets of information here and there. I tried to 
cover some of it on the Wikipedia article for Allan Deviation, but I 
don't know how much remains after numerous of other edits. I'm sure it 
can be improved.

I tried to give you an intuitive feeling of what the math do for you, 
but the theory is quite boring.

Anyway, don't hesitate to ask questions!

Cheers,
Magnus

On 08/11/2016 02:54 AM, Kevin Rosenberg wrote:
> Hi Mangus,
>
> No apologies necessary. Your music festival sounds more like it was more fun than the process review and implementation direction conference that I just returned from!
>
> It is very kind of you to share your detailed knowledge on this subject. It is extremely relevant to what I am working on and is a great resource.
>
> Much appreciated!
>
> Kevin
>
>> On Jul 31, 2016, at 10:41 PM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>>
>> 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.
>>>
>> _______________________________________________
>> 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.
>