Stepinfo provides wrong rise time using [0, 0.63] limits for non minimum phase systems

When using Stepinfo for 63% rise time (ie [0, 0.63]) interval, it ignores the first portion of time for non minimum systems. Stepinfo looks for the first time the output > 0 the lower limit. However, the non minimum phase goes negative first then crosses to positive. Stepinfo starts the rise time at this zero crossing instead of at time 0

Answer 1

[Sam Chak]

Hi @Ken Buckholtz

Rise time is a non-standard performance measure. By default, in MATLAB, rise time is defined as the duration required to rise from 10% to 90% of the transition from the initial value to the final value. Therefore, movement towards the negative side in non-minimum phase systems is not technically considered 'rising.' If your definition of rise time for non-minimum phase systems extends from the start to 63% of the final value, you will need to perform the calculation independently.

G   = tf([-1 2], [1 2 2])

G =
 
     -s + 2
  -------------
  s^2 + 2 s + 2
 
Continuous-time transfer function.

stepinfo(G)

ans = struct with fields:
         RiseTime: 1.3582
    TransientTime: 4.5381
     SettlingTime: 4.6388
      SettlingMin: 0.9042
      SettlingMax: 1.0495
        Overshoot: 4.9524
       Undershoot: 14.6134
             Peak: 1.0495
         PeakTime: 3.4539

step(G), grid on
[y, t]  = step(G);
idx = find(abs(y - 0.63) <= 1e-2);
tr  = t(idx(1));
xline(tr, '--', sprintf('User-defined Rise Time: %.3f sec', tr), 'color', '#7F7F7F', 'LabelVerticalAlignment', 'bottom')
yline(0.63, '--', sprintf('63%%'), 'color', '#7F7F7F', 'LabelVerticalAlignment', 'bottom')

[Paul]

Interesting that the doc page for stepinfo defines an input called 'RiseTimeLimits' under syntax but uses a different input called 'RiseTimeThreshold' in this example. And then the Inputs section doesn't actually define the Name of that Name-Value pair.

[Sam Chak]

Excellent observation as always, @Paul. I also did not notice the change, as I rarely measure rise time in my applications.

Answer 2

[Sam Chak]

Hi @Ken Buckholtz

Here is another approach to estimating the user-defined rise time: by defining the 'RiseTimeLimits' and identifying the time when the output crosses zero for the second time.

G   = tf([-1 2], [1 2 2])

G =
 
     -s + 2
  -------------
  s^2 + 2 s + 2
 
Continuous-time transfer function.

S   = stepinfo(G, 'RiseTimeLimits', [0 0.63])   % from 0% to 63%

S = struct with fields:
         RiseTime: 0.9133
    TransientTime: 4.5381
     SettlingTime: 4.6388
      SettlingMin: 0.6369
      SettlingMax: 1.0495
        Overshoot: 4.9524
       Undershoot: 14.6134
             Peak: 1.0495
         PeakTime: 3.4539

step(G), grid on, hold on
[y, t]  = step(G);
idx = find(abs(y - 0) <= 1e-2)

idx = 2×1

1 17

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

% 2nd Zero-crossing Time
t0  = t(idx(2))

t0 = 0.7368

% User-defined Rise Time
tr  = t0 + S.RiseTime

tr = 1.6501

plot(t(idx(2)), 0, 'ro')
xline(t0,   '--', sprintf('2nd Zero-crossing Time: %.3f sec', t0), 'color', '#7F7F7F', 'LabelVerticalAlignment', 'bottom')
xline(tr,   '--', sprintf('User-defined Rise Time: %.3f sec', tr), 'color', '#7F7F7F', 'LabelVerticalAlignment', 'bottom')
yline(0.63, '--', sprintf('63%%'),                                 'color', '#7F7F7F', 'LabelVerticalAlignment', 'bottom')

[Ken Buckholtz]

MATLAB can define rise time any way that they want. End users need to be aware of every single calculation that is be done "under the hood" for them. I wonder how many others are aware of MATLAB's definition.

[Sam Chak]

Hi @Ken Buckholtz

Like many other software products, MATLAB is not without its flaws and relies on user feedback for improvements. The development team typically considers user input; however, for non-critical issues, it may take several releases to implement updates. You can also contact MathWorks to suggest enhancements for specific features. Click this link:

https://supportcases.mathworks.com/mwsupport/s/casetypeselection?language=en_US&c__caseParameter=productusage&s_tid=srlp_product

[Ken Buckholtz]

It worked as expected in Release 2017b. The definition of the Rise Time was changed in around Rel 2021a.

Why MATLAB just repurposes definitions is beyond me.