Re: [time-nuts] First success with very simple, very low cost GPSDO
Magnus
Thanks, even more interesting, I'll give it a try after I figger out under
what conditions it should help.
You are right, I did not fully take into account the DC offset that is
removed.
That is because it happens only once on the very first pass the code loop.
Any effect that may have, goes away forever after the control loop's TC
settling time has passed and the VI term has had time to add the removed DC
offset back in.
Assuming there is no clipping going on, a D * I is exactly the same as a P
with one exception, as you pointed out.
It also removes a DC offset that is equal to the very first value read. (but
this only happens once at the first pass in the code)
So D * I == P - offset; where Offset == the first Vdp reading.
After I term has had time to replace first Vdp reading's "offset" that was
removed, the D * I term's effect is back to the exact same effect as an P
term for ever more.
So does the code depend on the first Vdp error reading to contain some valid
and useful value other than zero,
Are you suggesting this only works once during turn on and it's effects only
apply over the loops TC time period?
(if so sounds unpredictable at best, If not I still don't know how it works)
I can see a few possible initial conditions that could happen: Does the code
depend on a specific one of these to occur?
#1 the loop is started before there is any Vdp phase error, in which case
the D * I term will == P, No removed offset, therefore no effect on anything
but the P gain.
#2 the loop is started after the VdP error is stable, valid and non zero,
in which case the D * I term will == P minus a fixed offset
#3 the loop is started when the Vdp error input is not yet stabilized or
still invalid in which case the D x I term will ==P minus some random number
(not sure that can be depended to help anything)
In any case looks to me like the code is still mostly a standard PI
controller , at least after the code has been running long enough to settle
on the Loop's TC. After that, I can not see any further useful effect.
Same long term effect, Not quite the same effect short term.
Vi = Vi + (I * Vdp) ; Initial Vi value = F*First_Vdp_reading)
Vf = Vi + (P+F) * Vdp
ws
Magnus Danielson wrote
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
Magnus wrote
snip
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
Magnus
I think this is close to the exact equivalent code under all conditions and
includes the DC offset term that is removed.
If I'm right, it may not be doing exactly what you want it to be doing.
Vi = Vi + (I * Vdp)
Vf = Vi + (P+F) * Vdp - Offset; (where Offset = F * First_Vdp_reading)
ws
----- Original Message -----
From: "WarrenS" warrensjmail-one@yahoo.com
To: "Discussion of precise time and frequency measurement"
time-nuts@febo.com
Sent: Saturday, April 12, 2014 5:10 PM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO
Magnus
Thanks, even more interesting, I'll give it a try after I figger out under
what conditions it should help.
You are right, I did not fully take into account the DC offset that is
removed.
That is because it happens only once on the very first pass the code
loop.
Any effect that may have, goes away forever after the control loop's TC
settling time has passed and the VI term has had time to add the removed
DC offset back in.
Assuming there is no clipping going on, a D * I is exactly the same as a P
with one exception, as you pointed out.
It also removes a DC offset that is equal to the very first value read.
(but this only happens once at the first pass in the code)
So D * I == P - offset; where Offset == the first Vdp reading.
After I term has had time to replace first Vdp reading's "offset" that was
removed, the D * I term's effect is back to the exact same effect as an P
term for ever more.
So does the code depend on the first Vdp error reading to contain some
valid and useful value other than zero,
Are you suggesting this only works once during turn on and it's effects
only apply over the loops TC time period?
(if so sounds unpredictable at best, If not I still don't know how it
works)
I can see a few possible initial conditions that could happen: Does the
code depend on a specific one of these to occur?
#1 the loop is started before there is any Vdp phase error, in which case
the D * I term will == P, No removed offset, therefore no effect on
anything but the P gain.
#2 the loop is started after the VdP error is stable, valid and non zero,
in which case the D * I term will == P minus a fixed offset
#3 the loop is started when the Vdp error input is not yet stabilized or
still invalid in which case the D x I term will ==P minus some random
number (not sure that can be depended to help anything)
In any case looks to me like the code is still mostly a standard PI
controller , at least after the code has been running long enough to
settle on the Loop's TC. After that, I can not see any further useful
effect.
Same long term effect, Not quite the same effect short term.
Vi = Vi + (I * Vdp) ; Initial Vi value = F*First_Vdp_reading)
Vf = Vi + (P+F) * Vdp
ws
Magnus Danielson wrote
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
Magnus wrote
snip
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