[time-nuts] ADEV

[Bob Camp]

Hi

I don't see anybody arguing that systems work better when there's a high ADEV than a low ADEV. Most of the papers are heading in the direction of "it doesn't catch all of the problems I worry about". Based on what systems need and what ADEV measures, I don't find that a particularly surprising conclusion. The next step would be for people to come up with system related measures that do catch what they are after. Some have tried that, many have not. The next link in the chain would be getting (paying) vendors to run the tests on product. As far as I can tell - that's not happening at all. ADEV had the same issues early on. Until it became a mandatory specification, not a lot of people paid much attention to it. 

Bob

On Nov 13, 2010, at 10:18 AM, jimlux wrote:

> Magnus Danielson wrote:
>> Hi Bob,
> <snip>
> 
>> I think the system applications for short-term stability measurements was quite clear, and was brought out specifically. 
> 
> Basically, these are all systems where there is some "storage" or "delay" and you are comparing a signal generated/recorded at some time t with that signal at some time t+delta, where delta is in the seconds to minutes range.  (well, milliseconds in the radar case)...
> 
> (the really slow speed comm application is slightly different.. there, it's more of a reciprocal mixing of close in noise and a frequency stability in the hours/days sense issue.. although for one-way doppler measurements ADEV is important)
> 
>> ADEV addresses the oscillator noise issues, but isn't particularly well suited for the numerous of systematic effects that comes on top of the oscillator noise in the system.
> 
> yes. but some familiarity with how ADEV is measured/computed, and the fact that there are "test sets" out there that make a plot of ADEV means that you can look at a ADEV plot for the system, and if it deviates from that for the underlying oscillators, you can make some educated guesses about the system issues.  Not that it's best, by any means, but at least it exists.
> 
> When buying or building a complex system, one is often faced with the problem of "how do we write a testable specification or requirement" to show that the completed widget works.  And, further, you generally don't want to spend more developing the test than the thing you are buying. It does happen, though..probably part of the game for developing at the ragged edge of performance.  However, if you can sort of back your way into an analysis that shows that a performance of X on test Y (no matter how unsuited philosophicaly) means that you will get performance Z on important requirement Q, then all is good.
> 
> At work, we refer to the developing of a whole subproject to understand and test how the primary object is working as "doing a science project".. but that's because I work in an "engineering" area as opposed to one of the "science" areas, where science projects are their lives. By the time we get it, we're on a schedule and budget that doesn't allow for much contemplation, reflection, and thinking about how to best do things: planetary motion waits for no man, and the launch period is a few weeks long, at best.
> 
> 
> 
> 
> _______________________________________________
> 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.