risetime and falltime in the calculator

There were some bugs introduced between ISR8 and ISR10 (fixed in ISR11) where if the arguments (in some cases) were supplied as documented, the functions did not work properly. The result is that the two functions currently behave the same as each other - but we do plan to do something about that.

The falltime function is documented this way:

    Returns the fall time measured between theta1 (percent high) to theta2 (percent low) of
    the difference between the initial value and the final value.
    ...
    Percent High is the percentage high difference between initial and final values.
    Percent Low is the percentage low difference between initial and final values.

This is actually more clearly described on the MDL page:

    theta1 is the threshold high expressed as a percentage of the difference
between the initial and final values.
    theta2 is the threshold low expressed as a percentage of the difference
between the initial and final values.

This (along with the pictures) suggests that if the initial value is "high" and the final value is "low", then the percentages should be specified in the order 10 90. What was happening before was some attempt to handle the arguments being specified in the wrong order - but this unfortunately broke a few cases.

So the key difference is that the arguments are not supposed to be specified the same way - for rise time you should  specify the initialValue as the "low" value, adn the finalValue as  the "high", and then specify the percentages as (say) 10 then 90. For fallTime you should specify the initialValue as the "high" and finalValue as the "low", and then the percentages as 10 and 90 again.

What we ultimately want to do is make this unambiguous so that you always know that fallTIme is finding a falling edge and riseTime a rising edge. The challenge is that since these functions are already "out there" we may have to support the way they work currently because otherwise we're at risk of breaking somebody's measurements if they've specified them with the arguments counter to the documentation (in fact that was why it broke in the first place, because somebody tried to correct the behaviour without checking what the documentation said).

Regards,

Andrew.

There were some bugs introduced between ISR8 and ISR10 (fixed in ISR11) where if the arguments (in some cases) were supplied as documented, the functions did not work properly. The result is that the two functions currently behave the same as each other - but we do plan to do something about that.

The falltime function is documented this way:

    Returns the fall time measured between theta1 (percent high) to theta2 (percent low) of
    the difference between the initial value and the final value.
    ...
    Percent High is the percentage high difference between initial and final values.
    Percent Low is the percentage low difference between initial and final values.

This is actually more clearly described on the MDL page:

    theta1 is the threshold high expressed as a percentage of the difference
between the initial and final values.
    theta2 is the threshold low expressed as a percentage of the difference
between the initial and final values.

This (along with the pictures) suggests that if the initial value is "high" and the final value is "low", then the percentages should be specified in the order 10 90. What was happening before was some attempt to handle the arguments being specified in the wrong order - but this unfortunately broke a few cases.

So the key difference is that the arguments are not supposed to be specified the same way - for rise time you should  specify the initialValue as the "low" value, adn the finalValue as  the "high", and then specify the percentages as (say) 10 then 90. For fallTime you should specify the initialValue as the "high" and finalValue as the "low", and then the percentages as 10 and 90 again.

What we ultimately want to do is make this unambiguous so that you always know that fallTIme is finding a falling edge and riseTime a rising edge. The challenge is that since these functions are already "out there" we may have to support the way they work currently because otherwise we're at risk of breaking somebody's measurements if they've specified them with the arguments counter to the documentation (in fact that was why it broke in the first place, because somebody tried to correct the behaviour without checking what the documentation said).

Regards,

Andrew.