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

[Galaxyrise]

So yes, just like other manufacturers' implementations of High Resolution mode, Rigol's implementation acts exactly the same way - and will filter the waveform (and cause anti-aliasing if the effective sample rate is reduced too far for the incoming signal).

Compare these two:

and


See that the sample rate is 1Gsa/s in my screenshot, which should leave plenty of effective sample rate for a 100kHz signal.  Agilent produces the results I expected, and with far less sample rate.  As far as I can see, the Rigol is not acting the same way as the Agilent.

The complaint isn't just that "high res" happens post acquisition, but that Rigol's "one pixel per column" algorithm aliases out components that are too high frequency for the current time base.

[Tasman]

The complaint isn't just that "high res" happens post acquisition, but that Rigol's "one pixel per column" algorithm aliases out components that are too high frequency for the current time base.

What's the point of using high resolution mode for display of an envelope?  If you use normal aquisition mode the Rigol display looks exactly the same as Agilent and accomplishes all you could wish for. 

[marmad]

See that the sample rate is 1Gsa/s in my screenshot, which should leave plenty of effective sample rate for a 100kHz signal.

Using High Resolution mode applies an LPF function with a -3dB point approximated by 0.433 * sample rate / number of samples. To get 12 bits resolution, it means 4^4, or 256 samples need to be averaged, so that means the best-case (12-bit) bandwidth for either the Agilent or the Rigol when sampling at 1GSa/s is 1.69MHz (or 3.38MHz @ 2GSa/s).

Agilent produces the results I expected, and with far less sample rate.

The Agilent is displaying the number '25MSa/s' because that's the 'normal' sample rate of the DSO at the 1ms time base, but that's not what it's actually sampling at when you're in High Res mode.

As far as I can see, the Rigol is not acting the same way as the Agilent.

True, but Agilent has it's (HP-patented) anti-aliasing which is on automatically at slower time base settings, so it's hard to know exactly if it's random decimation is affecting what is displayed in that image.

It seems like the Rigol's BW in High Res mode is about equivalent to the 3.38MHz mentioned above at the 5us time base setting - then approximately reducing by a factor of 2 for each subsequent lower time base setting.

[Galaxyrise]

What's the point of using high resolution mode for display of an envelope?  If you use normal aquisition mode the Rigol display looks exactly the same as Agilent and accomplishes all you could wish for.

That example was to demonstrate the difference between algorithms; to demonstrate that Rigol's display with High Res enabled can be very different than other scopes.  If someone expects high res to act like normal but with a lower sample rate and "high res" samples, then they can be surprised on the Rigol. 

Naturally, now that I know more what it does, it can be a useful tool.  One just has to be aware that at 1ms/div + high res, the effective bandwidth (on screen) is like 5kHz.  High res is something I typically use after I've seen what it looks like in normal, and it can be great. I also like combining high res and roll mode.

[marmad]

"within the same acquisition" means oversampling.  Oversampling is done at acquisition time before storing each high-res sample.

1) Neither the Rigol DS2000 nor the Agilent X-Series can sample faster than 2GSa/s, so oversampling is meaningless if the rate is already at (or close to) this speed.

2) There is no theoretical difference between doing the averaging between acquisition and sample memory - or between sample and display memory (although it certainly can have an effect on the speed of the whole process).

3) The big problem with the Rigol is that their documentation is not clear on the subject.

It's impossible to change the memory depth on the Agilent, so at slower speeds, the number of bits of higher resolution is fixed. For example, at 5us/div it's 10 bits. But the Rigol allows user-definable memory depths, so it's obvious that it has to alter the number of bits of resolution at a given time base depending on the memory depth.

For example, according to the Rigol manual, the DSO gives "12 bits of resolution when >=5us/div @ 1GSa/s", but what happens when the sample depth is set to 14k @ 5us/div (meaning the displayed sample rate is 200MSa/s)?

