help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lukas Reichlin
Subject: Re: Aliasing of step response (3.4.2 MinGW, control-2.1.55)
Date: Mon, 26 Sep 2011 14:35:41 +0200

On 26.09.2011, at 10:24, Bernhard Weller wrote:

> 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

Hi Bernhard

I confirm your suspicion, but I don't have a quick fix this time. The problem 
is caused by the function __sim_horizon__ at the end of the file 
__time_response__.m which calculates tfinal and dt. Do you know of a robust 
method to find an appropriate time step? I would be happy to add an improved 
version :-)

Regards,
Lukas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]