[time-nuts] First success with very simple, very low cost GPSDO

WarrenS warrensjmail-one at yahoo.com
Sat Apr 12 19:09:16 UTC 2014


Interesting, Am I missing something or is there an error in your code or 

Looks to me like the code is a PI controller with a added "D" term  (Vdf) 
of input,
and the "D" is then Integrated with a scale factor of "F" at  Vi = Vi + 
F*Vdf ...
An integrated derivative is exactly equal to a P

Looks to me like the code is still just a standard PI controller where Vdp 
is the phase error;
Vi = Vi + I*Vdp
Vf = Vi + (P+F) * Vdp

This can be simplified by dropping the F scale factor and increasing the P a 

What am I missing?

One thing for sure that the code is missing is a pre-filter, which is very 
helpful because of the GPS phase noise.
Turning on the "D" term in a PID with a prefilter is mostly not recommended, 
They tend to just cancel each other.



Magnus Danielson wrote

On 10/04/14 20:28, Tom Van Baak wrote:
> I agree with Charles. Further, you don't even have to wait a predetermined 
> amount of time (this would be oscillator or environment dependent). 
> Instead simply monitor the rate of frequency change. When the drift rate 
> drops to the level where your PID is known to be able to track, then start 
> the PID.
> Realize that just 2 seconds after power-up you have your first frequency 
> measurement. By 3 seconds you have your first drift measurement. Just wait 
> until it falls to however few ppm/second or ppb/second you need for your 
> loop to smoothly track. This avoids special case PID startup or wind-up 
> code. Although you can argue it merely replaces it with special case drift 
> rate code.
> I'm suspicious of fast/slow tracking loops. If you want to vary the 
> tracking, perhaps it is best to continuously, transparently, smoothly vary 
> loop parameters according to drift rate rather than use a hardcoded 
> fast/slow algorithm binary switch. I'm sure there's deep theory on this, 
> which I have not read yet.

This is where many spend their time building a heuristics.

My favorite solution is to derive the phase detector and let the result
feed into the integrator through a scaling factor. This input to the
integrator is in parallel to the I factor input. Code-wise we get
something like this:

Vdf = Vdp - Vdp_pre
Vdp_pre = Vdp
Vi = Vi + I*Vdp + F*Vdf
Vf = Vi + P*Vdp

For far-out frequency errors, the PI PLL is weak, due to Bessel
coefficient, so the FLL dominates and the F factor steers the loop gain
of the FLL. It steers the Vi state of the integrator until it becomes
close, with an exponential decay into zero frequency error. When it
does, the Bessel coefficient becomes stronger and stronger and then PI
PLL starts to take over. When the gain of the PLL surpasses that of the
decaying FLL the PLL just takes over... by design. When the PLL has
locked the frequency, the FLL part just doesn't have gain, but adds a
little noise.

The benefit of this approach is that the frequency correction is kept in
the Vi state, and depending on the Vi state either the FLL or PLL
dominates, there is no hand-over, there is no external intelligence to
chose mode, it is always steered by the need from frequency-error
needing to be corrected and the current Vi, or if you so like, the
current Vi error.

Simple, relatively easy to analyse and completely linear regulation


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