[time-nuts] Measuring short term stability minus linear drift

[Magnus Danielson]

On 08/10/11 17:16, Jim Lux wrote:
> On 10/8/11 7:56 AM, Magnus Danielson wrote:
>> On 08/10/11 16:45, Jim Lux wrote:
>>> On 10/7/11 9:32 PM, Rick Karlquist wrote:
>>>> I want to measure the short term stability of a source
>>>> with substantial linear drift. I would like some measure
>>>> of stability along the lines of Allan deviation, but I
>>>> only want to measure the "noise" and ignore the "drift".
>>>> AFAIK, ADEV treats linear drift like a form of noise.
>>>> Has this problem been solved before?
>>>> Any ideas?
>>>>
>>>
>>> what if you (least squares?) fit a straight line to the frequency
>>> measurement data, remove that, then look at ADEV? We do something
>>> similar with testing deep space transponders which will be handling a
>>> signal with varying Doppler so our test signal is varying in frequency.
>>
>> This is what a simple fit does or HDEV does. The benefit of higher
>> degrees fit is that it would cause better fits and high tau ADEV values
>> will be less poluted by the weaker terms.
>>
>> For first degree effect, swap between ADEV and HDEV.
>> For second degree effect, use quadratic fit and ADEV that.
>>
>> You still want to know the systematic behaviour and how those systematic
>> effects behave, but it would be fairly ridicolous to teach you Rick on
>> the merits of that.
>>
>
> Yeah, but it's always nice to know how other people do it and if someone
> has published something somewhere with more analysis.

I do it when I care about it. HDEV gives me the quick view I need as the 
first degree effect dominates typically. However, I often find that 
environmental aspects kick in and I still lack a good tool to combat them.

> I find that at JPL (and I assume others have found this too) that we'll
> go off and reinvent the wheel (maybe because we're working in parallel
> ignorance) for something. And a lot of times, especially if it's in
> service of a "get the hardware tested and delivered" the analytical
> backup for whatever we did may not be as rigorous as one might like.

That would not put you in a very unique position.

> There's also the classic gap between the groups doing theoretical work
> in one building and groups building and testing hardware in another
> building 1000 meters away, and the two groups never have time to meet,
> and in some cases, may not even be aware of the other's existence. This
> is especially true when you're talking about early career hires (aka
> fresh-outs). These days, with tight budgets, you may not be able to put
> two people on a job (one senior, one junior) which would provides some
> of that knowledge transfer. (to be honest, I don't know that it's much
> worse than it ever was.. tight budgets are a perennial complaint since
> they were building pyramids in Egypt)

You do not need to have the senior sitting with each junior engineer, 
but available at need, down the hall, meet over coffie-breaks. Creating 
the environment that asking stupid questions is better than asking no 
questions, and once the stupid questions are out the more initiated come 
along... that how we do it and by raising the level of others, they stop 
pestering me with stupid stuff, we get much higher level questions and 
fewer trouble reports but of higher quality.

Cheers,
Magnus