testing square waves rise time with Rigol scope

[festus]

Hi, I have a few question about testing square waves rise time with new Rigol scope.

First question, why does the rise time measurement change as I turn the horizontal scale clockwise?  I understand if the time base is too slow for measurement, but is what I am seeing-

(above, it reads 240ns to 250ns)


(this one reads 208ns)


(this one reads 192ns)

A similar question, why does the Freq readout start reading (****) just because I turn the timebase clockwise?

[saturation]

You have more resolution with the faster timebase, the scope can provide more accurate measures.

The Rigol also measures what is on the screen, so what it can see, it can measure.

You don't have the entire cycle so frequency cannot be calculated, i.e., the fall time is not visible.

[festus]

OK, I understand, sort of like using a 6000 count meter instead of a 2000 counts meter.  More resolution.  Can I assume, then, that the highest resolution number is the most accurate?  In my example, the 192ns is closer to the true rise time than the others?

For the freq measurement, I just assumed that the scope would continue to display the previous freq unless it detected a change.

[scrat]

Just because yo umention it... I find the frequency measurement on the Rigol a bit tricky, since it seems to measure based on the points displayed. This is what happens: if I try to measure a certain square wave's frequency, the thing that seems best to me is to average on many periods, so to use a large time base. Over a certain base, the rising/falling edges on screen confuse and graphically "overlap", and at that point the measure doesn't work any more. It sounds strange to me, since the memory contains far more points than what is on screen, and I expected the measure was calculated based on all the memory acquired.

Is this normal? IIRC this is not the behaviour of higher end scopes...

However, maybe just to overcome this issue, there is a counter, which I expect is a sort of added hardware, which works fine, no matter what the time base is.

[festus]

Hi scrat,

Can you expand upon that -- "However, maybe just to overcome this issue, there is a counter...."
What counter you referring to?

In my 1-day experimentation with the scope, I know what you mean about freq measurements.  As you reduce the number of periods on screen, you can definitely get a bogus freq displayed on the screen.

[joelby]

Use the fastest horizontal timebase that will fit in a single rise.

When measuring frequency, zoom until you get a 'reasonable' number of cycles on the screen. One is too few, and when they're indistinguishable there are too many. Fortunately you can compare the reading between the timebases quickly. It helps if you have an idea of what the frequency should be to avoid misinterpretation due to aliasing - it may be better to start from the shortest timebase.

The fact that calculations are only done from the points displayed on the screen is extremely broken, but it's hardly a precision tool anyway. For more accuracy, consider capturing a long (1M point) waveform and processing it on a computer.

[chscholz]

Risetime measurements according to IEEE 181 (IEEE Standard on Transitions, Pulses,
and Related Waveforms) are done as follows. I have no idea if Rigol implements IEEE181 standards)

1) determine the distribution of all amplitudes in a waveform (in praxis, a histogram is taken as an estimate of the distribution)
2) determine the bottom and top of the distribution (or the histogram)
3) determine the 10% and 90% level from the bottom/top
4) for each edge in the waveform determine the time to rise form the 20% level to the 80% level.
(see attachment 1)

When you change your timebase you get to a point where your signal does not swing to the full amplitude any more, thus you change your top/bottom levels and the rise time measurement changes (see attachment 2 and 3)

What you should do to measure rise times accurately and reproducibly is to determine top/bottom level based on many rising edges and then calculate risetimes of your waveform based on this top/bottom level. For example attachment 4 shows the first risetime, average risetime, min/max, std of risetimes based on 48 rising edges. Jitter measurements (that are essentially based on risetime measurements) are done using millions of bits/rising edges. Most scopes can only measure a single edge in a long acquisition (or require optional jitter software add-on packages).

For your specific waveform, you should increase your V/div setting so that your waveform fills bottom to top of the screen in order to make use of all 8 bits in your sample.

[saturation]

@chscholz:

Most excellent.  IEEE 181 makes a whole lot of sense, which scopes today use the standards when making automated measurements?  What is the source of your graphs?

There is no mention of 181 in the Rigol documentation.  Empirically, if were true but undocumented, the measurements would not vary with timebase.

I've seen some reactions to the various editions of 181, it seems its more common in higher end scopes, or scopes with full Windows OS or similar OS based scopes that have more storage and hardware to make these postprocess calculations.

[scrat]

Hi scrat,

Can you expand upon that -- "However, maybe just to overcome this issue, there is a counter...."
What counter you referring to?

