REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol

[mtdoc]

IMO the improvements in the latest FW are way more valuable than the ~50MHz of extra BW you may be getting with that old FW version.

Thanks, you're probably right. Is there a list of all the improvements in the new firmware?

i've seen some different improvements mentioned but no comprehensive list.

[marmad]

Thanks, you're probably right. Is there a list of all the improvements in the new firmware?

Nothing from Rigol unfortunately. These are all (IIRC) that have been noted by users so far:

New feature: Manual cursors has DisplayMode X-Y.
New feature: Cursors in X-Y mode.
New feature (as option): CAN trigger and decode.
Bug fix: RS-232 baud rate at AUTO 57600.
Bug fix: Bus decoding of full ASCII character set.
Improved: Faster waveform update rates at lower time bases.
Improved: Intensity grading in Delayed Sweep (Zoom) mode.
Improved: FFT functioning.

[elecBlu]

Marmad already stated a few posts back, the non A models where not good enough for 300 Mhz.
they had to modify the entry in the A models.

maybe, but all tests so far were at HW 1.0, there were actually some noticeable board/ input stage changes in the non-A HW 2.0. So it is to early to say that for all the non-A models!

[marmad]

maybe, but all tests so far were at HW 1.0, there were actually some noticeable board/ input stage changes in the non-A HW 2.0. So it is to early to say that for all the non-A models!

I'm fairly sure Wim meant HW v.1 non-A models (which the vast majority of us owners posting here are) - since there weren't nearly as many HW v.2 non-A models sold. It's obvious Rigol got the new PCB design kinks worked out while supplying the back-orders for the original model.

It's quite certain that the HW v.2 models will have a better frequency response - perhaps the same as A-models.

[Wim13]

All bandwidth measurements are made on the same 2072, with hardware version 1.0.1.0.0
i corrected the chart.

sorry for the confusion, there are three major hardware versions on this moment
DS2000 with hw 1.0... DS2000 hw 2.0..  and DS2000A  hw 2.0 with 50 ohm switch.

[marmad]

My old TEK TDS3032 has 2.5 GS/s and 5 samples per division with 1 ns time base. It is so regardlss whether both or only one channel is on.

But that doesn't make sense mathematically. If 2.5GSa/s is the maximum rate, 400ps is the smallest sample period. That would be 2.5 samples per div @ 1ns. 5 samples per div would require a 5GSa/s rate (200ps sample).

[marmad]

I do not know about the math, but look at the picture.

Math is math; there is no getting around it. Drawing dots on a display is something else.

Either one of the following HAS to be true:
1) Your DSO samples at a maximum of 2.5G and it gets a sample every 400ps - and then, for whatever reason, it's doubling the number of actual sample points it draws on the screen.
2) Your DSO, for whatever reason, has the 5GSa/s rate of the TDS3052, and it gets a sample every 200ps. Then the number of points on the screen equals the actual real sampling rate.

[Carrington]

Math is math; there is no getting around it. Drawing dots on a display is something else.

Either one of the following HAS to be true:
1) Your DSO samples at a maximum of 2.5G and it gets a sample every 400ps - and then, for whatever reason, it's doubling the number of actual sample points it draws on the screen.
2) Your DSO, for whatever reason, has the 5GSa/s rate of the TDS3052, and it gets a sample every 200ps. Then the number of points on the screen equals the actual real sampling rate.

Maybe it's magic...

No seriously, as Marmad says: "Math is math".

[Carrington]

Well, I guess it's technically a bug - but in an unimplemented - and perhaps unfinished? - portion of firmware. So not very relevant.

EDIT: BTW, does not happen when saving via RUU.

I agree is true, it is not relevant.
RUU -> Superb work. 

[EV]

OK, I have deleted my posts.

from Tek 3032B Manual
Separate Digitizers. Ensure accurate timing measurements with
separate digitizers for each channel. Each digitizer can sample at up
to the maximum sample rate (2.5GSa/s); acquisition on all channels is always
concurrent to provide full single-shot bandwidth on each channel.

So IMO, Tek is  combining samples from 2 channels,
if so Let's deleted all this dicussion, Please

[EV]

Traces when using type as dots or vectors look quite different. Why?
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.

[marmad]

from Tek 3032B Manual
Separate Digitizers. Ensure accurate timing measurements with
separate digitizers for each channel. Each digitizer can sample at up
to the maximum sample rate (2.5GSa/s); acquisition on all channels is always
concurrent to provide full single-shot bandwidth on each channel.

So IMO, Tek is  combining samples from 2 channels,
if so Let's deleted all this dicussion, Please

This didn't really solve the mystery - since EV had posted an image with both channels on and samples displayed every 200ps. There is no way the scope could combine samples to do that; it's impossible (it could do it for 1 channel - but not for both). Anyway, we don't necessarily need to discuss it further here - but if I was EV, I'd probably do some tests to figure out exactly what my real max. sample rate was.

[Hydrawerk]

Traces when using type as dots or vectors look quite different. Why?
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.

It looks like a sinx/x interpolation, but it is weird.

[EV]

I noticed it already here:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/1785/
There time base is 2 ns.