It's clear the Rigol must switch to 10 (or 9) bits of resolution, and this can be observed by testing the LPF of the High Res mode while sending a 4MHz signal into the scope with those settings: 12 bits of resolution while sampling @ 200MSa/s would mean an effective bandwidth of ~338kHz.

So you MUST keep the memory depth set to 14MB (or AUTO) to get the full 12 bits of higher resolution - meaning that the DSO is sampling at the full (or nearly full) speed of 1GSa/s - 2GSa/s - at least until 1ms/div.

Yes there is a filtering effect, but this is firstly applied to the "oversampled" data rather than the final trace samples.

Six of one - half dozen of the other. It makes no difference whatsoever other than to the extent of how the successive sample decimation (High Res) is combined with the standard peak-to-peak decimation that is normally used between sample and display memory.

Naturally, now that I know more what it does, it can be a useful tool.  One just has to be aware that at 1ms/div + high res, the effective bandwidth (on screen) is like 5kHz.

That's the general idea, but you're off by a factor of about x4. The effective 3dB bandwidth (when using 14MB/AUTO + High Res) is roughly something like:
1ms = 20kHz
500us = 40kHz
200us = 100kHz
100us = 200kHz
50us = 400kHz
20us = 1MHz
10us = 2MHz
5us = 4MHz (the approx. maximum of any 2GSa/s DSO doing successive sample decimation to 12 bits)

[evanh]

Rigol's method stores only 8 bit samples.  There is never any oversampling.  It's not an acquisition mode at all.  Any "high-res'ing" is derived, at display time, from what is stored.  It can only add low-pass filtering on top of what's stored, and what's more it doesn't even say how severe this filter is let alone have any parameters.

Agilent's high-res builds the stored trace.  Agilent's method has higher bit depths per sample point which uses oversampling when suitable.  It need not create any extra filtering beyond the stored sample rate ... and probably ensures it never does by adjusting the bit depth accordingly.

That's the difference and it's significant.

I bet Rigol's method could be, but it doesn't let you, flipped on and off - refreshing the display in either Normal or High Res without any new trace acquisitions.  Where as Agilent's method has no change in display because it's purely done at acquisition time.


Evan

[marmad]

Rigol's method stores only 8 bit samples.  There is never any oversampling.  It's not an acquisition mode at all.  Any "high-res'ing" is derived, at display time, from what is stored.

Again, it makes NO DIFFERENCE whether you perform the math on already stored samples or samples as they're acquired. It's just math. I think you're hung up on believing 'acquisition mode' means that it has to happen between acquisition and sample memory - as opposed to acquisition and display.

It can only add low-pass filtering on top of what's stored, and what's more it doesn't even say how severe this filter is let alone have any parameters.

As I mentioned in my previous post, I ran some tests on the Rigol to determine the LPF bandwidth of the successive sample averaging - and it's quite predictable.

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

It automatically creates filtering by virtue of doing successive sample averaging. This is a GIVEN of the technique. Says Agilent: "High Resolution mode limits the oscilloscope's real- time bandwidth because it effectively acts like a low-pass filter."

[evanh]

The maths is not the problem.  It's the stored trace that's the problem.  One method perform oversampling and filters only to the Nyquist point and stores those high-res samples as the trace.  The other method just stores 8-bit samples straight from the ADC ... which is nyquist limited and still only 8 bits.  Any further processing cuts-off even lower.

[marmad]

The maths is not the problem.  It's the stored trace that's the problem.  One method perform oversampling and filters only to the Nyquist point and stores those high-res samples as the trace.  The other method just stores 8-bit samples straight from the ADC ... which is nyquist limited and still only 8 bits.  Any further processing cuts-off even lower.

So the Agilent X-Series is sampling faster than 2GSa/s @ 5us/div?

If the Agilent is NOT sampling faster than 2GSa/s @ 5us/div, please explain to me how the two following techniques are different:

