[time-nuts] PLL Math Question

[Jim Lux]

On 3/12/14 10:06 PM, Chris Albertson wrote:
> On Wed, Mar 12, 2014 at 9:13 PM, Daniel Mendes <dmendesf at gmail.com> wrote:
>> This is a FIR x IIR question...
>>
>> moving average = FIR filter with all N coeficients equalling 1/N
>> exponential average = using a simple rule to make an IIR filter
>
> Isn't his "moving average" just a convolution of the data with a box car
> function?  That treats the last N samples equally and is likely not
> optimal.   I think why he wants is a low pass filter.

A moving average (or rectangular impulse response) *is* a low pass 
filter.  The frequency response is of the general sin(x)/x sort of 
shape, and it has deep nulls, which can be convenient (imagine a moving 
average covering 1/60th of a second, in the US.. it would have strong 
nulls at the line frequency and harmonics)


This method is like
> the hockey player who skates to where to puck was about 5 seconds ago.  It
> is not the best way to play the game.  He will in fact NEVER get to the
> puck if the puck is moving he is domed to chase it forever..   Same here
> you will never get there.

That distinction is different than the filter IIR vs FIR thing. Filters 
are causal, and the output always lags the input in time.  if you want 
to predict where you're going to be you need a different kind of model 
or system design.  Something like a predictor corrector, for instance.



>
> But if you have a long time constant on the control loop you have in effect
> the kind of "averaging" you want, one that tosses out erratic noisy data.
> A PID controller uses only three memory locations and is likely the best
> solution.

PID is popular, having been copiously analyzed and used over the past 
century. It's also easy to implement in analog circuitry.

ANd, there's long experience in how to empirically adjust the gain 
knobs, for some kinds of controlled plant.

However, I don't know that the simplicity justifies its use in modern 
digital implementations: very, very few applications are so processor or 
gate limited that they couldn't use something with better performance.

If you are controlling a physical system with dynamics that are well 
suited to a PID (e.g. a motor speed control) then yes, it's the way to 
go.  But if PIDs were so wonderful, then there wouldn't be all sorts of 
"auto-tuning" PIDs out there (which basically complexify things by 
trying to estimate the actual plant model function, and then optimize 
the P,I, and D coefficients).

PID controllers don't do well when there's a priori side knowledge 
available.  For instance, imagine a thermostat kind of application where 
you are controlling the temperature of an object outside in the sun. 
You could try to control the temperature solely by measuring the temp of 
the thing controlled, and comparing it against the setpoint (a classic 
PID sort of single variable loop).  Odds are, however, that if you had 
information about the outside air temperature and solar loading, you 
could hold the temperature a lot more tightly and smoothly, because you 
could use the side information (temp and sun) to anticipate the 
heating/cooling demands.

This is particularly the case where the controlled thing has long time 
lags, but low inertia/mass.

>
> We have to define "best".  I'd define it as "the error integrated over time
> is minimum".  I think PiD gets you that and it is also easy to program and
> uses very little memory.  Just three values (1) the error, (2) the total of
> all errors you've seen (in a perfect world this is zero because the
> positive and negative errors cancel) and (3) the rate of change in the
> error (is it getting bigger of smaller and how quickly?)  Multiply each of
> those numbers by a constant and that is the correction to the output value.
>     It's maybe 6 or 10 lines of C code.   The "magic" is finding the right
> values for the constants.

And that magic is sometimes a lot of work.

And practical PID applications also need things like integrator reset to 
prevent wind-up issues, and clamps, or variable gains.

PID, or PI, is, as you say, easy to code, and often a good first start, 
if you have a system with fast response, and lots of gain to work with. 
  It's like building circuits with an opamp: big gain bandwidth product 
makes it more like an ideal amplifier where the feedback components 
completely determine the circuit behavior. Put in hysteresis, or a time 
delay, and things start to not look so wonderful.


>
> This is worth reading
> PIDforDummies.html <http://www.csimn.com/CSI_pages/PIDforDummies.html>
>