Sometimes the rise and or the fall time measurement reports an error (??? Or NaN (Not a Number)) when it seems that it should work. What is the problem?

Sometimes the rise and or the fall time measurement reports an error (??? Or NaN (Not a Number)) when it seems that it should work. What is the problem?

Here is a description of what could be causing the problem:

In order to find the point (in time) when the rise starts, it is necessary to do a histogram (flat horizontal box) of the rising edge, at 10%, and find the horizontal position of its mean. This is true for anyone - human or FW (FirmWare). Ditto for 90% and for the fall time measurement.

There is a question of where (horizontally) to start the histogram box and where to stop it. If there is no noise, you start somewhere before risetime, and stop somewhere after. This will yield a valid result according to standards.

But if there is noise or a slow falling edge at the 10% level, one (human or computer) can not well decide where to properly start (the histogram box). In other words, you can no longer provide a valid result (the standards don't allow any fuzziness to this decision). In an indeterminate case like that, you can make guesses and approximations, but not a result which could be called valid by a standard; the FW might approximate some result, and/or might report an error or low resolution. The solution to such case is to change the 10%-90% rise time measurement to e.g. 20%-80% measurements.

There exists a narrow region of cases between a good measurement and the indeterminate case described above, when the noise (or the dribble-down) actually is low enough at certain point along the region of interest, and the FW might and might not find it (the point with low enough noise). The FW then might and might not offer a result, -e.g. the risetime measurement will work and the fall time measurement will not. (As in the picture attached). This is a rare case which typically lasts just a short time - if acquisitions continue soon there will be enough noise to get the indeterminate case described above. This is something that is also of little help to the measurement where we need a reliable result, not something that might work on 300 acquisitions eye but not on 500 acquisitions eye.

Two more points:
Always enable annotations on the measurements, so as to be able to see what is going on; and note that some other products in the field actually keep on reporting even in the indeterminate case. The values reported then are somewhere between a guess and a complete error, and the user needs only to enable the annotations and observe the placement of the points to decide for themselves that the measurement is not useful.