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

[marmad]

Anti-aliasing is also done sample->display time, and it's almost useless since the "normal" sample->display decimation algorithm rarely introduces aliasing. And in high res, it actually tends to make aliasing worse!  What most people expect anti-aliasing to do, ie minimize sample-rate induced aliasing, Rigol's anti-aliasing cannot do.  It can make the display a little nicer looking sometimes, but I think it's generally a waste of update rate.

Yes, and Agilent's (well, it really came from HP) clever anti-aliasing technique - which could be used between the sample memory and display if oversampling - seems to be patented. I wonder if any other DSO manufacturers are using HP's technique?

[Teneyes]

I am more interested in the ANTI-ALIASING option, I would like to know how RIGOL implemented it, what sampling method used etc...

@Carrington
  Yes Marmad and Galaxyrise have discussed this back at:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg242861/#msg242861

[marmad]

By limiting the BW seems to be designed for audio applications, or something like that.

@Carrington: The bandwidth is automatically lowered by the High Res technique itself. As mentioned before, best case BW for a 2GSa/s DSO averaging to 12 bits is ~3.3MHz (0.433 * 2G / 256). In fact, calling it "High Resolution" is a bit of a marketing ploy - since it's really just a smoothing filter. The "12 bits" of resolution" are effective bits - since the displays on these cheaper 8-bit DSOs don't even have 9 bits of vertical resolution anyway. So the averaging is done to a 12-bit value - then downsampled to 8 bits again for display.

I think it would make more sense - and be more clear for people - if instead of calling the two acquisition modes "Average" and "High Res", they were called something like "Waveform Average" and "Sample Average".

I am more interested in the ANTI-ALIASING option, I would like to know how RIGOL implemented it, what sampling method used etc...

It seems to be some simple technique for reducing moire patterns on the screen - but totally worthless to eliminate real DSO aliases. If you're worried about aliasing, the best bet on the DS2000 is to use the AUTO or 56MB memory depths to keep the sample rate as fast as possible at slower time base settings.

[Galaxyrise]

This makes perfect sense since the stored frames are the waveforms constructed from the already-averaged samples (with the original samples no longer available). OTOH, when the DSO is stopped (when not in Record), the last group of captured samples still sits in sample memory - so the DSO can apply (or not apply) the averaging to the display memory by turning High Res on or off.

I had assumed that the raw samples were written to segmented memory, which would mean that the scope had to apply the high res algorithm to segmented memory in order for it to work at all in that mode, and thus there was no good reason not to enable changing between normal and high res on recorded data.

So I tested this. I generated the fastest pulse my sig gen could do, which was 32 samples at 2GSa/s.  I recorded this in high res at 5us/div.  Naturally, the display at that timebase was severely attenuated.  But zooming in to the recorded data was just like zooming in on a single waveform capture; all the data is there, confirming my assumption that the recorded data is the same in both modes.

There's a practical difference between the two approaches and it affects record mode: You get to store fewer waveforms if you want the high res averaging.

I'm not sure I understand you: on my DSO I haven't noticed any difference in the maximum frames I can record when using High Res mode.

I don't mean that turning on high res changes the record length for a particular memory depth, I mean that you have to use a larger memory depth to give the algorithm enough samples to average. If I want to capture 14k points per waveform, and I want each of those points to be the result of averaging >8 samples, then I actually need to capture at 140k pts. 

But really, I would expect a difference between the algorithms any time the scope increases its time between stored samples.  Averaging 16 consecutive points that were sampled 1ns apart produces very different results from averaging 16 consecutive points that were sampled 1us apart.  I'm pretty sure the latter is what Rigol does, and so even the aforementioned 140k pts could produce different results than 14k pts of acquire-time averaging.

[Svuppe]

I'd be curious to know what the bandwidth of the High Res mode is at each time base setting between 50us/div - 10ms/div in the Agilent 2000 X-Series.

