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

[Pinkus]

Besides decode in analyze mode, have you discovered any new fixes/feature enhancements with the new firmware?

To be honest: Due to lack of time I did not look deeply into all menus  and submenus. I did not discover anything new by "just" working with the usual functions.

[Bugware]

I update with FW 00.03.01.00.04 from 00.02.01.00.03...

Bug 17) is still there... 

I took a look at the waveform update rates and here are my results. I used only 70kHz Sinwave to test because I don't have a SigGen... Sorry!

[marmad]

I took a look at the waveform update rates and here are my results. I used only 70kHz Sinwave to test because I don't have a SigGen... Sorry!

Well, thanks for doing that, but your 20ns/Auto/Vector number is most definitely missing a zero. I'm getting 17,820 right at this moment.

Also, your input frequency of 70kHz is close enough to the highest update rates that it might negatively impact some of those numbers. I've never seen anyone make these tests with less than a 1MHz input signal - to make sure there isn't any chance input triggers might be missed due to timing mismatches between the input frequency and internal clock.

[pa3bca]

I have noticed that the waveform intensity of my 2072 in hires mode becomes significantly lower at low timebases. This is also the case if I use hires in roll-mode. It seems to happen if the timebase is > 100 ms/division. See attached screenshots. Basically the waveform becomes almost invisible in normal light, it is rather annoying.
Am I missing something, is it a known bug? (could not find anything)

My DS1074 does not exhibit this behavior. So I switch to that instrument when looking hires at low-frequency stuff...

[marmad]

My DS1074 does not exhibit this behavior. So I switch to that instrument when looking hires at low-frequency stuff...

Except, as I've already posted extensively about, the DS1000Z does NOT do correct 12-bit High Res at all. So you're basically just looking at a brighter waveform that is barely (if at all) being averaged. I just checked Roll mode on both scopes (@ 200ms/div), and the DS1000Z is definitely not averaging to 12-bits (i.e. no High Res) - while the DS2000 does it perfectly.

[pa3bca]

Except, as I've already posted extensively about, the DS1000Z does NOT do correct 12-bit High Res at all. So you're basically just looking at a brighter waveform that is barely (if at all) being averaged. I just checked Roll mode on both scopes (@ 200ms/div), and the DS1000Z is definitely not averaging to 12-bits (i.e. no High Res) - while the DS2000 does it perfectly.

Yes I realize(d) the difference between the scopes. But it does not explain (at least not to me) why the wave intensity of the (signal) trace on the DS2072 drops of instantly and dramatically when the timebase is > 100 ms/div - becoming almost invisible.

[marmad]

Yes I realize(d) the difference between the scopes.

But then running the DS1000Z in High Res/Roll is almost equivalent to DS2000 Normal/Roll, so why bother swapping scopes? 

But it does not explain (at least not to me) why the wave intensity of the (signal) trace on the DS2072 drops of instantly and dramatically when the timebase is > 100 ms/div - becoming almost invisible.

I believe the dimness of the waveform in High Res mode at slower timebases comes from the interaction between the successive sample averaging and the decimation for the intensity buffer. I think that it's actually performing correctly - in terms of the intensity mathematics (every 256 successive samples are being reduced to 1) - but it's the kind of thing that, even though technically correct, does not lead to a good visual result. It would require a workaround in the code to bypass (or correct, depending on your point of view) the problem.

[pa3bca]

But then running the DS1000Z in High Res/Roll is almost equivalent to DS2000 Normal/Roll, so why bother swapping scopes? 

Well I wanted to look at a low frequency signal with a lot of noise on top - including scope noise as I was at nearly maximum sensitivity. Hires gets rid of a lot of the noise. But then this signal becomes nearly invisible on the 2000.
The 1074 hires mode also gets rid of some of the noise, not as well as the 2000 but at least the trace is better (visible)

I believe the dimness of the waveform in High Res mode at slower timebases comes from the interaction between the successive sample averaging and the decimation for the intensity buffer. I think that it's actually performing correctly - in terms of the intensity mathematics (every 256 successive samples are being reduced to 1) - but it's the kind of thing that, even though technically correct, does not lead to a good visual result. It would require a workaround exception in the code to bypass (or correct) the problem.

Hmm but why the sudden change @ 100 ms/div. I would expect a more gradual dimming.

[marmad]

Hmm but why the sudden change @ 100 ms/div. I would expect a more gradual dimming.

The acquisition/display engine is working differently at the slower timebases. You can see that when you're at <=100ms/div, the entire waveform is captured before being displayed (i.e. all decimation is done), but when at >=200ms/div, it is displaying the waveform AS it's being captured (i.e. decimation done on the fly - thus not being affected by subsequent captures).

The Rigol's do intensity grading based on BOTH vertical and horizontal overlapping from sample to display memory. When displaying on the fly (anytime you're running at >=200ms/div), the overlapping (and thus, grading) will be different since it won't know beforehand the upcoming samples. This is true on the DS1000Z too, but because it's not really doing 12-bit averaging, you don't see the intensity difference caused by the missing (averaged) samples when displaying on the fly.

EDIT: BTW, this could explain why Rigol doesn't do true High Res on the DS1000Z: because people complained about the dim waveform on the DS2000 when using it at >=200ms/div, so instead of finding a workaround, they just crippled it on the DS1000Z.    I suspect it's either that - or the engine is just not fast enough for it.

[pa3bca]

The acquisition/display engine is working differently at the slower timebases. You can see that when you're at <=100ms/div, the entire waveform is captured before being displayed (i.e. all decimation is done), but when at >=200ms/div, it is displaying the waveform AS it's being captured (i.e. decimation done on the fly - thus not being affected by subsequent captures).

The Rigol's do intensity grading based on BOTH vertical and horizontal overlapping from sample to display memory. When displaying on the fly (anytime you're running at >=200ms/div), the overlapping (and thus, grading) will be different since it won't know beforehand the upcoming samples. This is true on the DS1000Z too, but because it's not really doing 12-bit averaging, you don't see the intensity difference caused by the missing (averaged) samples when displaying on the fly.

Aha! Now it makes sense. From 100 -> 200 ms/div the display indeed changes from complete capture -> display to displaying "live" while capturing.
Thanks, this helped me a lot. (Still would like Rigol to do something about it, but it is probably not on top of a list)

[marmad]

Aha! Now it makes sense. From 100 -> 200 ms/div the display indeed changes from complete capture -> display to displaying "live" while capturing.
Thanks, this helped me a lot. (Still would like Rigol to do something about it, but it is probably not on top of a list)

It's definitely a quirky byproduct of their mathematics/display code, which could be changed with a little effort - although you could argue that it's actually displaying the intensity (after averaging) exactly correctly. It is curious to note though, that the intensity is, in fact, 'adjusted' by the DSO when stopped.

Try this: do a Single capture of a sine wave in High Res mode @ >=200ms/div with Intensity at 50%. You'll see the typical very dim waveform when the capture is done. Then just lightly turn (I don't mean PUSH - just very slightly rotate) the multifunction knob, and the intensity will snap back to an 'average' setting.

[pa3bca]

Try this: do a Single capture of a sine wave in High Res mode @ >=200ms/div with Intensity at 50%. You'll see the typical very dim waveform when the capture is done. Then just lightly turn (I don't mean PUSH - just very slightly rotate) the multifunction knob, and the intensity will snap back to an 'average' setting.

Yes, I already noticed that (by twiddling the vertical position knob, even while capturing). That was (then) one of the reasons why I suspected a bug....

[marmad]

Yes, I already noticed that (by twiddling the vertical position knob, even while capturing). That was (then) one of the reasons why I suspected a bug....

No, I think that Rigol's thinking is that the dimness is actually the mathematically correct intensity after averaging (as mentioned above) - so it's giving you the 'truest' image of the averaged + decimated samples. But once the DSO is stopped, the 'true' image of the incoming and processed samples is not as important as normal brightness.

At least, I can imagine that some engineer might have thought this way 

[pa3bca]

No, I think that Rigol's thinking is that the dimness is actually the mathematically correct intensity after averaging (as mentioned above) - so it's giving you the 'truest' image of the averaged + decimated samples. But once the DSO is stopped, the 'true' image of the incoming and processed samples is not as important as normal brightness.

At least, I can imagine that some engineer might have thought this way 

Ok so if the displayed trace(brightness) reflects the actual density/intensity of the original signal at that level, then increasing the amount of noise on the input should result in an even dimmer average trace (as the signal density per tracewidth would become smaller). Might try that later...

[marmad]

Ok so if the displayed trace(brightness) reflects the actual density/intensity of the original signal at that level, then increasing the amount of noise on the input should result in an even dimmer average trace (as the signal density per tracewidth would become smaller). Might try that later...

No, the amount of noise won't make a difference: in High Res mode, it's already displaying the lowest intensity level possible.

Think of the math: for example, at 200ms/div in Normal mode (and the AUTO/14M memory setting), the sample rate is 5MSa/s, so the samples are every 200ns - and each column of the 400px waveform display area equals 7ms, so is derived from 35,000 samples. In other words, the intensity is roughly based on the number of hits between 0 to 35k (with 256 maximum divisions). If High Res is then turned on, the number of possible hits drops by a factor of 256 - which is already the lowest intensity level possible.

You can prove this by turning the intensity level to 0%, then running the DSO in High Res mode. It will always be a perfectly black trace.

[pa3bca]

No, the amount of noise won't make a difference: in High Res mode, it's already displaying the lowest intensity level possible.
<snip>
You can prove this by turning the intensity level to 0%, then running the DSO in High Res mode. It will always be a perfectly black trace.

Yup confirmed. But if the algorithm is so simple what would be the problem (for Rigol) to just upshift the intensity to get better visibility? If I understand you correctly there already is only one (1) intensity level in this mode, so no intensity information will be lost 

[marmad]

Yup confirmed. But if the algorithm is so simple what would be the problem (for Rigol) to just upshift the intensity to get better visibility? If I understand you correctly there already is only one (1) intensity level in this mode, so no intensity information will be lost 

Nothing really. As I mentioned, I guess some Rigol engineers thought it was better to keep it consistent to reflect the reduction of data by averaging when the DSO was running. But it would be nice if it was at least an option you could turn on and off (e.g. Intensity Averaging - or something like that).

Since there is only one level at >=200ms/div High Res, you might as well set intensity to 100%. Do you still find it too dark if you do that?

[pa3bca]

Since there is only one level at >=200ms/div High Res, you might as well set intensity to 100%. Do you still find it too dark if you do that?

I'd like it a bit brighter, but I suppose it will do 

[ted572]

There is a new issue with 'Rigol DS1000Z & DS2000 Oscilloscope Jitter' related to the Trigger mode/method.    See ->  https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964   This is already up to 12 pages in only two days.  I'm posting this alert here because I didn't see Rigol O'Scope experts here such as 'marmad', 'teneyes', etc there that could be valuable contributors to understanding the issue.  And further we should all at least be advised that this issue is being discussed.  I also believe that some DS4000 users are experiencing the trigger jitter issue (with the AC trigger mode).

[marmad]

There is a new issue with 'Rigol DS1000Z & DS2000 Oscilloscope Jitter' related to the Trigger mode/method.    See ->  https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964   This is already up to 12 pages in only two days.  I'm posting this alert here because I didn't see Rigol O'Scope experts here such as 'marmad', 'teneyes', etc there that could be valuable contributors to understanding the issue.  And further we should all at least be advised that this issue is being discussed.  I also believe that some DS4000 users are experiencing the trigger jitter issue (with the AC trigger mode).

Thanks for the heads up. As I noted over in that thread, we've been talking about problems with AC-coupling the trigger for over 2 years now in this thread (check out the bug list or search the thread). Few of us original owners use that setting because of these problems - and I've never found a single instance in my use of the DSO in that time where I needed it. The other jitter being discussed is not present on the DS2000.

[ted572]

There is a new issue with 'Rigol DS1000Z & DS2000 Oscilloscope Jitter' related to the Trigger mode/method.    See ->  https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964   This is already up to 12 pages in only two days.  I'm posting this alert here because I didn't see Rigol O'Scope experts here such as 'marmad', 'teneyes', etc there that could be valuable contributors to understanding the issue.  And further we should all at least be advised that this issue is being discussed.  I also believe that some DS4000 users are experiencing the trigger jitter issue (with the AC trigger mode).

Thanks for the heads up. As I noted over in that thread, we've been talking about problems with AC-coupling the trigger for over 2 years now in this thread (check out the bug list or search the thread). Few of us original owners use that setting because of these problems - and I've never found a single instance in my use of the DSO in that time where I needed it. The other jitter being discussed is not present on the DS2000.

Thank you 'marmad':
I just found your post that I somehow missed before reading through the whole thread.  I must have fallen asleep for some of it.
Anyway I for one feel much better as a DS2000 owner seeing that its AC Triggering issue has been known about for a long time.  It is very bad, so hopefully it will get corrected by Rigol.
Thanks! 

[ted572]

This is a Post from Dave about the D1000Z (with 5uS Jitter / AC Triggering) and DS2000 (AC Triggering) Jitter issues:
Re: EEVblog #683 - Rigol DS1000Z & DS2000 Oscilloscope Jitter Problems   « Reply #336 on: Today at 07:51:48 PM »
See ->  https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg554120/#msg554120

UPDATE FROM RIGOL
   1: We have reproduced the two issues in R&D side;
   2: All issues can be fixed by firmware updating without deleting any feature;
   3: The trail firmware form R&D will be released in early next week, that can be used for Dave or some urgent cases.

Good news: It appears that we will eventually see firmware fixes for these issues after their Beta testing with EEV's Dave Jones, etc. has been completed.

[Teneyes]

Gilberto Asks

I upgraded the ds1104z to version 00.04.01.SP2 (board version 0.1.1).
Triggering ac nothing has changed.
I find problems, attaching two pictures ... this's not normal!!!

[Teneyes]

Marmad and I responded

You can use the Delay Trigger type (which takes two input sources) to get a stable image of two waveforms with unrelated and different frequencies.

Gilberto60 Is this what you like to see with 2 different frequencies?

Note , Select SourceA or SourceB in order to adjust Trigger level for each Chan

[NikWing]

hey all

I've got a question: how good is the math function of the DS2xxx?
I have 3 DSOs here: 1 yokogawa and one philips pm3082 I think, both have 100 MHz 200 MS/s and my DS2072 @300 Mhz
I try to measure current, voltage and multiply both to see the power
on all 3 DSOs all channels and math are set to RMS.
But only the Rigol shows a 10-20W different calculated value
the math also changes with V/div resolution on the Rigol, that doesn't happen on the other 2 DSOs

Am I doing something wrong? all 3 DSO are set the same way, very odd ...
(btw, I really hate that the Rigol switches off/restarts after self cal and IIRC it also forgets the settings I made before self cal)
I want to use the Rigol because of it's better handling and ways to measure ...