[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