[time-nuts] GPSDO control loops and correcting quantizationerror

[Bob Camp]

Hi

The "knee" is a basic artifact of the cross over in the noise of one (say the OCXO) to the noise of the other (say the GPS). It's one of those things you can reduce, but never eliminate completely.  The noise of the combined pair will always be slightly worse than the best of the two when they are in the cross over region. 

Bob

On Sep 16, 2012, at 2:58 PM, Tom Knox <actast at hotmail.com> wrote:

> 
> Great dialog, One thing I have seen is the Allan intercept almost always has a "knee". If you wanted the best possible GPS quartz reference developing a variable Allan intercept would allow this knee to be moved and then mathematically removed during a gated measurement. 
> Allowing to effectively see behind he knee offering lower uncertainty in this important area. 
> 
> Thomas Knox
> 
> 
> 
>> Date: Sun, 16 Sep 2012 19:20:24 +0200
>> From: magnus at rubidium.dyndns.org
>> To: time-nuts at febo.com
>> Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror
>> 
>> On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote:
>>> In message<5C52FBDBA5084AD4A36300FBA73BEF5E at pc52>, "Tom Van Baak" writes:
>>>>> Yes, timing accuracy has been my main focus and in general I have been
>>>>> using integration times on the low side of 10000 seconds for that,
>>>>> but it depends a lot on the OCXO/Rb and environment.
>>>>> 
>>>>> The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL
>>>>> for optimal time stability, and it does a surprisingly good job at it.
>>>> 
>>>> Are there papers that talk about how to optimize for best timing or best
>>>> frequency or (no free lunch) some compromise combination of the two?
>>> 
>>> The only writings I am aware of, is what Dave Mills has written and
>>> the PLL code in NTPns, but I havn't followed this closely in the last
>>> 10 years, so do check for newer writings.
>>> 
>>> Dave Mills coined the term "allan intercept" as the cross over of
>>> the two sources allan variances and it's a good google search for
>>> his relevant papers.
>>> 
>>> I'm not entirely sure his rule of thumb for regulating to that point
>>> is mathematically sound&  precise, but the concept itself is certainly
>>> valid, even if you have to compensate for the timeconstant of the
>>> PLL you use to regulate to that point.
>> 
>> Well, what is being used is phase-noise intercept. Conceptually a 
>> similar intercept point will be available in Allan variance. However, as 
>> you shift between noise-variants, the Allan (and Modified Allan) 
>> variance has different scaling factor to the underlying phase noise 
>> amplitudes. The danger of using the Allan variance variant is that you 
>> get a bias in position compared to the phase-noise plots cross-overs.
>> However, the concept is essentially the same, and the relative slopes is 
>> the same. You get in the right neighbourhood thought.
>> 
>> The concept has been in use in the phasenoise world of things, so you 
>> would need to search the phase-noise articles to find the real source. 
>> It's been used to generate stable high-frequency signals.
>> 
>> The analysis of PLL based splicing of ADEV curves is tricky, and I have 
>> not seen any good comprehensive analysis even if the general concept is 
>> roughly understood. The equivalent on phase-noise is however well 
>> understood and leaves no magic too it.
>> 
>>> I spent a lot of time with the code in NTPns, to try to get that PLL
>>> to converge on the optimum, and while generally good, it's not perfect.
>>> 
>>> The basic problem is that the data you have available for autotuning,
>>> is the allan variance between your input and your steered source.
>> 
>> You need to treat the data as loose and tight PLL measure, depending on 
>> what you look for. There is loads of calibration issues, covered in 
>> literature.
>> 
>>> If you also have the allan variance between the steered source and
>>> a 3rd, better, source, the task is pretty trivial:  Minimize the
>>> area below that curve.
>>> 
>>> But if you do that on the curve you have, you don't optimize, you
>>> pessimize, since the lowest area, is with a timeconstant of zero.
>>> 
>>> Going the other direction and maximizing the area is no good either
>>> and trying to balance the area around some pivot related to the
>>> present PLL timeconstant does not converge in my experience.
>>> 
>>> What I did instead was to (badly) reinvent Shewarts ideas for testing
>>> if the phase residual is under "statistical process control":
>>> 
>>> I increase the timeconstant if the phase residual has too frequent
>>> zero-crossings and loosen it if they happen too seldom.
>>> 
>>> Having read a lot more about statistical process control, since I
>>> built those NTP servers for the Air Traffic Control 10 years ago,
>>> I would leverage more of the theory and heuristics developed in
>>> process control. (3sigma violations, length of monotonic direction
>>> etc. etc.)
>>> 
>> 
>> It's a complex field, and things like temperature dependencies helps to 
>> confuse you.
>> 
>> 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.
> 		 	   		  
> _______________________________________________
> 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.