Re: [time-nuts] First success with very simple, very low cost GPSDO
Magnus
Interesting, Am I missing something or is there an error in your code or
logic.
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
little
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.
ws
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 + IVdp + FVdf
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
mechanisms.
Cheers,
Magnus
Warren,
On 12/04/14 21:09, WarrenS wrote:
Magnus
Interesting, Am I missing something or is there an error in your code or
logic.
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
I may appear so, but the derivate, scale-factor F and integrate does not
make the scale-factor F equalent to P, since you are forgetting that the
derivate removes the DC term and the integration forms it's own DC term.
This DC-term as scaled through oscillator gain and added to the
oscillators offset is then subtracted from the reference frequency and
thus the error frequency is input to the integrator stage.
The FLL variant model can be understood if the differentiation is pushed
to both inputs of the phase comparator, where the reference frequency
and oscillators frequency will be subtracted rather than their phase and
the only remaining integrator in the loop is that holding the Vi term.
The frequency error term will exponentially decay with the time-constant
as set by the F coefficient.
So, F and P is not equivalents, as P will not contribute to the state of
Vi, which is evident in the weak pull-in of a standard PI loop.
However, F and P will for the AC behaviour of the loop be equivalents,
so care must be taken into setting P with regard to F in order to get
the expected damping of the loop.
Anyway, this is a FLL-aided PI-loop, which looks like an incorrectly
wired PID-loop. Quite minimalistic.
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 little
What am I missing?
I think I covered that above.
One thing for sure that the code is missing is a pre-filter, which is
very helpful because of the GPS phase noise.
It is missing a whole deal, but I wanted to illustrate the core.
One thing which is not covered is the un-wrapping of the phase detector
in the case that it does not wrap around binary. Another thing, the
frequency detector phase history may need to be unwrapped prior to
subtraction in order to make sure the frequency estimate becomes correct.
Turning on the "D" term in a PID with a prefilter is mostly not
recommended, They tend to just cancel each other.
I avoided the "D" coefficient name as it will be confusing to a normal
PID naming, when it will in fact does not do the normal "D".
Cheers,
Magnus