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

[marmad]

However, the settings in regular Save do have an effect on QuickPrint. The file type (PNG, BMP etc.) you set there is also used for QuickPrint.

That's true - and important to note. It's odd that Rigol didn't just allow a separate file type to be set in Print Setup as well.

[Teneyes]

2) When the RS-232 baud rate is set to AUTO 57600, it is incorrect. When set to USER 57600, it operates correctly.[/b]

OK Now,
first Pic shows Error , missing bytes 4 out of 13
second shows correct today on new firmware

Which is what I expected after receiving this E-mail from Rigol back in July /2013
---------------------------------
Dear xxxx 
  OK,I agree with you ,will check with R&D .
  Maybe 57600 is right ,then just need change internal programme .
  Best regards,
  Vivien Liu
Marketing Department
RIGOL Technologies,INC.
http://www.rigol.com
---------------------------------
Explanation  20% duty cycle of 11.52 KHz x4
           = 10 bits at 57.6KHz
           = 1000010000
           = 1     00001000   0
           = strt, 00001000, stop
           = strt,   xEF   , stop   (LSB endian)

 

[marmad]

OK Now,
first Pic shows Error , missing bytes 4 out of 13
second shows correct today on new firmware

Great - thanks for that, Teneyes! Any chance you can also check the ASCII decode issue?

Edit: Removed that bug from the list.

[JDubU]

Is it my imagination or did the latest firmware (00.02.01.00.03) change the behavior of the vertical gain and position controls so that, while adjusting them, new sample updates to the display are temporarily stopped?  It seems to make changes to the trace visually smoother and less jerky during the adjustments.  This can be demonstrated by using Auto trigger and changing the edge trigger level outside the range of the waveform (no trigger/free running).

Maybe it has always been this way and I am not remembering correctly?

[marmad]

Is it my imagination or did the latest firmware (00.02.01.00.03) change the behavior of the vertical gain and position controls so that, while adjusting them, new sample updates to the display are temporarily stopped?  It seems to make changes to the trace visually smoother and less jerky during the adjustments.  This can be demonstrated by using Auto trigger and changing the edge trigger level outside the range of the waveform (no trigger/free running).

Maybe it has always been this way and I am not remembering correctly?

Well, it seems about the same to me - but I couldn't be sure without comparing. The behavior of the firmware of holding the last captured waveform while adjusting size or position has has been around now for the last 3 FW releases.

But believe it or not, for the first two FW versions, (00.01.00.02 & 00.01.00.05), the DSO cleared the display completely and attempted to restart the sweep while adjusting the waveform (first 'bug' mentioned on this list); meaning that if you were on a slow time base, the waveform just vanished while trying to adjust the size or position.

[JDubU]

Well, it seems about the same to me - but I couldn't be sure without comparing. The behavior of the firmware of holding the last captured waveform while adjusting size or position has has been around now for the last 3 FW releases.

I think you're right.  Playing with it a bit more, fine position adjustment still has the feel of "two steps forward and one step back".
Guess it was just wishful thinking...

[PA0PBZ]

RS-232 Decode on 00.02.01.00.03

Looks like the § comes out as a * (not sure what character set that belongs to anyway) but the rest is there:

[marmad]

RS-232 Decode on 00.02.01.00.03

Looks like the § comes out as a * (not sure what character set that belongs to anyway) but the rest is there:

Great - thanks for that, PA0PBZ! It's nice to know that Rigol continues to listen to our feedback and iron-out bugs.

[marmad]

The ASCII decode bug (now fixed) was the last one on the list I created on the first page of this thread - excluding the AntiAliasing problem. But honestly, I'm not sure what Rigol can do about that unless they ignore Agilent's (HP) patent (or find a way around it).

OTOH, the safest way to avoid aliasing is with faster sample rates - and the DS2000 can sample @ 2GSa/s down to 2ms/div - while the Agilent DSOX2000 can only sample @ 2GSa/s down to 2us/div - so it needs the anti-aliasing feature more.

[marmad]

One additional change that Rigol really should make to their firmware - and it's also worth noting for users so they will be inclined to do it manually:

If the 56M option is installed, the AUTO memory depth setting should automatically switch to using the 56M sample depth when the time base is <= 1ms. That's because the waveform update rate is not substantially different between the two memory depths (56M/14M), but the sample rate is 2 - 4x faster with 56M at those time base settings - which significantly helps to reduce aliasing.

[marmad]

First image: The "Auto" indicates that it isn't triggered.  Set it to normal triggering if you only want triggered waveforms.  The stuff on the left doesn't look like it falls below -32mV, so it's not going to trigger there.  The stuff on the right just barely does, so I would think you'd get triggering on that if you set it to normal. 

