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

[marmad]

Congratulations, you have found it!  I heard first time about aliasing about half year ago.

Scratch that    Damn, I got over-excited about nothing. In fact, it doesn't seem as if the Anti-Aliasing button had the effect I thought it was having with AUTO memory setting - the aliasing still happens when you zoom in on the waveform when the DSO is stopped. 

[Teneyes]

- the aliasing still happens when you zoom in on the waveform when the DSO is stopped. 

Did you Zoom in far enough??

[jsykes]

OOOH Boy what a Scan and sample rate (5Sa/s)  here
The Warming up of my DSO with terminated inputs.
about 25 minutes between Pix
Note the gradual drift of the trace to Zero over 35 minutes

Mine drifts over 2 divisions from cold to warmup. See this old post and the one after it:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg241517/#msg241517
 
My drift stops after 15 minutes.
I ended up sending it back for the issue then found out it was "normal" after the replacement did the same thing. Channel 1 drifts 2 divisions where channel 2 drifts less than 1 division on both of the scopes I had.

[Carrington]

Yesterday I received my DS2072, I'm very happy. This topic reaches 100 pages, 100 pages of satisfaction, LOL ...

RIGOL good job. 

More good news, to see who get it. 

ON Semiconductor:
  MMBTH10-4L  fT(min) 800 MHz -> SMD Mark Code: 3E4.
  MMBTH10L     fT(min) 650 MHz -> SMD Mark Code: 3EM.
Fairchild:
  MMBFJ309      16dB @ 100MHz and 12dB @ 450MHz  (No gain mode, only follower), SMD Mark Code:6U

http://www.flickr.com/photos/eevblog/8022205555/#

[tinhead]

yeah sure , STOP DEAD
3:18 AM , time for bed

But you had just enough time before bed to push us up to 100 pages in this thread! We are the second longest thread here at EEVBlog - and bearing down on first place. 

It took "Hantek - Tekway - DSO hack - get 200MHz bw for free" (the longest thread) 2 years, 2 months, and 5 days to get to 100 pages - while it only took us 8 months and 10 days to get here - and we weren't even offering free bandwidth. 

474 postings are made by you, 1009 by others. In "my" Tekway thread 605 are made by me and 1230 by others.
It is however somehow unfair compare, the Tekway/Hantek/Voltcraft community is large, but ~ 5000 of these DSO owners don't speak or don't post english (lol) or post on mikrocontroller.net (2788 replies!). That makes 4623 total (of which i posted 1326 times) postings related to Tekway/Hantek/Voltcraft DSO/MSO in the 3 main threads only

But still, this Rigol thread is growing incredible fast !.

[marmad]

474 postings are made by you, 1009 by others. In "my" Tekway thread 605 are made by me and 1230 by others.
It is however somehow unfair compare, the Tekway/Hantek/Voltcraft community is large, but ~ 5000 of these DSO owners don't speak or don't post english (lol) or post on mikrocontroller.net (2788 replies!). That makes 4623 total (of which i posted 1326 times) postings related to Tekway/Hantek/Voltcraft DSO/MSO in the 3 main threads only

You did run the percentages, didn't you? 31.9% of the replies here were by me - 32.9% of the replies in your thread were by you - so I edge you slightly out there.    Although this post by me might even us out. 

And, I'm sorry, but I don't know what mikrocontroller.net has to do with EEVBlog. If you combine the top #2 and #3 threads here (both of which were started by me), I totally kick your ass here at EEVBlog. 

[marmad]

Did you Zoom in far enough??

Sure. But in your example images, you're sampling a 1MHz signal at 50MHz - so you wouldn't have any problems with aliasing anyway.

[tinhead]

And, I'm sorry, but I don't know what mikrocontroller.net has to do with EEVBlog. If you combine the top #2 and #3 threads here (both of which were started by me), I totally kick your ass here at EEVBlog. 

it is not about you and me or our threads in generally, but about threads about these two specific topics (if i would count my posts on analforum.com i would kick half of the world forever )

For sure mikrocontroller.net have nothing to do with eevblog, but large part of the german/eu Tekway/Hantek/Voltcraft community was posting there and not here, so even with this handicap the Tekway thread on Eevblog is huge.

On the other side, exacty as you said, "8 months and 10 days" to get 100 pages, and thats a lot!

Within same time i got only 50-55 pages So "free something" didn't means anything, heh.

[marmad]

it is not about you and me or our threads in generally, but about threads about these two specific topics (if i would count my posts on analforum.com i would kick half of the world forever )

 

On the other side, exacty as you said, "8 months and 10 days" to get 100 pages, and thats a lot!

Yes... but OTOH, membership here seems to be growing exponentially, so this thread had that in it's favor.

Within same time i got only 50-55 pages So "free something" didn't means anything, heh.

Well, I imagine until that Tekway/Hantek/Voltcraft DSO line is completely dead, it will impossible to ever catch up to your thread's leading 'view' total. 

