fall_time
Builtin index · Signal processing
result = rise_time(x, [low=0.1], [high=0.9], [base=], [top=])
Input: x, low, high, base, top · Output: result
What it is
x: a length-N real vector or Signal. low/high (optional numbers, defaults 0.1/0.9) are fractions of the step, not levels, so the 20%–80% convention is low=0.2, high=0.8. base/top (optional numbers) are the levels the step runs between, defaulting to x's own min and max.
Overloads
One call shape — this function is not overloaded.
| Code | Input | Output | Description |
result = rise_time(x, [low=0.1], [high=0.9], [base=], [top=]) | x vector or Signalx: a length-N real vector or Signal.low number, optional (default 0.1)low/high (optional numbers, defaults 0.1/0.9) are fractions of the step, not levels, so the 20%–80% convention is low=0.2, high=0.8.high number, optional (default 0.9)low/high (optional numbers, defaults 0.1/0.9) are fractions of the step, not levels, so the 20%–80% convention is low=0.2, high=0.8.base number, optionalbase/top (optional numbers) are the levels the step runs between, defaulting to x's own min and max.top number, optionalbase/top (optional numbers) are the levels the step runs between, defaulting to x's own min and max. | result number or Signal | Returns a single number: the transition time of the first complete rising (resp. falling) transition, in seconds for a Signal and samples otherwise, with both endpoints linearly interpolated between samples. Errors rather than guessing when the record holds no complete transition. Caveat, and it is a common case: on a step that *rings*, the automatic top is the overshoot peak rather than the settled value, which drags the 90% level up and reports a rise time that is too long — pass top= explicitly when the step overshoots. |
Examples
No documentation example calls this form yet. The Signal processing chapter is where one belongs.
How it works
rise_time(x, [low=0.1], [high=0.9], [base=], [top=]) / fall_time(...) -- the 10%-90% transition time of the first complete rising (resp. falling) transition in x, in seconds for a Signal and samples otherwise. low/high are FRACTIONS of the step, not levels, so the 20%-80% convention some standards use is low=0.2, high=0.8. base/top override the levels the step is taken to run between; they default to x's own min and max, which is exactly predictable but wrong in one specific, common case -- a step that RINGS puts its overshoot peak in max, dragging the 90% level above the settled top and reporting a rise time that is too long. Pass top= (the settled value) when the step overshoots. That caveat is stated rather than defended against, because every automatic top-detection scheme has its own surprising case and a silently-clever default here is worse than a stated assumption.
From the note above this builtin in the interpreter, where the reasoning was written down as it was built.
See also
rise_time — documented in the same entry.