On Jul 29, 2016, at 6:51 PM, Bob Camp kb8tq@n1k.org wrote:

HI

Keep in mind that if you apply pre-filtering, an ADEV plot is lying to you ….

Bob

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.

On Jul 29, 2016, at 11:44 PM, Kevin Rosenberg kevin@rosenberg.net wrote:

Hi Bob,

You have a good point. That leads to the question is what is the “best” measurement technique when you are sampling at a more smaller interval than the desired tau?

SDRs sample at high rates. The slowest the USRP N2x0 can sample is just under 200Ksps. For easy math, let’s assume we sample at 1Msps but we want to record only 1sps for a long-term measurement. What’s best way to handle the 1e6 to 1 ratio of available samples to desired samples? One method is to discard 999,999 samples and just record the phase difference with a true tau of 1 sec. The other is to take a window of 1e6 samples and output the average phase difference over that 1 second window. Is your point that averaging samples that are more frequent than the tau will overestimate stability at the tau? If using averaged data, would it be “less lying” to multiply the ADEV by the sqrt of the length of the averaging window?

I’d appreciate your thoughts on the subject,

Kevin

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.

On Jul 29, 2016, at 9:44 PM, Kevin Rosenberg kevin@rosenberg.net wrote:

Hi Bob,

You have a good point. That leads to the question is what is the “best” measurement technique when you are sampling at a more smaller interval than the desired tau?

SDRs sample at high rates. The slowest the USRP N2x0 can sample is just under 200Ksps. For easy math, let’s assume we sample at 1Msps but we want to record only 1sps for a long-term measurement. What’s best way to handle the 1e6 to 1 ratio of available samples to desired samples? One method is to discard 999,999 samples and just record the phase difference with a true tau of 1 sec. The other is to take a window of 1e6 samples and output the average phase difference over that 1 second window. Is your point that averaging samples that are more frequent than the tau will overestimate stability at the tau? If using averaged data, would it be “less lying” to multiply the ADEV by the sqrt of the length of the averaging window?

I’d appreciate your thoughts on the subject,

Kevin

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.

On Jul 30, 2016, at 12:04 PM, Kevin Rosenberg kevin@rosenberg.net wrote:

Hmm, I might have answered my own question: filter to the fast samples to the equivalent noise bandwidth (ENBW) of the lower desired sampling rate and then decimate.

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.

On Jul 30, 2016, at 5:08 PM, Tom Van Baak tvb@LeapSecond.com wrote:

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.

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.

On Jul 31, 2016, at 10:41 PM, Magnus Danielson magnus@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:

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.