Definitely should be using NORMAL triggering - as well some bandwidth limiting if you've got your DSO tweaked to 300MHz. In fact, it's possible that the 300MHz installed option could be causing problems on non-A models (if you installed it) - since it was never actually intended by Rigol to be activated accept on A models.

[Teneyes]

Carrington showed displays of  Auto Triggering, and the position of the waveform at the trigger point
That reminded me  to check the AC coupled Trigger bug I reported back in july here
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg256168/#msg256168

That bug is still there. (Noone confirmed back in July)

Trigger position should be at the Center
   1   DC coupling, NO offset
   2.  On  100ns/div the offset of 50nsec  is  1/2 div
   3.  On   50ns/div the offset of 50nsec  is  1  div
   4   On   20ns/div the offset of 50nsec  is  2 1/2 div

[marmad]

@Teneyes: Sorry, somehow I missed/forgot the AC-coupling trigger bug, and didn't add it to the list (so it wasn't fixed by Rigol). I think it was because of the busy summer renovations of my loft - but I will add it soon and pass it along to Drieg - currently on WiFi on fast train to Paris for the weekend

[marmad]

I'm away from my DS2000 until Monday, but perhaps someone else can test using the Trigger Out with the new v.2 firmware?

I'm not sure Rigol could have done anything about it in FW, since it might have been hardware related (on HW v.1 models), but I'm pretty sure our 'concerns' about it were reported to them via Drieg.

To sum up the previous findings:
Delay of Trigger Out when using CH1/CH2 as trigger: ~210ns +/- 4ns
Delay of Trigger Out when using External Trigger as trigger: ~163ns +/- 4ns

Anyone want to check if it's still the same?

[Carrington]

I'm away from my DS2000 until Monday, but perhaps someone else can test using the Trigger Out with the new v.2 firmware?

I'm not sure Rigol could have done anything about it in FW, since it might have been hardware related (on HW v.1 models), but I'm pretty sure our 'concerns' about it were reported to them via Drieg.

To sum up the previous findings:
Delay of Trigger Out when using CH1/CH2 as trigger: ~210ns +/- 4ns
Delay of Trigger Out when using External Trigger as trigger: ~163ns +/- 4ns

Anyone want to check if it's still the same?

After of the above.
I can confirm that the the trigger out delay is ~230ns, for the two last firmwares on my DS2072 HW v.1.

CH1= "The ghost pulse."
CH2= To Trigger Out.



How nice, X-Y cursors, in the firmware 02_01_00_03!

Have a great weekend.

[marmad]

I can confirm that the the trigger out delay is ~230ns, for the two last firmwares on my DS2072 HW v.1.

Thanks, but that's not a precise measurement. There is a fixed delay plus/minus some jitter - and a different delay with External trigger. I'd like to get specifics; as in this image:

[Carrington]

Ok, now I understand.
@marmad:
What is the input to the channel two in the picture above?
And what is the triggers source CH2 or CH1?

[Teneyes]

Mystery solved ...
Impressive because it was so powerful... reached up to 150mVpp
SDS8102V one meter away:

Yes the DSO's are sensitive, and be aware of RFI
See the FM Station RFI I picked up from my Finger in first picture last year (70MHz)
see again with mod. today in 2nd Pic (counter almost locks on)

[Teneyes]

Trigger on External and check Trigger out delay and Jitter
On some Frequency ,jitter is less

[Carrington]

Mystery solved ...
Impressive because it was so powerful... reached up to 150mVpp
SDS8102V one meter away:

Yes the DSO's are sensitive, and be aware of RFI
See the FM Station RFI in picked up from my Finger in first picture last year (70MHz)
see again with mod. today in 2nd Pic (counter almost locks on)

Yeah, check this:
https://www.eevblog.com/forum/testgear/review-of-owon-sds7102/msg290624/#msg290624

[Teneyes]

@Carrington
Does EMV35 come in light Green by the DecaLiter? 

[Carrington]

@Carrington
Does EMV35 come in light Green by the DecaLiter? 

I don't know, the paint of the 200ml EMV35 pot was brown (cooper). There is also gray color (Nikel).

[EV]

Here is picture about Trig out delay.
New FW 2.0...
-Ch1: pulse, Delay-Cal = 22 ns
-Ch2: trig out, Delay-Cal = -200 ns (min value)
Total delay = 200 + 22 = 222 ns.

[NikWing]

after reading so many postings about the DS2xxx DSOs, I have some questions ... hm

like, what's the meaning of the anti-aliasing problem
or, is the FFT working correctly or isn't it? (there've been some example screenshots where the curve didn't look like it should)

edit: where can I get firmware-updates, if not someone from this forum uploads them?

[JDubU]

Is a changelog available for the latest DS2000 firmware (00.02.01.00.03)?