I tested that last night on my 2000X, which has the optional 1M memory option.

Time base   Bandwidth (-3db)  -   First null in stopband

10ms/div   ~34kHz   ~77kHz
5ms/div   67.87kHz   153.6kHz
2ms/div   169.6kHz   384.0kHz
1ms/div   339kHz   768.0kHz
500us/div   676.7kHz   1.536MHz
200us/div   1.689MHz   3.840MHz
100us/div   3.364MHz   7.680MHz
50us/div   6.704MHz   15.36MHz
20us/div   16.87MHz   ?
10us/div   ?      ?
5us/div   ?      ?

I used the built-in waveform generator, which only goes to 20 MHz, so I couldn't get the last few measurements.
Hmm, I can't get the table to align nicely. I hope it is readable anyway.

[marmad]

I tested that last night on my 2000X, which has the optional 1M memory option.

@Svuppe: Fantastic! Thanks so much for doing that!

I used the built-in waveform generator, which only goes to 20 MHz, so I couldn't get the last few measurements.

Don't worry, my table was quickly done - and isn't super-accurate since I don't have an FG that generates a very precise sweep.

But this shows that the filtering caused by successive sample averaging is comparable on both DSOs - and NOT caused by the way that Rigol performs it (as continually asserted by evanh). The tables are quite similar, with the Agilent's being shifted down by 3 time bases - which corresponds to the fact that it starts full 12-bit averaging at a slower time base than the Rigol.

[evanh]

High-res acquisition mode operates in oversampling only

No, it CAN use oversampling - but it's not a prerequisite. Just look at the specs for the Agilent 2000 X-Series High Res mode at the following time base settings:

It is a prerequisite for high-res acquisition.

...
Successive sample averaging ("High Res") is purely a math operation on either incoming or stored samples - oversampling can be used, but it's not a necessity.

* evanh goes googles for user manual ...

Agilent has nice website  ...  Okay quoting the 2000 X manual:
"High Resolution — at slower time/div settings, all samples in the effective sample period are averaged and the average value is stored."

That's pretty clear cut.  It only filters the oversampled data.  There is zero filtering of the stored trace.

Rigol doesn't do this, so, although it is high-res, it's not an acquisition mode.

Oh, so now you're admitting that the Rigol IS doing successive sample averaging? Just that it's not an "acquisition mode"?   

I've never said otherwise.  The only comment I've made is that the maths is not the issue.  The real issue is the lack of oversampling and the filtering cutting into the displayed trace.

[Carrington]

@Teneyes
@Marmad
@Svuppe

Thank you very much for all the info.
Cool people make a cool forum.  :-

[Teneyes]

I can't get the table to align nicely. I hope it is readable anyway.

Time base   Bandwidth (-3db)  -   First null in stopband

 10ms/div     ~34kHz     ~77kHz
  5ms/div    67.8kHz   153.6kHz
  2ms/div   169.6kHz   384.0kHz
  1ms/div   339.0kHz   768.0kHz
500us/div   676.7kHz   1.536MHz
200us/div   1.689MHz   3.840MHz
100us/div   3.364MHz   7.680MHz
 50us/div   6.704MHz   15.36MHz
 20us/div   16.87MHz       ?
 10us/div       ?          ?
  5us/div       ?          ?

@ Svuppe use Courier Font for Fixed Spacing

[Carrington]

@Svuppe
Just curious:
You know if the DSOX2000 series gives their maximum waveforms per seconds with auto memory only, or with maximum memory too?
Thanks. 

[marmad]

It is a prerequisite for high-res acquisition.

When you use the term "oversampling", what exactly are you referring to? Do you mean a sample rate higher than what is normally used at a given time base (which would be the normal definition in this context)? If so, as already pointed out (and ignored by you), the normal sample rate of the Agilent @ 5us/div is 2GSa/s.

