[time-nuts] Changing ADEV, (was Phase, One edge or two?)

Bob Camp kb8tq at n1k.org
Sat Oct 25 14:15:08 EDT 2014

> On Oct 25, 2014, at 12:19 PM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
> Bob,
> On 10/25/2014 02:02 PM, Bob Camp wrote:
>>> On Oct 24, 2014, at 6:25 PM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>>> Tom,
>>> On 10/24/2014 11:31 PM, Tom Van Baak wrote:
>>>>>> ADEV most certainly does change with time, even for short tau's.
>>>>> Can you elaborate?
>>>>> Such as when, why, what kind of change, how much change,
>>>>> at how short of tau's, over how long of time,
>>>>> and using what type Oscillators?
>>>>> Do you know what in the freq or Phase plot is causing the ADEV to change?
>>>> I'm happy to let Bob answer his own claim here. I'm curious as well. Unless he's talking about thermal noise, in which case I now believe him 100%.
>>>> OTOH, for time intervals of minutes to hours or days, the plotted ADEV can often vary. When in doubt, enable error bars in your ADEV calculations or use DAVAR in Stable32, or use "Trace History" of TmeLab to expose how little or much the computed ADEV depends on tau and N.
>>>> In general, never do an ADEV calculation without visually checking the phase or frequency time series first.
>>> You should make sure that you remove all forms of systematic effects before turning the residue random noise over to ADEV.
>>> If you have random noise being modulated in amplitude, you need to measure long enough for the averaging end not to have a great impact on the result.
>> Is days long enough for a 1 second tau? If you define 1,000 x tau as “long enough” you are being way more
>> conservative than just about anybody out there. My claim is that rather than telling everybody to run for 10,000 or
>> 100,000 x tau, simply accept that ADEV does / may change.
> I did not say that you need to do 1000xtau, that was what someone else said. If you paid attention I said that the number of samples N and the tau0-multiple m for a particular dominant noise (of that tau) creates a certain degree of freedom for a particular ADEV estimator algorithm. Discussing the length of the measure without discussing which estimator algorithm you're using and what confidence interval you aim to reach is just taking a single value and run with it without thinking about it.
> For ITU-T telecom standards, the measurement length is 12 times the maximum tau, using the overlapping estimator (see O.172, §10.5.1 for limit and G.810 §II.3 for TDEV algorithm). That was chosen to ensure comparability between different implementations for the same type of measure. See O.172 for other relevant details on limits for implementation, tau0 has an upper limit, so does bandwidth. Naturally, these limits is for this specific purpose, algorithms etc. which may not fit the needs of other needs or choices.

If you are using under 100 samples for the test (overlapping or not), your confidence is not as high as it might be. You can see ADEV “drift in” over a period of days, even with a lot more than 10 samples. 

> It's only when you do old style non-overlapping that you need to go towards 1000*tau for some reasonable results.
>> Removing this or that *before* you do ADEV can get you on a very slippery slope indeed. Removing drift (either time
>> or frequency) - fine.  Removing this or that couple of minutes of data because it makes the 
> result look better, that’s
>> likely to get you in trouble. Your customer (or system, or test setup) isn’t likely to accept a “ADEV is ok most of
>> the time” specification.
> Agreed. But I've never advocated cutting away samples like that, but rather cancel out the systematics which is not part of the random noise.
>> Is ADEV a good way to measure temperature stability - no of course not.  We do indeed have rooms that vary in
>> temperature. They do impact ADEV on a Rb. Removing the delta temperature related data from your ADEV input is not at
>> all easy (1,000 to 10,000 second data …) and I believe it would mis-represent the part. Running in the real world,
>> it’s going to have that ADEV hump.
> ADEV hump for such systematic is maybe an indication, but not the best way of represent that. It's also not part of the ADEV intended purpose, namely to estimate the random noise effects.
>> Yes indeed you can find FCS papers with all sorts of interesting “adjustments” or no processing at all. The consensus
>> seems to be that if you go past drift correction, you really should have a footnote.
> When you do not make a drift compensation, and that line shows up, you better explain that too.
> In the end, ADEV is overused to represent things for which it is not a good tool. You will need other tools in the tool-box to build a good estimation of how that oscillator will behave at some tau.

Except that ADEV is used by many as an acceptance test on systems and oscillators. Saying it’s OK to pull data out of a test run makes for a very interesting test design. We certainly use ADEV (without subtractions) here on the list to compare things like GPSDO’s at the system level.


> Cheers,
> Magnus
> _______________________________________________
> 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