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

[AndersAnd]

Batronix haven't even updated their website yet to mention anything a bout DS2000A series scopes.

Maybe so, I don't know. Here is however the same picture with text "lower over shoot" under DS2000A web page:
http://www.rigol.com/prodserv/DS2000A/

You probably missed my post above which proves it was already on Batronix on October 13, 2012, long before HW 2 came along. So this screenshot was made on HW 1 and comparing to older scope series. It has nothing to do with HW 2 vs. HW 1.

[marmad]

This got me thinking about when Steve Jobs said people were holding it wrong when customers complained about poor iPhone antenna signal. 

Well, thank you for the complement - but I'm not sure I should be classified as the Steve Jobs of Rigol. I mean, I am on the phone everyday telling Rigol designers, engineers and programmers what to do, but still.... perhaps the Steve Wozniak of Rigol would be more appropriate? 

I do like your idea for mugs and t-shirts though. Perhaps it can be a dual line: 'You're holding it wrong' for certain people; and 'Wahhh, I can't get it to work' for others?   

[EV]

You probably missed my post above which proves it was already on Batronix on October 13, 2012, long before HW 2 came along. So this screenshot was made on HW 1 and comparing to older scope series. It has nothing to do with HW 2 vs. HW 1.

Ok, so it is old picture and they advertise on web page http://www.rigol.com/prodserv/DS2000A/ that over shoot of DS200A is lower but don't say lower of what.

[AndersAnd]

Ok, so it is old picture and they advertise on web page http://www.rigol.com/prodserv/DS2000A/ that over shoot of DS200A is lower but don't say lower of what.

Yeah it's very easy to make random comparison claims when you don't tell what you're actually comparing against. Noone will ever be able to hold it against you.
That's what happens when marketing people and not engineers are in charge of the message.

[marmad]

Show off!     

I'm sure there's some young hotshot out there who can do it in 12.3 seconds

[NikWing]

it's really odd ...
I entered the test-serials using the DSO editor and the rotary enc.
no problems with that
but if I try to select let's say the probe correction, I might end up with the next or prev value (beside a laggy response during selection)

[marmad]

it's really odd ...
I entered the test-serials using the DSO editor and the rotary enc.
no problems with that
but if I try to select let's say the probe correction, I might end up with the next or prev value (beside a laggy response during selection)

It's true that moving the selection bar in a menu is more unresponsive than in the editor - it requires slower movements to prevent overshoot (due to the lag) - perhaps the menus are dealt with in a different way than the screen overlay by the FW? Also, moving the selection bar left or right, IMO, seems slightly more natural than up and down.

[marmad]

Happy New Year, everyone! 

Here's what the festivities looked could have looked like in my neck of the woods when 2014 arrived (if we were all in the same time zone, weather was clear, and fireworks were more powerful):

Ahh... good ole editing 

[AndersAnd]

Happy New Year, everyone! 

Here's what the festivities looked like in my neck of the woods when 2014 arrived:

Happy New Year. But that's not what Europe looked like. Kind of obvious when you think of it, otherwise why would some countries be red, others yellow and others again blue?
Besides if it's supposed to look like fireworks at midnight, the UK would not be lit up at the same time as mainland Europe, as they celebrate New Year an hour later and Moscow i 3 hours ahead of CET.
And what's up with all the blue light in the middle of the sea between the UK and Norway/Denmark?

http://www.daily-headlines.net/2013/01/spectacular-images-of-europe-in.html

Although this photo spread Internet expanses as "spectacular photos Europe at midnight 1 January 2013. Recorded by NASA," we'll have to disappoint you, though someone just played well in Photoshop.

Maybe one day New Year's footage from space really look like that - when NASA made ??an even better photo equipment, when the fireworks on the ground look like a nuclear war, and when all countries regardless of the time zone they decide to welcome the New Year at the same time.

[NikWing]

haha, yes that's fake
(also the other europe at night pics flying around)

but nevertheless, happy new 2014

[marmad]

Besides if it's supposed to look like fireworks at midnight, the UK would not be lit up at the same time as mainland Europe, as they celebrate New Year an hour later and Moscow i 3 hours ahead of CET.

No kidding... I assumed it was composited or Photoshopped.

[EV]

Happy New Year to All!

[marmad]

I wish the Navigation Knob would also do high speed horizontal position in normal mode the same way it does in delayed sweep and record playback modes.
I also wish that the inner knob had a finger indent so that it could be spun continuously (like many professional video playback controllers).  The way it is designed now, I find it to be almost useless and, instead, use the small horizontal position knob which has the same function but can be spun faster and with more control.