Wim13 explained then:
"There is always something like cross talk between channels.
To the book Rigol claims cross talk between ch1 and 2 better then 40 dB"

I however now noticed that there is not this trasition in the Dots picture. The trace there looks same as if Ch2 is not on.

Traces when using type as dots or vectors look quite different. Why?
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.

It looks like a sinx/x interpolation, but it is weird.

[JDubU]

I noticed it already here:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/1785/
There time base is 2 ns.

Wim13 explained then:
"There is always something like cross talk between channels.
To the book Rigol claims cross talk between ch1 and 2 better then 40 dB"

I however now noticed that there is not this trasition in the Dots picture. The trace there looks same as if Ch2 is not on.

Traces when using type as dots or vectors look quite different. Why?
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.

It looks like a sinx/x interpolation, but it is weird.

There seems to be a problem with the sample-to-display interpolation algorithm (sin(x)/x) when the horizontal time base is faster than about 20ns/div.
The dots display looks reasonable but the vector display introduces interpolation artifacts when the distance between sample points spans a larger number of pixels on the display.  This can be seen more easily in single sweep mode.  The dots reliably form a smooth curve but the vectors tend to "zig zag" between adjacent sample points with multiple 2 or 3 pixel steps in opposite directions as the trace moves from one sample point to the next.  On a free running sweep, these display artifacts appear as a noisier trace.

This also partially explains why enabling CH2 increases the apparent noise on CH1.  The sampling rate is cut in half causing the distance between sample points to double (producing more display artifacts) for a given time base setting.

[EV]

Thanks JDubU! This sounds good explanation.

There seems to be a problem with the sample-to-display interpolation algorithm (sin(x)/x) when the horizontal time base is faster than about 20ns/div.
The dots display looks reasonable but the vector display introduces interpolation artifacts when the distance between sample points spans a larger number of pixels on the display.  This can be seen more easily in single sweep mode.  The dots reliably form a smooth curve but the vectors tend to "zig zag" between adjacent sample points with multiple 2 or 3 pixel steps in opposite directions as the trace moves from one sample point to the next.  On a free running sweep, these display artifacts appear as a noisier trace.

This also explains why enabling CH2 increases the apparent noise on CH1.  The sampling rate is cut in half causing the distance between sample points to double (producing more display artifacts) for a given time base setting.

[marmad]

There seems to be a problem with the sample-to-display interpolation algorithm (sin(x)/x) when the horizontal time base is faster than about 20ns/div.

I haven't noticed this. Can you post some documentation to illustrate?

[marmad]

Note that the steps are multiple display pixels high....

By multiple, do you mean a multiple of 2? The Rigol maps 200 possible ADC values to a 400 pixel high display - steps are ALWAYS a minimum of 2 pixels - it doesn't matter what time base or interpolation method you use.

...with several examples of inappropriate direction reversals between sample points.

What you're talking about here is noise fluctuation between 3-4 quantization levels (which is 1-2 bits); normal on digital oscilloscopes. This has nothing to do with sin(x)/x - and can be found at every time base if you STOP the DSO and 'zoom' in on the trace with vertical scale.

[JDubU]

Note that the steps are multiple display pixels high....

By multiple, do you mean a multiple of 2? The Rigol maps 200 possible ADC values to a 400 pixel high display - steps are ALWAYS a minimum of 2 pixels - it doesn't matter what time base or interpolation method you use.

...with several examples of inappropriate direction reversals between sample points.

What you're talking about here is noise fluctuation between 3-4 quantization levels (which is 1-2 bits); normal on digital oscilloscopes. This has nothing to do with sin(x)/x - and can be found at every time base if you STOP the DSO and 'zoom' in on the trace with vertical scale.

By multiple, I mean that the available vertical display resolution is not being used to its best advantage by the interpolation algorithm.   The individual, lower resolution ADC values may map to locations that are separated by multiple display pixels, but the interpolated trace that connects them is not limited to the resolution of the ADC.  The interpolation algorithm should produce smooth traces that fully utilize the available vertical resolution of the display. 

[marmad]

By multiple, I mean that the available vertical display resolution is not being used to its best advantage by the interpolation algorithm.   The individual, lower resolution ADC values may map to locations that are separated by multiple display pixels, but the interpolated trace that connects them is not limited to the resolution of the ADC.  The interpolation algorithm should produce smooth traces that fully utilize the available vertical resolution of the display.

All of the interpolation is done on the original 8-bit values - with scaling for the display done as the last stage of the process (which I believe most lower-prices DSOs do - see attached image from Agilent X-3000 showing a minimum of 2 pixel steps - and even some quantization error at the top of the second sine wave). This method also guarantees that the display memory produces 8-bit values when read by another device.

In any case, what you've pointed out is not a 'problem with the sample-to-display interpolation algorithm' - it's the way it's normally done - and while your suggestion would lead to a nicer looking waveform when the DSO was stopped, it would definitely be slower.

[JDubU]

By multiple, I mean that the available vertical display resolution is not being used to its best advantage by the interpolation algorithm.   The individual, lower resolution ADC values may map to locations that are separated by multiple display pixels, but the interpolated trace that connects them is not limited to the resolution of the ADC.  The interpolation algorithm should produce smooth traces that fully utilize the available vertical resolution of the display.

