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

[Xyphro]

Or the 20Mhz bw limit is done in the digital domain with a 8 bit signal path? You said it was turned on if I remember correctly.

But I'm also still happy with my Rigol :-)

[Wim13]

Or the 20Mhz bw limit is done in the digital domain with a 8 bit signal path? You said it was turned on if I remember correctly.

But I'm also still happy with my Rigol :-)

i dont think so, as the entry chip  can do this easy,

from the TI datasheet:

In a typical oscilloscope application, the voltage range encountered is from 1 mV/DIV to 10 V/DIV with 8 vertical
divisions visible on the screen. One of the primary concerns in a digital oscilloscope is SNR which translates to
display trace width/ thickness. Typically, oscilloscope manufacturers need the noise level to be low enough so
that the “no-input” visible trace width is less than 1% of FS. Experience has shown that this corresponds to a
minimum SNR of 52 dB.

[alank2]

Is there a way to adjust the trigger to 50% of the signal?  I don't see this button which was quite handy on my previous rigol...

[Galaxyrise]

Is there a way to adjust the trigger to 50% of the signal?  I don't see this button which was quite handy on my previous rigol...

Presuming you still want the signal displayed with DC coupling, you can put the trigger in AC coupling and 0V and it will do that.

[alank2]

Is there a way to adjust the trigger to 50% of the signal?  I don't see this button which was quite handy on my previous rigol...

Presuming you still want the signal displayed with DC coupling, you can put the trigger in AC coupling and 0V and it will do that.

I usually use DC coupling and just press the 50% button to put the trigger in the center of the signal...  No way to do this?

[EV]

Maybe EV or Wim can do a Sweep with DS2000 set @ 500uV, I only did from 4-40 MHz

Sorry, I am not at home yet. 

[Hydrawerk]

(...) Could you please send a 100kHz sine wave into your Agilent DSO - then adjust the horizontal scale until the sampling rate shows 100kSa/s - then grab a screen shot and post it (...)
Thanks,
Mark

Here are my pictures. I added a 10MHz at 10MSa/s. There is some small product of aliasing, but it's OK. It is not a clear sine wave, that fools you.
Edit: Note the wrong automatic frequency measurements. But it is not a huge deal. Who would use it at undersampled signal...

[marmad]

Here are my pictures. I added a 10MHz at 10MSa/s. There is some small product of aliasing, but it's OK. It is not a clear sine wave, that fools you.

Thanks, Hydrawerk. I understood the math, but I hadn't seen it in action.

[Hydrawerk]

So how do similar pictures from DS2000 look like?

[marmad]

I think pix are close to Hydrawerk's conditions

Huh?    Totally aliasing - not close at all.

[Galaxyrise]

Huh?    Totally aliasing - not close at all.

I think you missed what Teneyes was replying to

[Hydrawerk]

So how do similar pictures from DS2000 look like?

I think pix are close to Hydrawerk's conditions

Thank you for the pictures. What happens if you turn on the Antialiasing feature?

[zibadun]

So how do similar pictures from DS2000 look like?

I think pix are close to Hydrawerk's conditions

Thank you for the pictures. What happens if you turn on the Antialiasing feature?

hydrawerk, here is the antialiasing feature at work on Rigol https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg255344/#msg255344.   It attempts to minimize moire patterns on the display.  I think it works fine

marmad and now Teneyes expect this feature to do something else in undersampling mode. But looks like they will get  either noise with some aliasing (Agilent) or "classic" aliasing (Rigol).  they don't get to see the real signal while undersampling.  So guys pick your poison 

[Marc M.]

marmad and now Teneyes expect this feature to do something else in undersampling mode. But looks like they will get  either noise with some aliasing (Agilent) or "classic" aliasing (Rigol).  they don't get to see the real signal while undersampling.  So guys pick your poison 

Please add me to the above list .  Both Marmad and Teneyes understand the theory behind proper anti-aliasing as applied to scopes and it is clear that Rigol does not perform it that way.  With all the material that's been presented on how random decimation of the raw data helps to minimize the effects of aliasing, I'm at a bit of a loss why this is still being argued  .

[marmad]

hydrawerk, here is the antialiasing feature at work on Rigol https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg255344/#msg255344.   It attempts to minimize moire patterns on the display.  I think it works fine

Wow, you just don't want to stop being wrong about this 

The meaning of Aliasing, as applied to a DSO, is when high-frequency components “fold down” into a lower frequency when the sample rate isn’t fast enough. What you call "classic" aliasing is the ONLY aliasing - there is NO other meaning in the world of Digital Storage Oscilloscopes. As I've mentioned before, if you think there is, please post a link describing a different kind of aliasing in DSOs.

What Rigol calls Anti-Aliasing is a useless feature. There is no way I would be confused by your first image into thinking I was seeing a lower frequency than I was. Oh great, it's managed to eliminate a fluctuating pattern in a solid block of pixels - whoopee! 

marmad and now Teneyes expect this feature to do something else in undersampling mode. But looks like they will get  either noise with some aliasing (Agilent) or "classic" aliasing (Rigol).  they don't get to see the real signal while undersampling.  So guys pick your poison 

The Agilent's "noise", as you call it, is actually a solid block of pixels, which is what you should see given the frequency and sample rate - that is the REAL signal (or a close enough approximation). That would actually help me from being confused by incorrectly folded-down lower frequencies. Sorry, but it seems as if you still don't understand the concept of what it's doing