The Agilent samples at 2GSa/s and averages every N samples into a single sample, down samples, and stores it for the display.
The Rigol samples at 2GSa/s and stores the samples. Later, it averages every N samples into a single sample, down samples, and moves it to the display.

There is no such thing as oversampling when the DSO is already sampling at it's maximum rate. I can't speak about the DS1000Z, but the Rigol DS2000 series can sample at it's maximum 2GSa/s rate down to 2ms/div - it doesn't need to oversample because the sample memory already contains all possible samples that could be captured in a given time frame.

There's obviously no difference between averaging 256 samples in a row from an ADC running @ 2GSa/s - than from averaging 256 samples in a row from samples stored in memory @ 2GSa/s.

[Galaxyrise]

I bet Rigol's method could be, but it doesn't let you, flipped on and off - refreshing the display in either Normal or High Res without any new trace acquisitions. 

I think this is a clue to Evan's issue.  As far as I know, the only time Rigol doesn't let you change the High Res setting on existing data is in record mode.  It absolutely does let you change the setting when stopped normally.

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. This bothered me at first, too, but it's never actually mattered to me in practice.

Does Agilent's trigger ever use the high res data? That's another possible difference.

[marmad]

As far as I know, the only time Rigol doesn't let you change the High Res setting on existing data is in record mode.  It absolutely does let you change the setting when stopped normally.

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.

It seems to me there is some strange idea about "oversampling". Oversampling, in this context, just means using the samples which would be otherwise ignored or discarded when using a time base that normally requires a slower sampling rate than the maximum 2GSa/s rate.

For example, running the Agilent @ 500us/div gives you a nominal sample rate of 50MSa/s (with it discarding 39 out of every 40 samples). Turning on High Res mode just makes the DSO start averaging together the samples it would normally have discarded (thus the "oversampling"). Running the Rigol @ 500us/div and a 14MB memory depth gives you a 2GSa/s rate, with all of the samples ready to be averaged saved into sample memory.

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.

[Galaxyrise]

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 admit I'm operating on some assumptions there; I'll do some experiments in the next day or two and get back to you.

[marmad]

I admit I'm operating on some assumptions there; I'll do some experiments in the next day or two and get back to you.

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.

Some of it you can calculate based on their published specs, such as 20us/div = 12 bits = 3.4MHz BW - but I'm curious if that bandwidth remains the same until 5ms/div - when it clearly must be lower due to the fact that the DSO must discard more samples than the 256 needed for 12-bit averaging.

I wish there were owners of that DSO who did as much testing and publishing about it as we have done for the Rigol DS2000. Although Agilent is, of course, much better than Rigol at providing information, even they tend to be rather tight-lipped about any drawbacks/weaknesses of certain features.

[Teneyes]

I wish there were owners of that Agilent DSO who did testing

A short report:  I was down south, in Silicon Valley, and checked a large electronics store (Frys), and I saw a:  AGILENT DSO1052B 50MHz Oscilloscope, 2-channels for sale at $790

I laughed,  and informed the sale person, they better check on the Rigol DSO's
The sale person asked me to write the info down for them.
I foresee Agilent dropping out of the lower end market.

[marmad]

I foresee Agilent dropping out of the lower end market.

I don't know... Agilent has a good product in the X-Series and they've already done all of the development. It may be that they will just lower their prices on that line.

[marmad]

See that the sample rate is 1Gsa/s in my screenshot, which should leave plenty of effective sample rate for a 100kHz signal.

@Galaxyrise: Interestingly, the reason the 100kHz signal is so attenuated in the image you posted is that it falls almost directly in the first null point of the stopband @ 1ms/div (see image above which shows the null points of an averaging filter). Compare it to this image using the same settings as you, but with a 150kHz sine wave - which falls beyond the first null point (although still attenuated by -12dB):



Playing around with sending sweeps to the Rigol while in High Res mode reveal the nulls that exist in the stopband at each time base setting (while using 14MB/AUTO mem depth). These null points are at the averaging frequency (sample rate/number of samples averaged) and its harmonics.