So what happens when you turn on High Res at that time base? Does the Agilent start sampling faster than 2GSa/s? Of course not - it can't! All it does is start adding the incoming samples together - so it's not sampling "over" (above) the given rate; it's just trading off bandwidth for 'effective' resolution. This is exactly what the Rigol (DS2000) does when set to 5us/div @ 2GSa/s - it just saves the samples first before adding them together later.

So in your mind, in this example - are they both "oversampling" - or is neither? They are both sampling @ 2GSa/s and combining the acquired samples.

I've never said otherwise.  The only comment I've made is that the maths is not the issue.  The real issue is the lack of oversampling and the filtering cutting into the displayed trace.

  Seriously? Wow, you must be the most stubborn person on this forum (which is saying a lot). You wrote several assertions which have already been proven incorrect with data- such as:

....and what's more (Rigol) doesn't even say how severe this filter is let alone have any parameters.

Well, ignoring the fact that Agilent ALSO doesn't say how severe their filter is: Yes, there ARE parameters; they follow the basic filter formula for successive sample averaging; and they are quite predictable.

...(Agilent) need not create any extra filtering beyond the stored sample rate ... and probably ensures it never does by adjusting the bit depth accordingly.

It's obvious from the real data that Svuppe and I posted that the filtering is quite similar between the Agilent 2000X and Rigol DS2000 - with the tables shifted based on the decision by each DSO manufacturer as to which time base to use when implementing 12-bit averaging.

That's the difference (between Agilent and Rigol) and it's significant.

NO - you were wrong: the difference is NOT significant. Ignore or deny it all you want (and having interacted with you before - I'm guessing you will), but I'm confident it's clear to anyone else reading these posts.

EDIT: Yep - as predicted: ignored 

[Svuppe]

I don't believe there is anything called auto memory. At least I haven't found it yet.

[Carrington]

I don't believe there is anything called auto memory. At least I haven't found it yet.

Ok.

The DS2K auto set the memory according with the base time.

Time/Div  Auto Menory (One channel)
1ks             14M
...
500us         14M
200us         5M6
100us         2M8
50us           1M4
20us           560K
10us           280K
5us             140K
2us             56K
1us             28K
500ns         14K
200ns         5K6
100ns         2K8
50ns           1K4
20ns           700
10ns           700
5ns             700

[marmad]

The High Res BW table I made for the DS2000 is really rather crude - I just don't own a decent FG/AWG, so many of the values are approximations.

@Teneyes: Perhaps you can run the sweep tests again using a decent FG/AWG)?  I think you have a DG4000 series, right? 

Just make sure you test with memory depth set to 14MB or AUTO!

[Carrington]

I only have a digital pattern generator from my omega logic analyzer, so I can't do it.

[Teneyes]

Agilent has a nice demo of using High Res ,
to see small pulse in the noise of a Sine wave.
 
Has anyone seen a Rigol Demo of High res?
I would think the Rigol responds the same.

[Carrington]

I don't believe there is anything called auto memory. At least I haven't found it yet.

See at min:2.29.

[Carrington]

About Agilent High Resolution:

[Svuppe]

I don't believe there is anything called auto memory. At least I haven't found it yet.

See at min:2.29.

Well ok. I guess you could call that auto memory. But returning to your original question:

You know if the DSOX2000 series gives their maximum waveforms per seconds with auto memory only, or with maximum memory too?

There is no user-setting that lets you select between auto and max. The Agilent ALWAYS use the maximum available memory if possible with regards to the timebase.
If you have the segmented memory option, you could limit the memory use that way. However as segmented memory is used for single-shot events, it can't be used to manipulate the speed of continuous waveform updates.

[evanh]

About Agilent High Resolution:

Interesting.  So, Agilent are doing more than they say in the description of their High-Res acquisiton mode.  I guess that could be explained by the fact that the "more" is a display rendering function separate from acquisition.

As the commentator says right at the start, it's something to be wary of ... I guess I've been spoilt up till now.

[marmad]

As the commentator says right at the start...