[Teneyes]

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

[marmad]

This is basically what a 100kHz sine wave SHOULD look like at 500ms/div:




This is what the Rigol displays @500ms/div using 200kSa/s:




This is what the Agilent displays @500ms/div using 100kSa/s:




Which is closer to the REAL signal?

"Anti-aliasing" should eliminate aliasing - period. If that means that the DSO needs to 'lock' the sample size while the feature is being used - that's what it should do.

[marmad]

I realize that normally the DSO triggers on a select trigger (condition) and that there is a need to record data before and after the event.  I am finding it an annoyance to have to wait as the DSO records long data before I am able to force a trigger.

When I select , "Single" I want 1 event
When I select , a Long time base  , 1 min/div  ( anything greater than 2 seconds)
When I move trigger point to near left edge of the Display ( showing I wish to see data after the trigger)
and then I press a "Force" trigger, I wish to see data Now
 I think the DSO should start the trace immediately and just show the data immediately at the trigger point and NOT make me wait a long time for the DOS to record a preample.

@Teneyes: I played around with the slower time bases to see what I could figure out. It appears as if the Rigol has to capture a minimum of ~512 bytes of pre-trigger data; this is when the trigger point is anywhere off the screen to the left (D >= 7 x time base). This pre-trigger data, of course, is what it analyzes to look for triggering events.

The length of time this takes is linked - as it must be - to the sampling rate. So if my memory depth is set to 14kB, then my sample rate at, for example, 200s/div is only 5Sa/s. So that means it takes the DSO ~102.4 seconds to fill the 512 byte pre-trigger buffer before the 'WAIT' status is displayed. OTOH, if my memory depth is set to 56MB, then my sample rate is 20kSa/s, so it only takes ~.0256 seconds to fill the buffer.

If you want the DSO to respond instantly at slow time base settings for Single shot - move the trigger point >= 7 x divisions left and use a large memory depth.

[marmad]

Nope not for me :
  At 20s/div, 14 Mpts, 50KSa/s ,
After moving trigger point to 5 div left of center (on the screen), "Wait" takes 40 seconds to Arm

Dude! It's because you're asking it to show you two divisions BEFORE the trigger: 2 x 20 seconds = 40 seconds. How can it show you that if it doesn't first capture it? Move the trigger point 2 divisions left and it will be almost instantaneous to "Wait". 

[marmad]

After moving trigger point to 5 div left of center (on the screen), "Wait" takes 40 seconds to Arm

Anything visible on the DSO screen which is left of the trigger point is considered pre-trigger buffer. That buffer is FIFO - and needs to be completely filled at the current time base setting before any triggering can happen.  If the trigger point is >= 7 x time base setting, then the pre-trigger buffer is ~512 bytes. Once it's filled, the DSO is ready to be triggered, since new sample data will just overwrite the buffer.

[marmad]

Yes , got it now, to get immediate tracing on manual trigger set the trigger exacting at left edge of the display,  Just an OLD dude like the scan, I'm a bit slow ,
 before left edge, then you wait to see trace
   after left edge  then you wait to arm

Yes, but just be aware that even with the trigger point all the way left, if your sample rate is too low, it can still take a long time to fill the 512 bytes.

And don't worry: everything - and everybody - will slow down in the end . 

[marmad]

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. 

[zibadun]

This is basically what a 100kHz sine wave SHOULD look like at 500ms/div:




This is what the Rigol displays @500ms/div using 200kSa/s:



This is what the Agilent displays @500ms/div using 100kSa/s:




Which is closer to the REAL signal?

"Anti-aliasing" should eliminate aliasing - period. If that means that the DSO needs to 'lock' the sample size while the feature is being used - that's what it should do.

Agilent is more real, but it's lying about the sampling rate.  It's oversampling the signal and then performs DSP on it to down convert to 100ksps.  Rigol shows the real 200khz sampling rate.   with only two samples per cycle it's not able to represent the amplitude correctly so it appears like the signal is amplitude modulated.  Rigol shows what you asked, with no gimmicky "stochastic" sampling.   If you keep an eye on the sampling rate you'd be fine. The Auto button will work in a pinch   Anyways I'm done commenting on aliasing. 

[marmad]

Agilent is more real, but it's lying about the sampling rate.  It's oversampling the signal and then performs DSP on it to down convert to 100ksps.

It's not lying about anything - 100kSa/s means exactly that = 100,000 samples per second - you can arrive at that anyway you'd like. OTOH, the Rigol IS lying about 'Anti-Aliasing' - it DOES NOT DO IT, as anyone who understands aliasing can see. And that, after all, has been the point of this entire discussion. 

Rigol shows the real 200khz sampling rate.   with only two samples per cycle it's not able to represent the amplitude correctly so it appears like the signal is amplitude modulated.  Rigol shows what you asked, with no gimmicky "stochastic" sampling.

It's no more gimmicky than averaging, high-res mode, intensity grading, or a dozen other things both DSOs do. Again, if a DSO says it does anti-aliasing - it should do it.

[Teneyes]

100KHz oversampled at 2MSa/sec
How can one tell the difference?

1st display looks like a display in Zibadun's post
2nd display I push Auto (1.7Hz AM)