[time-nuts] Re: GPSDO Control loop autotuning

Pluess, Tobias tpluess at ieee.org
Sun Mar 20 20:46:30 UTC 2022


Hi Bob,

I see your point on quickly moving the OCXO. However of course this is NOT
what I do. To be precise, my GPSDO does this exactly once after powerup, to
quickly align the PPS. After that, the control loop takes over and steers
the OCXO according to the error signal.
I also have already implemented the algorithm that switches the control
parameter sets: just after powerup, a "quick" set is used, that quickly
brings the OCXO to the right frequency but also lets the DAC work quite
hard. If the time error stays below 100 ns for a couple minutes, an
"intermediate" control set is used with longer loop time constants. If the
time error stays below 100 ns for a couple minutes, the "slow" control set
is used which, currently, has a loop time constant of one hour. The DAC
ouput changes very rarely, about one count up or down every couple minutes.
What I wanted to achieve with this autotuning is to find out whether 1 hour
is a good time constant. Should it be longer? shorter? what would be the
best value?

Since the GPSDO already has a TIC built in, that measures the time interval
between the two PPS, I thought it must be, somehow, possible to assess the
current performance of the GPSDO. Lets say by estimating the ADEV. Based on
that value, it should then be possible to adapt the loop time constant,
until some sort of optimum is found. No?

Best
Tobias
HB9FSX


On Sun., 20 Mar. 2022, 20:03 Bob kb8tq, <kb8tq at n1k.org> wrote:

> Hi
>
> If you want “best” jitter compared to the GPS PPS, put in a very wide
> band loop and move the OCXO very quickly to match the PPS. That
> will give you best performance by that measure. If you go to every
> tenth sample, the same process will occur, just at a slightly different
> point.
>
> Since the purpose of the loop is to *attenuate* the jitter passed from
> the GPS PPS to the OCXO, this sort of tuning is normally counter
> productive.
>
> The best way to work out the constants is to measure the noise on the
> GPSDO output. Then select sets of loop constants that give reasonable
> performance at various time constants.
>
> With an ideal OCXO, the longest time constant would pretty much always
> be best. If we had zero drift / zero aging “ideal” OCXO’s there would
> be less demand for GPSDO’s :)
>
> With a real (as opposed to ideal) OCXO, a long time constant will have
> it wandering all over the place. The DAC will be cycling like crazy as a
> result. This stuff is what most constant switching algorithms focus
> on. Not quite the same as auto tune since the constants have already
> been worked out and you are simply switching from set A to set B.
>
> Bob
>
> > On Mar 20, 2022, at 1:58 PM, Pluess, Tobias via time-nuts <
> time-nuts at lists.febo.com> wrote:
> >
> > Hi all,
> >
> > I am still working on my GPSDO also now with added NTP time server. This
> > one is still work in progress, though.
> > In the meantime I found another interesting problem. Currently, my GPSDO
> > uses a PI controller to steer the DAC voltage of the OCXO. This proved to
> > work very well. (see my source code at https://github.com/tcpluess/gpsdo
> ).
> > Currently, I use manually determined KP and KI constants for the control
> > loop. I can adjust them via serial port, of course.
> > I am thinking about whether it would be possible to implement some sort
> of
> > autotuning to this controller to find the "best" set of control
> > parametersthat give the least jitter.
> >
> > How could I do this?
> >
> > one idea is the following:
> > since I have a TIC that measures the time interval between the GPS-PPS
> and
> > the OCXO-derived PPS, I could collect, for example, the last 1000 samples
> > of this time interval and calculate the 1sec, 10sec, 100sec and 1000sec
> > averages of this time interval. If the control loop operates "well", the
> > time intervall should become 10 times smaller when the averaging time is
> 10
> > times increased. On the other hand, if the control loop is too slow and
> the
> > OCXO is drifting, this assumption will not hold. In the first case, we
> can
> > increase the integration time for the control loop (make the loop time
> > constant larger), in the second case we have to decrease the integration
> > time (make the control loop faster).
> > I wouldn't run this autotuning all the time, just maybe once to determine
> > the optimal loop parameters. However the averaged time interval samples
> > probably provide some interesting info....
> > Is there a way to estimate the ADEV on-the-run without having to collect
> > millions of samples?
> > I have enough RAM left on my microcontroller to collect maybe 1000, or
> > probably even 2000 samples. It would be interesting to do something with
> > this info.
> >
> >
> > best
> > Tobias
> > HB9FSX
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
> send an email to time-nuts-leave at lists.febo.com
> > To unsubscribe, go to and follow the instructions there.
>
>




More information about the Time-nuts_lists.febo.com mailing list