Aliasing of step response (3.4.2 MinGW, control-2.1.55)

[Bernhard Weller]

Today I was very baffled as I was analyzing some step responses of a second
order transfer function. Increasing the quality factor Q suddenly lead to a
response without any overshoot or oscillation.

Take this as an example:
MechResFreq = 1000;
QMech = 1400;
MechModel = tf([(2*pi*MechResFreq)^2], [1 2/QMech*(2*pi*MechResFreq)
(2*pi*MechResFreq)^2]);
step(MechModel)

This will look like a normal exponential function. If you reduce QMech to
100, you will actually see an oscillation and overshoot.

After thinking some time about why this could happen, it suddenly struck me,
that this might be an aliasing problem. So I changed the step command to:
step(MechModel,2,1e-6) % smaller time step

And then the oscillation will be visible for QMech=1400 as well (maybe the
time steps are a bit overkill now).
The documentation states:
step(sys,tfinal,dt)
sys
       LTI model.
tfinal
       Optional simulation horizon. If not specified, it is calculated by
the poles of the system to reflect adequately the response transients. 
dt
       Optional sampling time. Be sure to choose it small enough to capture
transient phenomena. If not specified, it is calculated by the poles of the
system.

So when I specify a small enough dt everything is fine, but something seems
to go wrong if the time step is calculated by the poles of the system. It's
not a huge issue, but maybe something to watch out for.

Bernhard

--
View this message in context: 
http://octave.1599824.n4.nabble.com/Aliasing-of-step-response-3-4-2-MinGW-control-2-1-55-tp3843066p3843066.html
Sent from the Octave - General mailing list archive at Nabble.com.