6

I'm still a bit new to this domain, just wondering if the rise time of a probe and the oscilloscope itself have to be substracted to the measure in order to recover the real measured rise time?

Let's suppose a case:

My signal have a real rise time of 0.7ns. The probe is announced to have a rise time of 1.4ns and 1.8ns for the oscilloscope.

Is the final readed value will be 1.4 + 1.8 + 0.7 = 3.9ns?

AnomalySmith
  • 177
  • 1
  • 6
  • 4
    The normal way would be to have oscilloscope and matching probes far faster than your signal since anything else will give you high uncertainty of your measurement. – winny Sep 28 '16 at 10:15
  • 4
    More like 2.4ns in this case, but in these domains you need to take into account the possible uncertainties at any point, so for any scope in that range it would possibly come out to 0-2ns for your signal, or said in another way: measuring rise times anywhere below the scopes system limit is guesswork mostly. – PlasmaHH Sep 28 '16 at 10:54

2 Answers2

6

No, the actual physics and formulas involved to get this absolutely right are not totally easy, but for gaussian response oscilloscopes (quick read about differences for flat response scopes: http://cp.literature.agilent.com/litweb/pdf/5988-8008EN.pdf), we relate things to each other like this:

\$R_{meas} = \sqrt{R_{signal}^2 + R_{system}^2 }\$

where \$R_{system}\$ is the bandwidth of Oscilloscope + Probes, which is determined by basically the same relation (Just as its bandwidth is the inverse rms relationship, as for all bandwidths you "chain" with each other).

For me it helps to think of each next element in this chain, as an additional L(R)C filter, thus each adds a little more capacitance that needs to be filled.

So to your initial question, in theory we could subtract the rise times of the system from the measurement to get the real rise time, however there are usually uncertainties. The scope and probe risetimes are usually typical ones and may vary for each probe. Likewise there are a lot of other error sources, not the least one being uncertainty in the scopes sampling and limited resolution (in most digital scopes you see a sinc interpolation of the signal, try finding a dot display mode to see how many datapoints there really are that you can base your measurement of).

Thus trying to calculate it that way can only be called a rough estimate.

Lets try some numbers to get a feeling here:

The real perfect data:

\$\sqrt{1.4ns^2 + 1.8ns^2 + 0.7ns^2} = 2.385ns\$

Lets assume the system rise time is perfect, but just not the scopes timing: \$\sqrt{-1.4ns^2 - 1.8ns^2 + 2.36ns^2} = 0.608ns\$

And now lets assume the scope and probes are a bit off too: \$\sqrt{-1.45ns^2 - 1.85ns^2 + 2.36ns^2} = 0.21ns\$

PlasmaHH
  • 6,498
  • 5
  • 38
  • 49
0

No.

If your system has a rise time of x V/ns, anything below that will seem to have x V/ns rise time, anything above will be properly measured and no post processing is necessary.

This is because the rise time is the response of the system to a step input, i.e. a signal that rises much faster than the system capabilities. It is a sort of speed limit of the system. If you go faster, your system tries to follow doing its best, i.e. going at x V/ns, while if you go slower your system can accurately (within spec) follow the input signal.

If you want to measure a 0.7ns rise time you simply cannot do that with the hardware you propose.

Vladimir Cravero
  • 16,007
  • 2
  • 38
  • 71
  • 2
    As a first approximation, yes, but each added risetime adds a bit to the total, its the rms of the sums to be precise. You can ignore that for a rise time measurement when the step is so much faster than the actual rise time so that it can be ignored. I like to think of each added rise time in the chain as yet another capacitance that needs to be filled up – PlasmaHH Sep 28 '16 at 10:48
  • Hi Plasma, I am not really convinced of what you say. Would you care posting a comprehensive answer that deepens the explaination? Thanks. – Vladimir Cravero Sep 28 '16 at 20:57
  • Apparently your answer did not load for some reason while I wrote my previous comment. – Vladimir Cravero Sep 28 '16 at 21:11