All of the interpolation is done on the original 8-bit values - with scaling for the display done as the last stage of the process (which I believe most lower-prices DSOs do - see attached image from Agilent X-3000 showing a minimum of 2 pixel steps - and even some quantization error at the top of the second sine wave). This method also guarantees that the display memory produces 8-bit values when read by another device.

In any case, what you've pointed out is not a 'problem with the sample-to-display interpolation algorithm' - it's the way it's normally done - and while your suggestion would lead to a nicer looking waveform when the DSO was stopped, it would definitely be slower.

The problem is that the interpolation algorithm is adding the appearance of higher frequency content than what the ADC is actually measuring.  The ADC is only producing the "dots" display.  Everything in between the dots in the vector display should be as close to an estimate of what the waveform looks like as possible.  This is the role of the sin(x)/x convolution window which attempts to use Nyquist criteria to reasonably interpolate what the actual waveform is doing between measured sample points.  Since these are simply mathematically derived estimates and not measured, there is no reason that there should be higher frequency content in the interpolation than there is in the dots display itself.   It seems like what is happening (and what you describe) is that the interpolation is rounding off to the nearest of the 256 quantization levels of the ADC rather than to the 400 level vertical resolution of the display and then linearly scaling (with more roundoff error) to the vertical display resolution.

[marmad]

The problem is that the interpolation algorithm is adding the appearance of higher frequency content than what the ADC is actually measuring.  The ADC is only producing the "dots" display.  Everything in between the dots in the vector display should be as close to an estimate of what the waveform looks like as possible.  This is the role of the sin(x)/x convolution window which attempts to use Nyquist criteria to reasonably interpolate what the actual waveform is doing between measured sample points.  Since these are simply mathematically derived estimates and not measured, there is no reason that there should be higher frequency content in the interpolation than there is in the dots display itself.   It seems like what is happening (and what you describe) is that the interpolation is rounding off to the nearest of the 256 quantization levels of the ADC rather than to the 400 level vertical resolution of the display and then linearly scaling (with more roundoff error) to the vertical display resolution.

I don't agree that there is higher frequency content added: there is quantization and rounding error - again, visible in the Agilent's screen capture as well - and within the error bounds of the DSO. But it seems to me you have a very simplified idea about how the captured samples end up as interpolated display. If vectors are ON, the display memory ALWAYS contains 1400 bytes (700 vectors) - it doesn't matter if the ADC captures 14M - or - 28 samples during the acquisition window. There are a WHOLE bunch of steps involved in arriving at those 1400 bytes - just one of which is the actual sin(x)/x or linear interpolation algorithm.

But anyway, it's late and I'm done here - if you want to believe there is a problem with the Rigol, fine by me. 

[JDubU]

The problem is that the interpolation algorithm is adding the appearance of higher frequency content than what the ADC is actually measuring.  The ADC is only producing the "dots" display.  Everything in between the dots in the vector display should be as close to an estimate of what the waveform looks like as possible.  This is the role of the sin(x)/x convolution window which attempts to use Nyquist criteria to reasonably interpolate what the actual waveform is doing between measured sample points.  Since these are simply mathematically derived estimates and not measured, there is no reason that there should be higher frequency content in the interpolation than there is in the dots display itself.   It seems like what is happening (and what you describe) is that the interpolation is rounding off to the nearest of the 256 quantization levels of the ADC rather than to the 400 level vertical resolution of the display and then linearly scaling (with more roundoff error) to the vertical display resolution.

I don't agree that there is higher frequency content added: there is quantization and rounding error - again, visible in the Agilent's screen capture as well - and within the error bounds of the DSO. But it seems to me you have a very simplified idea about how the captured samples end up as interpolated display. If vectors are ON, the display memory ALWAYS contains 1400 bytes (700 vectors) - it doesn't matter if the ADC captures 14M - or - 28 samples during the acquisition window. There are a WHOLE bunch of steps involved in arriving at those 1400 bytes - just one of which is the actual sin(x)/x or linear interpolation algorithm.

But anyway, it's late and I'm done here - if you want to believe there is a problem with the Rigol, fine by me. 

Thanks for the discussion Marmad.
Have a good night.   

[Teneyes]

Here are displays showing how variations in the trigger timing result in sample dots occuring at different points along the sin wave curve. With the noise the dots are shown as streaks and clusters
The displays
1. Shows input as a display in vectors
2. Shows input as a display of dots
3. Shows input as a display of dots SINGLE scan
4. Shows input as a display of dots with trigger level higher and there is a streak of dots
5. Shows input as a display of 1 small cluster of dots with trigger level higher
6. Shows input as a display of 3 small cluster of dots at some conditions.
7. Shows input as a display of 3 small cluster of dots under some conditions. With 'Trigger out' fed into chan 2

I hope this helps explain how the DS2000 operates.

Is the variations of the trigger point by design, or an effect of noise & clock variations??

[cyr]

Not quite sure I understand your question, but of course the sample points will be at different points on the signal unless it happens to be perfectly synchronized with the sampling clock of the scope...