In my 1-day experimentation with the scope, I know what you mean about freq measurements.  As you reduce the number of periods on screen, you can definitely get a bogus freq displayed on the screen.

If I understand correctly your post, I was speaking about the behaviour of freq measurement when you take a large number of periods into the window. As the edges become indistiguishable from one to the other (half period lasts less than one point on the screen), the frequency measurement becomes erratic.

If you play around the menus (I don't remember where, and don't have the Rigol by hand), you can activate a "counter" function. At first I though it was a trigger/s counter, but it seems to work indeed as a frequency measurement (at least for a square wave, I should try some other signals to see how it works. I think this is a hardware feature or a different measurement based on the acquisition, but it gives different results than the freq measurement, and has higher resolution.

[saturation]

You can read the manual  , but I think its in the Display or Utility button.  I use it all the time.  As chscholz post shows, unless you analyze a captured waveform statistically, you'll always see some change in measurement as the Rigol screens change, as every screen is a statistical sample, and all samples are not identical.

The counter works on continuously fed signal, so when live, it will read in real time and have a stable value regardless of timebase.  If you select 'Frequency' from the Ch1 menus, the frequency count will not be identical per timebase.

Hi scrat,

Can you expand upon that -- "However, maybe just to overcome this issue, there is a counter...."
What counter you referring to?

In my 1-day experimentation with the scope, I know what you mean about freq measurements.  As you reduce the number of periods on screen, you can definitely get a bogus freq displayed on the screen.

[saturation]

DSO in general are not precision measurement tools, after all 8 bits results in  0.4% resolution, and accuracy is another issue.

But the measurements pointed out by chscholz is great for uniformity and standardization, but in praxis, eyeballing is just as good, but its not the best possible measurement, and one can argue the least significant digits without end unless a formal way to define the data points is established. 

As analogy, its the difference between using a simple ruler, or having the same ruler and using a Vernier scale to measure between the lines, it defines an area very specifically.

...

The fact that calculations are only done from the points displayed on the screen is extremely broken, but it's hardly a precision tool anyway. For more accuracy, consider capturing a long (1M point) waveform and processing it on a computer.

[scrat]

Not only the freq measurement value slightly changes between different time bases and different captures, but the feature simply doesn't work if the time base is too large (too much time on screen), since it doesn't recognize the edges of the signal. It gives results which move around the submultiples of the real frequency.

I haven't read the specs of the Rigol, but usually DSOs have a quite good horizontal precision, besides their vertical one.

The Rigol, with its easy to use PC interface and long memory should be quite useful for post processing, where you can do any kind of calculation, based on standards or not.
 

[saturation]

One needs the right scale to measure the right size accurately, without it each cycle in the signal cannot be isolated, and so frequency cannot be calculated from its meaning, "cycles per second."

The Rigol measures as best as its hardware can provide.  Its not necessarily related to the resolution of its vertical or horizontal axes.

Even if you can see more, the vertical axis will be drowned by noise caused by the limits of an 8 bit ADC.  So even if the Rigol can present more on the scope, it likely won't be meaningful even with post processing.  However, maybe your external software can do a better job at measurement than the algorithm used by Rigol.

The theoretical maximum is given by were N= ADC bits:



For the Rigol, this becomes -49.92 dB.  Roughly, it will not be possible to discern signals from noise below 3mV, looking say at 1V signals, even if the Rigol can do 2mV/div.

The X axis is limited by Nyquist frequency, which is tied to the sampling speed, and the sampling speed is tied to the memory length for each timebase you select.

The Rigol will 'auto' adjust the sampling speed to compensate for the memory length selected or on auto mode, it prioritizes the sampling speed and uses the short memory length.  So even if the scope can do 5ns/div timebase, its top sampling speed is 1Gs/s, so its practical frequency limit is ~ Samples/10, or 100MHz.  This makes the 1052E viable as a hack version, since it has nearly the same hardware as the 1102E.

However, if you use 2 channels, the sampling speed is halved, to 500Ms/s; if you select high memory length, its halved once again to 250 Ms/s, and thus its practical frequency response in its worse case scenario is ~ 25 MHz.

Not only the freq measurement value slightly changes between different time bases and different captures, but the feature simply doesn't work if the time base is too large (too much time on screen), since it doesn't recognize the edges of the signal. It gives results which move around the submultiples of the real frequency.

I haven't read the specs of the Rigol, but usually DSOs have a quite good horizontal precision, besides their vertical one.

The Rigol, with its easy to use PC interface and long memory should be quite useful for post processing, where you can do any kind of calculation, based on standards or not.
 

[chscholz]

Thank you saturation.

Screenshots are form a LeCroy WaveMaster 830Zi-A scope but it works exactly the same down to a WaveSurfer, (200 MHz through 45 GHz scopes). All of these scopes are run MS Windows.

Chris

@chscholz:

Most excellent.  IEEE 181 makes a whole lot of sense, which scopes today use the standards when making automated measurements?  What is the source of your graphs?

There is no mention of 181 in the Rigol documentation.  Empirically, if were true but undocumented, the measurements would not vary with timebase.

I've seen some reactions to the various editions of 181, it seems its more common in higher end scopes, or scopes with full Windows OS or similar OS based scopes that have more storage and hardware to make these postprocess calculations.

[saturation]

Wow, thank you too chscholz.

My god  , that's a $100,000 scope!  Supposedly the world's fastest last year!
 i


Just compare, its like a Ferrari vs a Traban!



http://www.prnewswire.com/news-releases/lecroys-wavemaster-830-zi-oscilloscope-wins-2010-designvision-award-for-test-and-measurement-equipment-83553042.html

It cost more than my house!

What a scope, stuff only dreams are made off.  

Thank you saturation.

Screenshots are form a LeCroy WaveMaster 830Zi-A scope but it works exactly the same down to a WaveSurfer, (200 MHz through 45 GHz scopes). All of these scopes are run MS Windows.

Chris

@chscholz:

Most excellent.  IEEE 181 makes a whole lot of sense, which scopes today use the standards when making automated measurements?  What is the source of your graphs?

There is no mention of 181 in the Rigol documentation.  Empirically, if were true but undocumented, the measurements would not vary with timebase.

I've seen some reactions to the various editions of 181, it seems its more common in higher end scopes, or scopes with full Windows OS or similar OS based scopes that have more storage and hardware to make these postprocess calculations.

[scrat]

One needs the right scale to measure the right size accurately, without it each cycle in the signal cannot be isolated, and so frequency cannot be calculated from its meaning, "cycles per second."

The Rigol measures as best as its hardware can provide.  Its not necessarily related to the resolution of its vertical or horizontal axes.

Even if you can see more, the vertical axis will be drowned by noise caused by the limits of an 8 bit ADC.  So even if the Rigol can present more on the scope, it likely won't be meaningful even with post processing.  However, maybe your external software can do a better job at measurement than the algorithm used by Rigol.

The theoretical maximum is given by were N= ADC bits:



For the Rigol, this becomes -49.92 dB.  Roughly, it will not be possible to discern signals from noise below 3mV, looking say at 1V signals, even if the Rigol can do 2mV/div.

The X axis is limited by Nyquist frequency, which is tied to the sampling speed, and the sampling speed is tied to the memory length for each timebase you select.

The Rigol will 'auto' adjust the sampling speed to compensate for the memory length selected or on auto mode, it prioritizes the sampling speed and uses the short memory length.  So even if the scope can do 5ns/div timebase, its top sampling speed is 1Gs/s, so its practical frequency limit is ~ Samples/10, or 100MHz.  This makes the 1052E viable as a hack version, since it has nearly the same hardware as the 1102E.

However, if you use 2 channels, the sampling speed is halved, to 500Ms/s; if you select high memory length, its halved once again to 250 Ms/s, and thus its practical frequency response in its worse case scenario is ~ 25 MHz.

Not only the freq measurement value slightly changes between different time bases and different captures, but the feature simply doesn't work if the time base is too large (too much time on screen), since it doesn't recognize the edges of the signal. It gives results which move around the submultiples of the real frequency.

I haven't read the specs of the Rigol, but usually DSOs have a quite good horizontal precision, besides their vertical one.

The Rigol, with its easy to use PC interface and long memory should be quite useful for post processing, where you can do any kind of calculation, based on standards or not.
 

Maybe I was wrong using the auto triggering, thus limiting the memory depth...
However, the thing I find strange is that the measurement is based on the points plotted. Since the points drawn on screen are much less than those in memory (even for low memory), if the edges get confused on screen doesn't automatically mean that there aren't enough samples in memory (at sufficient rate) to allow to read frequency.
For example, on the Tek at the lab I could correctly measure the frequency even if the displayed waveform was "unreadable".

About post processing, besides the fact that high enough sampling frequency and time length are needed (that's math!), averaging measures (both vertical and horizontal) on many periods allow to reduce measurement error (generally speaking it falls with sqrt of the number of measurements). For frequency and phase, for example, filtering, squaring (with hysteresis), averaging among some periods and "Fourier" analysis worked quite well for a measurement I needed. This won't surely be possible using the scope's functions (even if it was a mid end Tek).

[saturation]

Auto will set the basic Y X axes for you, but after the signal is presented, you are now in manual mode; you can reset Y gain, X timebase, and set memory depth manually, and this will preselect sampling rate.  Its important to know and use this to reduce error as the sampling rate drops when you use longer timebases.  See menu under horizontal controls.

Measures from points plotted is low cost solution, separates the 'Ferrari' or maybe a BMW level scopes versus the Traban.  Without auto measurements, you'd do it manually, and to do it manually you can only eyeball the waveform limits using the div markers for a scale, since this is based on the screen presentation, Rigol's algorithm simulates what you'd do by hand, so its workable.

Tek <> Rigol, $$$$ <> $$. 

From what you describe, your Tek has a more accurate measurement capacity, I wouldn't be surprised if its IEEE 181 compliant.

Maybe I was wrong using the auto triggering, thus limiting the memory depth...
However, the thing I find strange is that the measurement is based on the points plotted. Since the points drawn on screen are much less than those in memory (even for low memory), if the edges get confused on screen doesn't automatically mean that there aren't enough samples in memory (at sufficient rate) to allow to read frequency.
For example, on the Tek at the lab I could correctly measure the frequency even if the displayed waveform was "unreadable".

About post processing, besides the fact that high enough sampling frequency and time length are needed (that's math!), averaging measures (both vertical and horizontal) on many periods allow to reduce measurement error (generally speaking it falls with sqrt of the number of measurements). For frequency and phase, for example, filtering, squaring (with hysteresis), averaging among some periods and "Fourier" analysis worked quite well for a measurement I needed. This won't surely be possible using the scope's functions (even if it was a mid end Tek).

[scrat]

As an Italian I must say you're right, especially about Ferrari's superiority over other cars ...

I intended to point that, IMHO, working out the measurements on the memory and not the displayed samples should not have added too much cost, while resulting in a far more reliable function.
Another thing that, despite its low cost, also "BMW" scopes don't have is a resolution (sampling rate) manual setting: the actual rate is fixed for each time base (and memory, if there are different options). A lower resolution than the maximum, although could help the user to fall into mistakes because of aliasing, could allow a higher triggering rate (a narrower "dead" or holdoff time for calculation) if needed.

However, that's it, I'm happy for how the Rigol works, even if I haven't had too much time to play with it.
Tektronix usually gives so many specs, that the Rigol don't mention... but price makes the Rigol a good machine.

[chscholz]

Still the fastest clocking in at 45 GHz, 120 GS/s, 768 Mpts/Ch Analysis Memory (and shipping in quantities today).

Wow, thank you too chscholz.

 Supposedly the world's fastest last year!
 [...]

[chscholz]

Yes, you would think so but it is not quite that simple if your computing platform is a few years old and does not provide sufficient processing power. Hardware needs to be upgraded, software needs to support multi-processor architectures etc.

I intended to point that, IMHO, working out the measurements on the memory and not the displayed samples should not have added too much cost, while resulting in a far more reliable function.

[saturation]

FWIW on the Rigol, on the Acquire button, you can select memory depth from normal to long, set the sampling time from real to equivalent and turn off/on Sinx/x, regardless of timebase.  The sampling rate dynamically adjusts to the options selected.  You can then see the effect on sampling time by hitting Menu button on the Horizontal controls.  By playing with these in combination, you can reduce aliasing to its lowest possibility.

To help improve the appearance of your signal, you can then adjust Acquire->Acquisition from normal, peak or average to reduce noise.

I also use Display to select dots or vectors to see what the actual data points from the sampling to insure the Rigol interpolation is realistic.  

As an Italian I must say you're right, especially about Ferrari's superiority over other cars ...

I intended to point that, IMHO, working out the measurements on the memory and not the displayed samples should not have added too much cost, while resulting in a far more reliable function.
Another thing that, despite its low cost, also "BMW" scopes don't have is a resolution (sampling rate) manual setting: the actual rate is fixed for each time base (and memory, if there are different options). A lower resolution than the maximum, although could help the user to fall into mistakes because of aliasing, could allow a higher triggering rate (a narrower "dead" or holdoff time for calculation) if needed.

However, that's it, I'm happy for how the Rigol works, even if I haven't had too much time to play with it.
Tektronix usually gives so many specs, that the Rigol don't mention... but price makes the Rigol a good machine.