HM
Hal Murray
Mon, Mar 24, 2014 6:12 AM
I did a temporary hack on the PID code to convert the D-term into I^2 term,
by integrating the integrator output. First attempt was indeed quite
resonant just to show that I was in the unsafe region. Backing down on the
strength of the component sure did remove much of the resonance, but I did
not see any appreciable improvement in filtering performance, so quick and
dirty hacking isn't sufficient, darn.
Maybe it isn't sufficient to make a great GPSDO, but it's more than
sufficient to point out the advantages of Tom's simulation setup.
Thanks Tom.
--
These are my opinions. I hate spam.
magnus@rubidium.dyndns.org said:
> I did a temporary hack on the PID code to convert the D-term into I^2 term,
> by integrating the integrator output. First attempt was indeed quite
> resonant just to show that I was in the unsafe region. Backing down on the
> strength of the component sure did remove much of the resonance, but I did
> not see any appreciable improvement in filtering performance, so quick and
> dirty hacking isn't sufficient, darn.
Maybe it isn't sufficient to make a great GPSDO, but it's more than
sufficient to point out the advantages of Tom's simulation setup.
Thanks Tom.
--
These are my opinions. I hate spam.
MD
Magnus Danielson
Wed, Mar 26, 2014 7:58 PM
On 24/03/14 07:12, Hal Murray wrote:
I did a temporary hack on the PID code to convert the D-term into I^2 term,
by integrating the integrator output. First attempt was indeed quite
resonant just to show that I was in the unsafe region. Backing down on the
strength of the component sure did remove much of the resonance, but I did
not see any appreciable improvement in filtering performance, so quick and
dirty hacking isn't sufficient, darn.
Maybe it isn't sufficient to make a great GPSDO, but it's more than
sufficient to point out the advantages of Tom's simulation setup.
Thanks Tom.
Did some home-work on third-degree PLL parameters, so now I know why I
failed, as I never tried to do it right.
One thing that Tom's simulator isn't doing is calculating the parameters
for the PID for you, or backwards what characteristics you will get.
Cheers,
Magnus
On 24/03/14 07:12, Hal Murray wrote:
>
> magnus@rubidium.dyndns.org said:
>> I did a temporary hack on the PID code to convert the D-term into I^2 term,
>> by integrating the integrator output. First attempt was indeed quite
>> resonant just to show that I was in the unsafe region. Backing down on the
>> strength of the component sure did remove much of the resonance, but I did
>> not see any appreciable improvement in filtering performance, so quick and
>> dirty hacking isn't sufficient, darn.
>
> Maybe it isn't sufficient to make a great GPSDO, but it's more than
> sufficient to point out the advantages of Tom's simulation setup.
>
> Thanks Tom.
Did some home-work on third-degree PLL parameters, so now I know why I
failed, as I never tried to do it right.
One thing that Tom's simulator isn't doing is calculating the parameters
for the PID for you, or backwards what characteristics you will get.
Cheers,
Magnus
TV
Tom Van Baak
Wed, Mar 26, 2014 9:42 PM
Did some home-work on third-degree PLL parameters, so now I know why I
failed, as I never tried to do it right.
One thing that Tom's simulator isn't doing is calculating the parameters
for the PID for you, or backwards what characteristics you will get.
Cheers,
Magnus
Magnus, et al,
Still hoping some of you process control & PID experts will contribute a couple lines of C code to the simulator. The gpsim1 ver=N parameter will select any one of many different algorithms. I believe no one algorithm is "correct"; the goal is simply to include as many as you can contribute so we can all play with them.
/tvb
> Did some home-work on third-degree PLL parameters, so now I know why I
> failed, as I never tried to do it right.
>
> One thing that Tom's simulator isn't doing is calculating the parameters
> for the PID for you, or backwards what characteristics you will get.
>
> Cheers,
> Magnus
Magnus, et al,
Still hoping some of you process control & PID experts will contribute a couple lines of C code to the simulator. The gpsim1 ver=N parameter will select any one of many different algorithms. I believe no one algorithm is "correct"; the goal is simply to include as many as you can contribute so we can all play with them.
/tvb
PK
Poul-Henning Kamp
Wed, Mar 26, 2014 10:47 PM
Did some home-work on third-degree PLL parameters, so now I know why I
failed, as I never tried to do it right.
Once you get to third-order PLLs you need to start paying serious
attention to rounding errors.
In most cases using a "double" floating point format will do, but you
have to make sure you don't loose precision to normalisation in
your additions.
I've had varying degress of success myself, and overall I'm not
sure it really makes sense to fight the battles, unless you need
really long hold-over times.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message <5333314D.5090202@rubidium.dyndns.org>, Magnus Danielson writes:
>Did some home-work on third-degree PLL parameters, so now I know why I
>failed, as I never tried to do it right.
Once you get to third-order PLLs you need to start paying serious
attention to rounding errors.
In most cases using a "double" floating point format will do, but you
have to make sure you don't loose precision to normalisation in
your additions.
I've had varying degress of success myself, and overall I'm not
sure it really makes sense to fight the battles, unless you need
really long hold-over times.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
BC
Bob Camp
Wed, Mar 26, 2014 11:33 PM
Hi
64 bit int’s with 128 bit intermediate results can do a pretty good job for most of this.
Bob
On Mar 26, 2014, at 6:47 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
Did some home-work on third-degree PLL parameters, so now I know why I
failed, as I never tried to do it right.
Once you get to third-order PLLs you need to start paying serious
attention to rounding errors.
In most cases using a "double" floating point format will do, but you
have to make sure you don't loose precision to normalisation in
your additions.
I've had varying degress of success myself, and overall I'm not
sure it really makes sense to fight the battles, unless you need
really long hold-over times.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
64 bit int’s with 128 bit intermediate results can do a pretty good job for most of this.
Bob
On Mar 26, 2014, at 6:47 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <5333314D.5090202@rubidium.dyndns.org>, Magnus Danielson writes:
>
>> Did some home-work on third-degree PLL parameters, so now I know why I
>> failed, as I never tried to do it right.
>
> Once you get to third-order PLLs you need to start paying serious
> attention to rounding errors.
>
> In most cases using a "double" floating point format will do, but you
> have to make sure you don't loose precision to normalisation in
> your additions.
>
> I've had varying degress of success myself, and overall I'm not
> sure it really makes sense to fight the battles, unless you need
> really long hold-over times.
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
MD
Magnus Danielson
Fri, Mar 28, 2014 5:50 PM
On 26/03/14 22:42, Tom Van Baak wrote:
Did some home-work on third-degree PLL parameters, so now I know why I
failed, as I never tried to do it right.
One thing that Tom's simulator isn't doing is calculating the parameters
for the PID for you, or backwards what characteristics you will get.
Cheers,
Magnus
Magnus, et al,
Still hoping some of you process control & PID experts will contribute a couple lines of C code to the simulator. The gpsim1 ver=N parameter will select any one of many different algorithms. I believe no one algorithm is "correct"; the goal is simply to include as many as you can contribute so we can all play with them.
Yes, now as the weekend finally reached me I can look at it again.
I have looked at third degree PLLs again and if you know where you're
poles should be going, then setting it up is trivial and stability can
be guaranteed.
Cheers,
Magnus
Cheers,
Magnus
On 26/03/14 22:42, Tom Van Baak wrote:
>> Did some home-work on third-degree PLL parameters, so now I know why I
>> failed, as I never tried to do it right.
>>
>> One thing that Tom's simulator isn't doing is calculating the parameters
>> for the PID for you, or backwards what characteristics you will get.
>>
>> Cheers,
>> Magnus
>
> Magnus, et al,
>
> Still hoping some of you process control & PID experts will contribute a couple lines of C code to the simulator. The gpsim1 ver=N parameter will select any one of many different algorithms. I believe no one algorithm is "correct"; the goal is simply to include as many as you can contribute so we can all play with them.
Yes, now as the weekend finally reached me I can look at it again.
I have looked at third degree PLLs again and if you know where you're
poles should be going, then setting it up is trivial and stability can
be guaranteed.
Cheers,
Magnus
Cheers,
Magnus