Bandwidths @ 14MB/AUTO memory depth in High Res mode on DS2000

Time base  -	Bandwidth (-3db)  -	First null in stopband
10ms/div	~4.3kHz	~10kHz
5ms/div	~8.6kHz	~20kHz
2ms/div	~21.6kHz	~50kHz
1ms/div	~43.3kHz	~100kHz
500us/div	~86.6kHz	~200kHz
200us/div	~173.2kHz	~400kHz
100us/div	~346.4kHz	~800kHz
50us/div	~692.8kHz	~1.6MHz
20us/div	~1.38MHz	~3.2MHz
10us/div	~2.77MHz	~6.4MHz
5us/div	~5.54MHz	~12.8MHz

[evanh]

The maths is not the problem.  It's the stored trace that's the problem.  One method perform oversampling and filters only to the Nyquist point and stores those high-res samples as the trace.  The other method just stores 8-bit samples straight from the ADC ... which is nyquist limited and still only 8 bits.  Any further processing cuts-off even lower.

...
There is no such thing as oversampling when the DSO is already sampling at it's maximum rate. I can't speak about the DS1000Z, but the Rigol DS2000 series can sample at it's maximum 2GSa/s rate down to 2ms/div - it doesn't need to oversample because the sample memory already contains all possible samples that could be captured in a given time frame.

Except, of course, a DSO is often storing the trace at no where near it's ADC's max sample rate.  This is when oversampling kicks in.  An oversample situation is with respect to the stored trace, not the ADC.  When the trace is stored at, say, one sample per minute there is certainly some room for oversampling wouldn't you think?

There is a distinct acquisition mode change here, it changes the content of the stored samples.  The Rigol's don't attempt to perform this function and therefore are not implementing a high-res acquisition mode.

[evanh]

I bet Rigol's method could be, but it doesn't let you, flipped on and off - refreshing the display in either Normal or High Res without any new trace acquisitions.

I think this is a clue to Evan's issue.  As far as I know, the only time Rigol doesn't let you change the High Res setting on existing data is in record mode.  It absolutely does let you change the setting when stopped normally.

The setting is editable but it doesn't action until the next capture.  I was only giving an example of what could happen because the stored trace is no different between Normal mode and High Res mode.  Which is not the case on scopes that have a true high-res acquisition mode.

I can assure you this is a big issue for everyone.  Rigol's High Res mode should be avoided.  It will create problems if used.

[marmad]

There is a distinct acquisition mode change here, it changes the content of the stored samples.  The Rigol's don't attempt to perform this function and therefore are not implementing a high-res acquisition mode.

Wrong. Acquisition modes change what is shown on the oscilloscope screen. There is sample memory and there is display memory. Whether a mode changes what is stored in the sample memory - or whether it performs the math between sample and display memory - is the prerogative of the DSO manufacturer. As I've mentioned half a dozen times already, there is NO MATHEMATICAL DIFFERENCE (except for speed) in performing successive sample averaging on samples as they arrive from the ADC @ 2GSa/s - or performing it on samples that have been saved in sample memory @ 2GSa/s.

I can clearly see the effects of the successive sample averaging filter on my Rigol DS2000 with simple sweep tests - as I've posted here. Whether it works correctly on your slower (and less capable) DS1000Z, I couldn't say - but it's certainly implemented on my DS2000.

I was only giving an example of what could happen because the stored trace is no different between Normal mode and High Res mode.  Which is not the case on scopes that have a true high-res acquisition mode.

Sorry, you're just spouting nonsense that's not backed up with any data (as usual). Successive sample averaging can be performed on a stored waveform at any time - it just requires a single waveform (whereas successive capture averaging, which requires multiple waveforms, can not). Of course, the speed at which that waveform was sampled will effect the LPF of the averaging - but other than that, it makes no difference.

