[time-nuts] GPSDO control loops and correcting quantizationerror

Bob Camp lists at rtty.us
Sun Sep 16 17:48:54 UTC 2012


Hi

By far the most common approach to optimizing these is the "measure it and see" approach. 

1) measure the noise out of the GPS ( must be done no matter what)
2) measurer the noise of the specific OCXO (again must be done)
3) *guess* at a cross over
4) try it and measure the result.
5) step and repeat 3 and 4 until exhaustion sets in

Indeed converting the data to phase noise rather than ADEV helps the guess process. You can go a bit crazy with math to get a better first guess. Unless you measure what you get, you won't find all the silly little things you forgot to put into your math model. 
If you simply try a dynamic tune approach, you never really get to an optimum point. You need a "better than" reference to let you know where you are. You can keep pushing out the time constant and watching with just a GPS and OCXO, but you never really know when to stop. 

Bob

On Sep 16, 2012, at 11:47 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> 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.
> 
> 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.
> 
> 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.)
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
> 
> _______________________________________________
> 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_lists.febo.com mailing list