[time-nuts] Lying to Lady Heather

Bill Hawkins bill at iaxs.net
Tue May 11 22:49:56 UTC 2010


Arrrr, Ulrich, lad, I, Bill Hawkins, kin to Jim Hawkins and the pirates 0f
Treasure Island, do pardon you, though you really should have resisted.
(Understanding pirates is key to understanding today's economy.)

The pardon is easy, because I have at times ridiculed something that I did
not understand, only to find out that there were those who understood it
much better than I. It is better to remain silent than to open one's mouth
and remove all doubt about understanding.

I have been working with PID algorithms for nigh on to 50 years. "Plant"
in my world meant part of an oil refinery or a dangerous exothermic process,
not a dinky little short time constant servomechanism. The embedded PID does
not have to handle mode changes between Auto and Manual, where the operator
changes the output to correct a problem and then switches to Auto, expecting
the PID to pick up from the present output.

And so, the three industrial process control systems that I designed used 
the present output as the basis for the next move. New OUT = old OUT plus
difference terms, as I described.

Perhaps I did not explain this clearly. That, too, is a risk of opening
one's
mouth.

Bob Camp asked about what seemed to be inconsistencies between behavior and
tuning constants. I tried to explain PID, but should have realized that a
Lady
can do whatever she wants to do. Ah, in this case, her behavior is
constrained
by her programmer.

Ulrich, I bear you no ill will. You have made many useful contributions to
this list. T'was a recent unwanted phone call that brought Arrrr to mind. I
should have resisted.

Bill Hawkins


-----Original Message-----
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of Ulrich Bangert
Sent: Tuesday, May 11, 2010 3:33 AM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] Lying to Lady Heather

Pardon, but I cannot resist:

> OUT = previous integrated error + gain * (error + current 
> error/integral time constant  + delta error * derivative time 
> constant) 

> Then previous integrated error = new output.

May a formula that contains

- an "error"
- a "current error"
- a "delta error"
- a "previous integrated error"

be considered to contain a lot of errors? 

If the formula is to be taken serious I would call it an I-Regulator with a
strange integration rule. Surely NOT what a PID looks like. For a really
nice introduction into control theory have a look at

http://dpm1480.pbworks.com/f/PID%20without%20a%20PhD.pdf

Tim Wescott is a very experienced engineer and one of the protagonists in
the newsgroup on DSP topics.

Regards
Ulrich Bangert



> -----Ursprungliche Nachricht-----
> Von: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] Im Auftrag von Bill Hawkins
> Gesendet: Dienstag, 11. Mai 2010 09:29
> An: 'Discussion of precise time and frequency measurement'
> Betreff: Re: [time-nuts] Lying to Lady Heather
> 
> 
> Bob,
> 
> I'd expect the PID output to change instantly with error. The 
> equation is
> roughly:
> 
> OUT = previous integrated error + gain * (error + current 
> error/integral time constant  + delta error * derivative time 
> constant) 
> where multiply or divide occurs before addition, as 
> controlled by parentheses.
> 
> Then previous integrated error = new output.
> 
> The time constants are relative to the sampling time of the 
> PID algorithm.
> 
> Like all integrals, something has to set the initial value.
> 
> Damping is a function of gain and time constants. Either a 
> high gain or a short integral time will cause the output to 
> oscillate, as will a long derivative time.
> 
> How are you calculating damping?
> 
> Bill Hawkins
> 
>  
> 
> -----Original Message-----
> From: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] On Behalf Of Bob Camp
> Sent: Monday, May 10, 2010 7:22 PM
> To: Discussion of precise time and frequency measurement
> Subject: [time-nuts] Lying to Lady Heather
> 
> Hi
> 
> I've spent some time lying to Lady Heather, with some 
> interesting results:
> 
> 1) Classical control loop theory would suggest that damping 
> should be fairly close to 1 for reasonable operation. Greater 
> than 10 should be highly damped. Less than 0.1 should ring 
> quite a bit. The TBolt doesn't seem to work this way. You can 
> go to << 0.1 and still have a stable response to a step. You 
> can go out to > 100 and not get a "lazy" response to a step. 
> You can get to a point that it will ring, but it's down < 
> 0.001. Obviously the TBolt and I read different books.
> 
> 2) In a PID setup, you would have control on each 
> coefficient. With the TBolt setup the "gain" seems to be the 
> only way to impact the D part of the PID. You can watch the 
> DAC output as you increase the gain. The swing of the DAC 
> responding to the GPS pps jumping will decrease as you 
> increase the gain number. It sounds backwards, but it makes 
> sense. With "correct" gain, each time there is a step in the 
> GPS PPS, the DAC immediately changes, no matter what the 
> damping or time constant. Again, seems strange, but that's 
> the way it works. 
> 
> 3) Time Constant does seem to slow down the "integrator" in the PID. 
> 
> Why lie to Lady Heather?
> 
> On a very stable unit - watch the DAC voltage. It's climbing 
> up and down like crazy on a second to second basis. It's 
> reasonable to believe that the OCXO is more stable than GPS 
> at one second. The DAC should be fairly quiet second to 
> second. DAC LSB's are around 1 ppt. That's around (like a 
> factor or 3 or 5) the stability of the OCXO at 1 second. One 
> or two LSB per second might make sense. Anything 5 or 10X  
> than that is mostly noise that you simply don't need. 
> 
> Tell the unit enough lies (like gain = -60) and sure enough 
> the DAC slows down and hops 1 LSB every so often. When GPS is 
> stable it will stay in one state for 10's of seconds. Even 
> with 10 ns hops in the GPS, it still stays down in the 1 to 2 
> LSB range. That's *got* to be more stable. 
> 
> Why is this good - nice as a frequency standard. 
> 
> Why this is bad - TBolt pps does not track GPS PPS very 
> closely. Not good for E911 service. 
> 
> Bottom line - there's lots of ways to optimize a TBolt.
> 
> Bob




More information about the time-nuts mailing list