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, <kb...@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@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@lists.febo.com -- To unsubscribe > send an email to time-nuts-le...@lists.febo.com > > To unsubscribe, go to and follow the instructions there. > > _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