JDubU: I missed this comment from you when you originally posted it, but I thought it brings up a good point which I agree with: the Navigation knob is underutilized when it isn't functioning for moving through frames, moving the delayed sweep window, or as a fast variable selector: it should automatically be working as a fast horizontal position knob.

Also, while I don't care as much as you do about whether the inner knob has a finger indent, I do think it's a bad UI choice to have the inner knob incrementing at exactly the same rate as the horizontal position knob when in Delayed Sweep. You've got one knob (Navigation) which increments very fast - and then two knobs which increment very slowly at the same rate (although you can spin the h.pos. knob faster if you want). The inner knob should increment at a medium rate - making it much easier to hone in on the desired position.

Perhaps I'll pass these suggestions along in the hopes Rigol will implement them in the next firmware.

[JDubU]

... You've got one knob (Navigation) which increments very fast - and then two knobs which increment very slowly at the same rate (although you can spin the h.pos. knob faster if you want). The inner knob should increment at a medium rate - making it much easier to hone in on the desired position.

Perhaps I'll pass these suggestions along in the hopes Rigol will implement them in the next firmware.

Sounds good!

[Wim13]

So far testing, i think it is better as Rigol makes two different FW for the DS2000,
one version for the non A and a second version for the A model.

I think it slows down and makes FW complicated , now the FW has everytime
make decisions and have to think , ohh this is a A or a non A.

[marmad]

I think it slows down and makes FW complicated , now the FW has everytime
make decisions and have to think , ohh this is a A or a non A.

Really? I haven't noticed any slowing down - the newer FW seems better to me. Can you give a specific example to demonstrate?

[Giorg]

Today I've updated directly from SW 00.01.01.00.02, HW 1.0.2.0.0 with all options installed and 200 bw to latest FW version. I've also cleared the memory as suggested. Any warning about this procedure? Anything else I should know?

Scope freezed while changing time division today, but maybe it's not related to the update.

thank you!

[marmad]

While working on the new version of RUU, I've discovered two (relatively minor) firmware bugs involving SCPI commands (and added to the list on page 1). One of them is old (I noticed it already back in v.01.00.00.03) - one of them is new in this version. When reading display memory from the DSO, you should always get back 1400 bytes (unless you STOP the DSO and zoom out).

1) OLD BUG: When in HighRes mode and reading display memory from the DSO, if the time base is <= 20us, the DSO returns 1398 bytes instead of 1400.

2) NEW BUG: When the DSO is STOPped and reading display memory from the DSO while zooming out (i.e. make the time base bigger so the waveform is shrinking on the screen), the DSO returns (correctly) a decreasing number of display memory bytes until < 6, and then it incorrectly starts sending 1400 bytes every time (which is a nonsense waveform) instead of 2 (a single line).

You can see bug #2 in action (non-destructively) if you run RUU, then RUN and STOP the DSO with a small sample length. Then start zooming out. When the waveform reaches a single vertical line on the DSO screen, RUU will start displaying a wild, nonsense waveform - which is some part of overwritten display memory which the DSO is sending (incorrectly) to RUU. Kind of funny... 

[PA0PBZ]

Traces when using type as dots or vectors look quite different. Why?
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.

Carrington asked me to test this on my non-A hardware version 2 scope, with latest software and all upgrades and I get the following. Not sure if I missed a setting but it looks ok:

^{(Had no input for CH2 at hand)}

Oops... looks the same at 1nS...

[PA0PBZ]

And 1nS 

[alank2]

I don't know if it is a bug or an inconsistency, but in ds2302 mode if you turn the unit off and on and go to change the bandwidth for a channel, it will not open a menu and let you use the spin knob to select it.  It will just toggle the setting to the next one.  If you restore a saved configuration or default settings, you will get the menu.  If you power cycle again, the menu will no longer work and you will be toggling through the options until you restore settings/defaults again.  This is on both HW 1.0.1.0.0 and HW 1.0.2.0.2.  You always get the menu as expected in ds2202 mode.

[PA0PBZ]

Bandwidth DS2302 HW 2, signal generator on 1 volt, 10 Mhz steps:

[Carrington]

Bandwidth DS2302 HW 2, signal generator on 1 volt, 10 Mhz steps:

Awesome... 

[alank2]

Bandwidth DS2302 HW 2, signal generator on 1 volt, 10 Mhz steps:

Can you repeat that in DS2202 mode with HW 2?

[JDubU]

And 1nS 

Something looks wrong in your screen captures: (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg362905/#msg362905).

How are you getting a continuous trace of closely spaced dots?  You should be seeing only one dot per horizontal division (1 ns/div, 1G samples/second).