[Carrington]

This post: "REVIEW - Owon SDS7102 - A look at the SDS series from Owon" Also has nearly 100 pages, but not due to the quality of the product. 

[marmad]

So yesterday I got prematurely excited during testing because I thought that Anti-Aliasing was actually working when Memory Depth was set to AUTO - but it turns out not to be true. 

It did get me thinking about it though:
Normally when you set Memory Depth to AUTO, the DSO automatically adjusts the sample size (up to 14M) to keep the sample rate as high as possible (with just enough samples needed to fill the horizontal scale [time base x 14]). But why doesn't Rigol write a new FW routine which has a different behavior for when both AUTO and ANTI-ALIASING are on?

Instead of changing the block sample size or rate, the routine would keep the sample rate fixed @ 2GSa/s - and just achieve the necessary sample size for the display by random decimation (i.e. stochastic sampling). This would allow users to use anti-aliasing while probing unknown signals - then if deeper sampling of a certain time base is desired, simply turning off ANTI-ALIASING will cause the DSO to fall back into normal AUTO mode.

To me, it seems pretty easy to implement - certainly no more difficult than HIGH-RES mode, or a number of other post-processing techniques they use.

[Carrington]

To me, it seems pretty easy to implement - certainly no more difficult than HIGH-RES mode, or a number of other post-processing techniques they use.

I hope that RIGOL consider it.
They could also add decoders CAN and LIN.

Note: With serial number: DS2A1516xxxxx, continue with probes RP3300.

[marmad]

I hope that RIGOL consider it.
They could also add decoders CAN and LIN.

I'm afraid that those decoders are something that they might consider as product differentiation between the DS2000 and DS4000 series. CAN and LIN are also not offered in the new DS1000Z series.

[Carrington]

Well, a PC application solves this problem. 
Like a translator to OLS-client.

[Galaxyrise]

But why doesn't Rigol write a new FW routine which has a different behavior for when both AUTO and ANTI-ALIASING are on?

To me, it seems pretty easy to implement - certainly no more difficult than HIGH-RES mode, or a number of other post-processing techniques they use.

Do you have any picture evidence that the DS2000 is capable of oversampling?  My first couple of attempts at this seemed to indicate otherwise (which is what I was complaining about a dozen pages ago) but I haven't spent the time yet to thoroughly convince myself of it.  If the DS2000 can only process what makes it to sample memory, then the anti-aliasing you want is simply not possible.

[marmad]

Do you have any picture evidence that the DS2000 is capable of oversampling?  My first couple of attempts at this seemed to indicate otherwise (which is what I was complaining about a dozen pages ago) but I haven't spent the time yet to thoroughly convince myself of it.  If the DS2000 can only process what makes it to sample memory, then the anti-aliasing you want is simply not possible.

The technique doesn't require the DSO to ever sample faster than 2GSa/s - it just varies how it decimates those samples at slower time base settings. This could happen between the ADC and sample memory (which is how I think the Agilent does it) or it could happen between sample memory and display memory.

[Galaxyrise]

The technique doesn't require the DSO to ever sample faster than 2GSa/s - it just varies how it decimates those samples at slower time base settings.

I've never suggested that the DSO sample faster than its max. I haven't seen evidence that the Rigol ever does any logic between ADC and sample memory, even if the current sample rate is 1MSa/s.

This could happen between the ADC and sample memory (which is how I think the Agilent does it) or it could happen between sample memory and display memory.

I'm confused: I thought the anti-aliasing you've been talking about has to happen before writing to sample memory.  How could a sample->display algorithm help the situation in the agilent vs rigol images posted earlier? The presence of a high frequency signal has already been lost.

[Teneyes]

Reporting A BUG
on FFT the DSO must maintain the Center frequency selected at the center of the display as you change through span scales
Start with span top (widest to see peak) then narrow span and the display must spread the frequency holding the center frequency at the Center of the Display!!!. see Pic , as only the Scale(FFT) was changed.  And NOT move the selected Peak way off the display, and Making the 'Pissed Off' User constantly  needing to adjust the Center Frequency.  Seem like the Programmers have never worked in Frequency domain

I will forward to RigolNA

[ve7xen]

So I posted this a few days ago but I guess it got buried. Anyone have any comments on my posts about the MATH functions back here? https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg257777/#msg257777

Am I using it incorrectly or is it a bug?

[marmad]

I'm confused: I thought the anti-aliasing you've been talking about has to happen before writing to sample memory.  How could a sample->display algorithm help the situation in the agilent vs rigol images posted earlier? The presence of a high frequency signal has already been lost.