By commentator, do you mean Dave - the owner and operator of this forum and EEVBlog? 


Anyway... back to measured data:

I did a more precise measurement of the BWs of the DS2000 - and came up with the following table comparing the DSO-2000X and DS2000 High Res implementations:


           Rigol DS2000 series                             Agilent DSO-2000X series (based on Svuppe's data)
Time base  BW (-3dB)  Eff.SR   Bytes Averaged  Eff.Bits    BW (-3dB)  Eff.SR  Bytes Averaged  Eff.Bits

100ms/div  429Hz      250kHz   256 bytes       12 bits     ?
50ms/div   859Hz      500kHz   256 bytes       12 bits     ?
20ms/div   2.1kHz     1.25MHz  256 bytes       12 bits     ?
10ms/div   4.3kHz     2.5MHz   256 bytes       12 bits     34kHz      25MHz   ~325 bytes      12 bits
5ms/div    8.6kHz     5MHz     256 bytes       12 bits     67.87kHz   50MHz   ~325 bytes      12 bits
2ms/div    21.5kHz    12.5MHz  256 bytes       12 bits     169.6kHz   125MHz  ~325 bytes      12 bits
1ms/div    42.9kHz    25MHz    256 bytes       12 bits     339kHz     250MHz  ~325 bytes      12 bits
500us/div  85.9kHz    50MHz    256 bytes       12 bits     676.7kHz   500MHz  ~325 bytes      12 bits
200us/div  171.6kHz   100MHz   256 bytes       12 bits     1.689MHz   1GHz    ~260 bytes      12 bits
100us/div  343kHz     200MHz   256 bytes       12 bits     3.364MHz   2GHz    ~260 bytes      12 bits
50us/div   686kHz     500MHz   320 bytes       12 bits     6.704MHz   2GHz    ~130 bytes      11 bits
20us/div   1.37MHz    1GHz     320 bytes       12 bits     16.87MHz   2GHz     ~52 bytes      10 bits
10us/div   2.75MHz    2GHz     320 bytes       12 bits     ?
5us/div    5.5MHz     2GHz     160 bytes       11 bits     ?
2us/div    13.75MHz   2GHz      64 bytes       11 bits     ?
1us/div    27.5MHz    2GHz      32 bytes       10 bits     ?
500ns/div  55MHz      2GHz      16 bytes       10 bits     ?

[Hydrawerk]

At DSOX2000 everything is automatic, LOL. You cannot set acquisition length, sin(x)/x interpolation, or vectors / dots. 

[marmad]

Added the following table to the first post in this thread:

Updated High Res bandwidth table here.

[Carrington]

Added the following table to the first post in this thread:

Perfect, I keep a copy, for my personal collection.
Thanks. 

[marmad]

I had assumed that the raw samples were written to segmented memory, which would mean that the scope had to apply the high res algorithm to segmented memory in order for it to work at all in that mode, and thus there was no good reason not to enable changing between normal and high res on recorded data.

@Galaxyrise: Maybe the reason you can't switch between Normal and High Res with recorded frames is because the display frames are already "compiled" from the raw samples and stored separately in display memory. That's why the DSO can play them back so quickly. The raw samples are still in sample memory - and can be read out via SCPI - but the DSO doesn't want to alter or change the compiled frames once they're stored.

But I just discovered something quite interesting when you turn on the Analyze mode in Record.

Here is an image of a recorded frame of a 780kHz sine wave @ 200us/div in Normal mode:




Here is an image of a recorded frame of a 780kHz sine wave @ 200us/div in High Res mode. The sine wave falls precisely into the second null point of the stopband filter:




Here is that same frame when in Analyze mode. You can see the filtered display frame above, but the DSO is clearly using the raw samples for the tiny frames below:




If you then Analyze based on Trace - even though the template seems different - you won't get any errors:




OTOH, if you Analyze based on Mask, you will get errors - since the Mask is built from the non-High Res samples below: