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

[Bugware]

and that's not a new bug?
dropping from 47k to 17k while nearly all other values got better?

It is quite likely that is a new bug. But they release a new Firmware again since a long time. After many new devices offers maybe they have more time to release new fixes.... 

Read my message above. It's not realistic to classify slower or faster wfrm/s rates as bugs. Is it a bug when you turn on High Res and the rate drops? Nope - not a bug.

Yes, you are right. It is not a "bug". But there is a deterioration of the previous value. So I think there is something wrong for only this one rate. For me, no big deal.

[marmad]

sorry, but im new here and i dont know how to post a topic..can anyone help me?

Click the 'Help' button at the top of the page - it will show you how to do anything in the forum.

[NikWing]

ok, it just seemed a bit weird to me that only 1 value has such a difference

[marmad]

ok, it just seemed a bit weird to me that only 1 value has such a difference

Yes, but 5ns single/vector had an even bigger difference (> 31k wfrm/s) - in the opposite direction. 

Ideally, the faster the time base, the more waveforms per second (because blind time is increasing). So Rigol's speeds are much more balanced (i.e. growing larger at smaller time bases) than before.

[JDubU]

New chart: full comparison of v.1 and v.2 waveform update rates in AUTO mode / vectors:

Do these waveform update rates change if you change the frequency of the input signal (change the trigger rate)?

[marmad]

Do these waveform update rates change if you change the frequency of the input signal (change the trigger rate)?

I always use a 1MHz sine - but I've noticed there is some variation (maybe +/- 5%?) based on the trigger frequency - just as there is based on the input levels (and virtually anything else). I've never done extensive testing, but feel free to work it out if you'd like 

[Galaxyrise]

and that's not a new bug?
dropping from 47k to 17k while nearly all other values got better?

I find it more likely that the old figure was caused by a bug (billed as a feature), since it was such a discontinuity.  But like marmad says, it's hard for us to know what's an intended consequence of balancing features and what's an unintended drop in wfrm/s.  Hopefully someone at Rigol knows

[marmad]

Found a bug in the new firmware - incorrect setting of the sample rate in DOTS mode at certain time bases it appears to be a bug between sample and display memory.

It seems to affect AUTO/14M/56M memory settings while in DOTS mode @ time bases >= 5us/div.

If someone still has FW v.01.01.00.02 installed, could they please double-check to make sure this bug is NOT present in that FW?

To test:

Single channel on; DOTS mode; test signal input (e.g. 1MHz sine); AUTO memory setting.

Go from 100us/div to 200us/div - and watch the image change. The sample rate appears to be wrong for the displayed image (it's supposed to be 2GSa/s):

[marmad]

Following up on the bug discovered: problems in DOTS mode @ >= 5us/div.

This waveform chart shows how the update rates for DOTS mode are always better than VECTORS until 5us/div, at which point they get drastically worse. Something is definitely wrong here:

[JDubU]

Following up on the bug discovered: problems in DOTS mode @ >= 5us/div.

This waveform chart shows how the update rates for DOTS mode are always better than VECTORS until 5us/div, at which point they get drastically worse. Something is definitely wrong here:

HW2, latest firmware.

I can confirm your waveform update findings in Dots vs. Vector mode at timebases >= 5us/div.

In regards to your previous post:  Dots mode 100us --> 200us.  The 200us setting does produce a display with unique dot artifacts at that one setting but, if I stop the sampling and zoom in, the sampling rate does match what is displayed at the top of the screen (by counting the dots per horizontal division).

[marmad]

In regards to your previous post:  Dots mode 100us --> 200us.  The 200us setting does produce a display with unique dot artifacts at that one setting but, if I stop the sampling and zoom in, the sampling rate does match what is displayed at the top of the screen (by counting the dots per horizontal division).

Thanks, JDubU! Yes, it appears as if it's a bug that's between sample memory and display memory - since the sample memory is correct when stopped. But there is something wrong in the routine which is building the intensity map in the display memory - thus screwing up the waveform update numbers as well. But it's causing errors at other time base settings as well - you can tell by switching to 1.4M sample depth and seeing what appears to be a higher sample rate (which should, in fact, be a lower sample rate).

I sent an email onto Drieg to report the bug to Rigol.

[eV1Te]

Found a bug in the new firmware - incorrect setting of the sample rate in Dots mode at certain time bases (and maybe something else too).

Perhaps someone can confirm on their DSO? Also, if someone still has FW v.01.01.00.02 installed, could they please double-check to see if this bug is present in that FW or not?

To test:

Single channel on; Dot mode; test signal input (e.g. 1MHz sine) - the bug affects both AUTO/14M/56M memory settings (but not the others, I think).

Go from 100us/div to 200us/div - and watch the image change. The sample rate is clearly wrong; in the image it's supposed to be 2GSa/s:

I don't see what is wrong? if you stop the scope and "zoom in" horizontally until you see the points, what is the distance? 0.5 ns?

I haven't seen Rigol actually specifying how many points the scope can show at once on the same screen, I guess it decimates the data in order to to get the 256 intensity gradings it is rated for.

For example the scope has 256 intensity gradings if i remember correctly and how many pixels wide is the graph part of the display? 700 pixels maybe?

256*700 dots = 179200 points at once on the screen. What is screen fps? 30? 179200 * 30  = 5376000 points on screen per second

You have 5.6 Mpoints memory which according to the table gives 88 Wfrm/s = 88*5600000 =  492800000 points captured per second

5376000/492800000 = 0.011 = ca. 1 % of the captured points are displayed on the screen.

[marmad]

I don't see what is wrong?

Here is the EXACT same signal and settings - except with 2 channels ON - and a 1GSa/s rate (LOWER than the first image). Can you see what's wrong now?

[Bugware]

Same here with HW2 and old FW 00.01.01.00.02. (I could only test it with 16Mhz, but same at 200µs)

[eV1Te]

I don't see what is wrong?

Here is the EXACT same signal and settings - except with 2 channels ON - and a 1GSa/s rate (LOWER than the first image). Can you see what's wrong now?

I agree that it should look as good as that with one channel also, I just wanted to point out that when you have "too" many points in memory and an unfortunate frequency of the input signal you can get an apparent aliasing on the screen even though you have intensity graded display. But when the difference is that big it must be something else I would think as you pointed out.

What happens when you have anti-aliasing turned on in the first case, does it get better?

[marmad]

I agree that it should look as good as that with one channel also, I just wanted to point out that when you have "too" many points in memory and an unfortunate frequency of the input signal you can get an apparent aliasing on the screen even though you have intensity graded display. But when the difference is that big it must be something else I would think as you pointed out.

Again, look at the chart I posted - the waveform update rate is TRIPLING when using VECTORS instead of DOTS? That shouldn't happen: it should get slower - there is clearly a big bug.

[marmad]

Here's another @ 500us/div with 1MHz sine wave input. Same settings in both images except for memory depth. Top image is supposed to be 2GSa/s with 14M - bottom image is 200MSa/s with 1.4M. The bottom image is the correct one:

[marmad]

@JDubU: Did you install the 300MHz option? It would be nice to know if this is connected to that option - or inherent in the firmware in general.

[JDubU]

@JDubU: Did you install the 300MHz option? It would be nice to know if this is connected to that option - or inherent in the firmware in general.

I am seeing the Dot mode artifacts at 200us/div using the latest firmware with no options installed.

[marmad]

Same here with HW2 and old FW 00.01.01.00.02. (I could only test it with 16Mhz, but same at 200µs)

I am seeing the Dot mode artifacts at 200us/div using the latest firmware with no options installed.

Thanks, Bugware and JDubU.


Revamped the BUG LIST on the opening page to reflect just the last two firmware releases (v.01.01.00.02 / v.02.01.00.03) - and added the older AC-coupled Trigger bug (thanks, Teneyes!) and the newly discovered DOTS mode bug.

[Bugware]

I have just upgrade my device to the new Firmware 00.02.01.00.03. I had two Bugs with the old Firmware 00.01.01.00.02 and they are not solved. But I noticed, that the Screensave is now much faster!

First Bug:
The intensity graded waveform gets bright horizontal lines in the waveform when statistics is turned on:






Second Bug
When the trigger is change from DC Coupling to AC or HF Reject Coupling then the trigger point slips to the "left" about approx 2µs:








An other Bug in Firmware 00.01.01.00.02 is now fixed. When in Time Base X-Y the Horizontal knob was pushed to delayed sweep "unavailable function" is displayed. But after change to Y-T Time Base the delayed sweep background is activated but not for the Waveforms. This Bug is now fixed.

[marmad]

First Bug:
The intensity graded waveform gets bright horizontal lines in the waveform when statistics is turned on:

I'm not sure I would classify this as a bug or not. When you turn on Statistics, the waveform display area is reduced from 700x400 to 700x360 by the display processor before overlaying measurement stats. Those small horizontal lines you see are artifacts from the reduction (exactly 5 lines per div.) from 50 vertical pixels per div. to 45. Perhaps Rigol could fix this, but I'm SURE it would mean slower update rates for a smoother algorithm (which, IMO, isn't worth it).

Second Bug
When the trigger is change from DC Coupling to AC or HF Reject Coupling then the trigger point slips to the "left" about approx 2µs:

As noted in my post right above yours, this bug is already in the list: #17.

[Bugware]

First Bug:
The intensity graded waveform gets bright horizontal lines in the waveform when statistics is turned on:

I'm not sure I would classify this as a bug or not. When you turn on Statistics, the waveform display area is reduced from 700x400 to 700x360 by the display processor before overlaying measurement stats. Those small horizontal lines you see are artifacts from the reduction (exactly 5 lines per div.) from 50 vertical pixels per div. to 45. Perhaps Rigol could fix this, but I'm SURE it would mean slower update rates for a smoother algorithm (which, IMO, isn't worth it).

Sure that is a scaling problem. But I think all data in the display memory must be scaled?! So maybe there is no change in the update rate, so my thought...

Second Bug
When the trigger is change from DC Coupling to AC or HF Reject Coupling then the trigger point slips to the "left" about approx 2µs:

As noted in my post right above yours, this bug is already in the list: #17.

I see. Sorry I have misunderstood the bug #17 in the list. So then this is only a confirmation of that.   BTW. the offset is not only with AC Coupling but also for LF and HF Reject Coupling...       

[WVL_KsZeN]

Was wondering if anyone could confirm this bug aswell:

If i use the test signal as input (1.000kHz) and change my timebase using fine adjust, the measurement go all weird (while they dont have to)

- attach channel 2 (f.e.) to the test signal
- press auto
- you should now have a timebase of 200us
- active frequency measurement (2nd in left menu)
- it should read 1.000kHz
- change timebase to 500us -> it still reads 1.000kHz
- change timebase to 1ms -> it still reads 1.000kHz
- change timebase to 2ms -> it still reads 1.000kHz
- change timebase to 5ms -> it still reads 1.000kHz
- change timebase to 10ms -> it still reads 1.000kHz
- now, change the scale adjust from coarse to fine
- change timebase to 9.350ms -> frequency reads 891.3Hz!!!

now, this is way off (more than 10%) and doesnt have to be. on the screen, there's 14*9.35ms=130.9ms of data. In that time, there have been 130.9 oscillations. Maybe it's possible the scope is reading one oscillation more or less, but imo the max error should be /130.9 * 100% = 0.76% = (9.9924Hz to 1.0076kHz), not more than 10%! Using a slightly smarter algorithm, the error should be even smaller..

This is with the latest firmware. Can anyone confirm this?

if i set the timescale one higher (9.4ms), the scope reads 1.064Khz, one lower (9.3ms) and it reads 1.075Khz, which is about the error I'd expect.

Same thing happens on other timebases, f.e. on 5.450ms the reading is >8% off!

Update :

It also seems to depend on the numer op points being taken.

on the 5.45ms timescale, the auto mem depth is set at 7.63Mpts when using only one channel. The reading is 917.4Hz
When changing the mem depth manually, you get :

14kpts - 1.019khz
140kpts - 1.019khz
1.4mpts - 1.019khz
14mpts - 1.019khz
56mpts - 1.019khz

so only the auto setting for the mem depth is way off.. isnt that weird?

At a timescale of 7.05ms/division, I'm even getting a reading of 886.5Hz, which is more than 11% off.. this is at a mem depth of 9.87Mpts. Any other manual mem depth gives a reading of 1.013kHz..

[marmad]

Sure that is a scaling problem. But I think all data in the display memory must be scaled?! So maybe there is no change in the update rate, so my thought...

There is the normal scaling done between sample memory and display memory. The scaling for statistics is clearly done after this (since it's doubling lines), as part of the overlay (adding measurements, screen icons, etc).

I see. Sorry I have misunderstood the bug #17 in the list. So then this is only a confirmation of that.   BTW. the offset is not only with AC Coupling but also for LF and HF Reject Coupling...   

Yes, I knew, but the bug clearly affects filtered triggers - so fixing it for one will likely fix it for all - but I added *filtered* to the bug description to make it clearer.