Ok - a few things to clarify (some or all of which may be obvious):
The anti-aliasing I've been talking about won't solve EVERY aliasing problem - just the majority of them.
Most aliasing on a DSO happens when people use a slower time base setting, thus causing the DSO to use a lower sample rate - thus lowering the effective bandwidth of the DSO.
When you see an aliased waveform on the DSO screen, you should actually be seeing a block of pixels; i.e. the equivalent of a fuzzy band (because the period of the waveform ~<= the pixel-to-pixel time).
During normal sampling (regular time intervals), running an ADC clock at 1MSa/s is the same thing as sampling at 2GSa/s and keeping every 2000th sample (simple decimation) - with either technique you will get aliasing on, for example, a 20MHz sine wave.
OTOH, sampling at 2GSa/s and varying the sample you keep within certain parameters (random decimation) will NOT give you aliasing - because the sub-(beat)-frequencies which can appear due to the regular time intervals between samples will not occur.

The Rigol does NOT have to do this during sampling; it could sample at full speed (2GSa/s) into sample memory - then do random decimation (to simulate the current sampling rate) to display memory. Of course, this wouldn't work for ALL slower sample rates (at some point the memory wouldn't be large enough), but it could work for many slower rates.

Is this clear now? 

[Teneyes]

. Anyone have any comments on my posts about the MATH functions back here?

@VE7XEN eh!
looks like limited numerical , point to point calculation and use DC values see disp

Yes I see Positive accumulations in the Int() function
See pics
1, Dirfting up
2  Drifting  down 
3  By putting offset of -20mVdc on the 2Vpp sawtooth dirft was zero'ed

4  Now with Sinwave ,
     NOTE the input of 7.36Vpp integrates to 4mVpp
             the  input has a -14.6Vdc Offset   

[ve7xen]

Thanks Teneyes, I think you're right, it's just accumulation of a constant offset. I suppose that makes sense.

But why the tiny and gigantic values, they're orders of magnitude out from expected?

[Teneyes]

Reporting A BUG
on FFT the DSO must maintain the Center frequency selected at the center of the display as you change through span scales

An Update, and very quick, I'm impressed

---------------------------------------------------------------
Hello Teneyes (edit)

Thanks for sharing the information. I understand what you are saying - that you would like the FFT function to work more like a Spectrum Analyzer where the span adjusts from the center.

All of our scopes operate like the DS2000 because the high end of the span is really set by the time per division of the underlying signal. That timing effects your sample rate on the display and consequently the max frequency. So, as a design decision we made the span move from the left side to keep the accurate parts of the signal on the display as much as possible.

I would actually prefer that the FFT moves from the center like you suggest, but all our scopes currently move from the left. So, for best operation you may want to move your target signal toward the left side before zooming in or set your span first and then adjust the center.

We will submit this as an enhancement request since we think it is a good idea, but as all of our scopes currently operate in this mode I wouldn't expect it to be something that is changed quickly. We will probably need to put some wider organizational thought into it.

Thanks for the feedback!
Chris Armstrong,   General Manager , Rigol NA Technologies

------------------------------------------------------------
Hello Chris
 
   Thank you for the quick response.
 
Yes, I realize the timebase/sample rate sets the max frequency for the frequency span in FFT mode.
 
I suggest Rigol keep the setup as is.
 
But I suggest Rigol add a check to see if the Operator-set Center Frequency is within the span of the 4 choices (determined by time base) then I suggest the program does Not go to the pre=assigned Center frequency but keep the operator selected Center Frequency.
 
Obviously, entering the FFT mode there is no Center Frequency so setting 0 Hz on left is correct.
 
Now if the time base is Not changed,
then the changing of the Frequency/div does not change the 4 choices(of span) and the Center frequency is still available, so I suggest keep the Center Frequency at center of the Display.
 
For that matter even if the time base is changed, if one of the new 4 choices(of span) overlaps the existing selection then keep the same Center Frequency . 
 
Thanks Again
===================================================

Great process flow summary Teneyes! (edit)
I will pass it along.
thanks for the help making our products better!

Chris

[Galaxyrise]

The Rigol does NOT have to do this during sampling; it could sample at full speed (2GSa/s) into sample memory - then do random decimation (to simulate the current sampling rate) to display memory. Of course, this wouldn't work for ALL slower sample rates (at some point the memory wouldn't be large enough), but it could work for many slower rates.

Is this clear now? 

With you up to here.  I thought "at some point the memory wouldn't be large enough" is every time sample rate is reduced. Going back and looking at one of the examples you posted, the scope is sampling at 200kSa/s because the memory depth is set to 14kpt and the timebase is 5ms. There's no room to increase the sample rate there, so that couldn't be a fix to that particular aliasing.  What's an example where it could still sample at 2GSa/s into sample memory that it isn't doing that already?

[Teneyes]

A little Tip for Math function  Intg()
When using an input from a Chan and the Scan rate is in mSec, then multiply the input by 1000, that way the Units calculated will be in U,  see the display
For a square wave input of -1.0  to 1.0 Vdc at 4mSec period
So integrating (+1.0 *1000) for 2 mSec = +2 Units
So integrating (-1.0 *1000) for 2 mSec  =  -2 Units