I can assure you this is a big issue for everyone.  Rigol's High Res mode should be avoided.  It will create problems if used.

   Avoid it on your DSO if you want... I've already posted the stopband frequencies for the High Res averaging on the DS2000 from 5us-10ms here. Other users just need to be aware of them to use High Res problem-free.

[evanh]

Display rendering is separate from acquisition.

High-res acquisition mode operates in oversampling only, not the stored trace.  The stored trace is the end result of acquisition.  All the filtered frequencies are beyond the Nyquist point.

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

[marmad]

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:

2us   = normal sample rate 2GSa/s (no oversampling) = 9 bits of high res
5us   = normal sample rate 2GSa/s (no oversampling) = 10 bits of high res
10us = normal sample rate 2GSa/s (no oversampling) = 11 bits of high res

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.

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"?   

[Carrington]

See that the sample rate is 1Gsa/s in my screenshot, which should leave plenty of effective sample rate for a 100kHz signal.

@Galaxyrise: Interestingly, the reason the 100kHz signal is so attenuated in the image you posted is that it falls almost directly in the first null point of the stopband @ 1ms/div (see image above which shows the null points of an averaging filter). Compare it to this image using the same settings as you, but with a 150kHz sine wave - which falls beyond the first null point (although still attenuated by -12dB):



Playing around with sending sweeps to the Rigol while in High Res mode reveal the nulls that exist in the stopband at each time base setting (while using 14MB/AUTO mem depth). These null points are at the averaging frequency (sample rate/number of samples averaged) and its harmonics.

Bandwidths @ different time base settings in High Res mode on DS2000

Time base	Bandwidth (-3db)	First null in stopband
10ms/div	~4.3kHz	~10kHz
5ms/div	~8.6kHz	~20kHz
2ms/div	~21.6kHz	~50kHz
1ms/div	~43.3kHz	~100kHz
500us/div	~86.6kHz	~200kHz
200us/div	~173.2kHz	~400kHz
100us/div	~346.4kHz	~800kHz
50us/div	~692.8kHz	~1.6MHz
20us/div	~1.38MHz	~3.2MHz
10us/div	~2.77MHz	~6.4MHz
5us/div	~5.54MHz	~12.8MHz

By limiting the BW seems to be designed for audio applications, or something like that. For now I never used this mode.
I am more interested in the ANTI-ALIASING option, I would like to know how RIGOL implemented it, what sampling method used etc...

[Mark_O]

Bandwidths @ different time base settings in High Res mode on DS2000

Time base	Bandwidth (-3db)	First null in stopband
10ms/div	~4.3kHz	~10kHz
5ms/div	~8.6kHz	~20kHz
2ms/div	~21.6kHz	~50kHz
1ms/div	~43.3kHz	~100kHz
500us/div	~86.6kHz	~200kHz
200us/div	~173.2kHz	~400kHz
100us/div	~346.4kHz	~800kHz
50us/div	~692.8kHz	~1.6MHz
20us/div	~1.38MHz	~3.2MHz
10us/div	~2.77MHz	~6.4MHz
5us/div	~5.54MHz	~12.8MHz

Thanks for this table, BTW.  That's very useful info to have, and not provided by any of the vendors, to my knowledge.

[marmad]

Thanks for this table, BTW.  That's very useful info to have, and not provided by any of the vendors, to my knowledge.

No problem - although I went back and edited the title of the table to:

Bandwidths @ 14MB/AUTO memory depth in High Res mode on DS2000

...because the DSO will use lower sample speeds (and thus lower bandwidths) if you don't have the memory depth set to 14MB or AUTO (and possibly 56MB, although I didn't test that).

[Galaxyrise]

By limiting the BW seems to be designed for audio applications, or something like that. For now I never used this mode.
I am more interested in the ANTI-ALIASING option, I would like to know how RIGOL implemented it, what sampling method used etc...

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.

There have been quite a few posts in this thread about it, if you have an afternoon to kill