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

[ve7xen]

How could BMPs be faster than PNGs? They are often ~100x bigger - and writing to an external device usually requires more time than processing - although I can't say I've actually timed saving BMPs on the DS2000. Also, I don't know if the brand of USB stick you're using (or FW 01.00.02) affects save/transfer rates - but my timed speeds are:

PNG is quite often slower even on a fast PC depending on how you set the compression. The CPU in these is not fast. It wouldn't surprise me that much.

However I've done some more poking around and it seems that the problem only happens if you set Storage>Storage to Picture instead of Traces. I'm not sure what the difference is since it seems to produce identical image files, but Traces doesn't allow filetype selection and takes from 2-5s to write to the USB and makes a BMP file.

Thanks for setting me straight, that's a lot better .

[marmad]

However I've done some more poking around and it seems that the problem only happens if you set Storage>Storage to Picture instead of Traces. I'm not sure what the difference is since it seems to produce identical image files, but Traces doesn't allow filetype selection and takes from 2-5s to write to the USB and makes a BMP file.

I'm happy you figured out a method to make it quicker for yourself (although saved traces [the channel data itself] is not the same as a saved bitmap of the entire screen) - but it doesn't really resolve the issue or shed light on the problem behind it - which might be helpful for other 01.00.02 users here.

It takes you 45 seconds to save a PNG picture - but it takes me 15 seconds. Is this a question of firmware - or different USB sticks?

Also, would you please mind posting the time (and connection method) it takes to transfer & save a PNG using RUU? This might help resolve things.

Thanks!

[kape]

Well, as I mentioned in the video and a couple of times since, I recommend people buying in the EU use EEVBlog member drieg. Same price/free shipping as Batronix (I think the price is fixed in the EU - same as in NA)- but much better before/after sales support. Drieg is the one testing and reporting all of the bugs we discover here on the blog to Rigol - and I gather he is perhaps the biggest expert here on all things Rigol.

Thanks for this information.
It seems that the DS2072 is lacking the alt trigger mode and dual timebase, or have I missed something?

Marmad, can you briefly summarize, what were the main reasons for replacing the Owon with DS2072? Can these reasons justify the price difference...?
Btw, there seems to be slight difference in end user prices (with VAT included) when comparing Batronix to Silicon electronics...(maybe due to different VAT amount).

[marmad]

It seems that the DS2072 is lacking the alt trigger mode and dual timebase, or have I missed something?

No alternate trigger - but many other standard included triggers (plus even more via one of the option packages). Yes dual timebase - called Delayed Sweep - which is very easy to enter and exit (via a simple push of the Horizontal Scale knob).

Marmad, can you briefly summarize, what were the main reasons for replacing the Owon with DS2072? Can these reasons justify the price difference...?

Well, actually, the Owon was replaced with a Hantek - which was later returned. I then continued using my analog Tek scope until I read about the Rigol DS2000 series. But I've spoken/written about this quite a lot already (short synopsis here) so suffice it to say that all of your instincts (and the stuff you wrote in your previous post) are correct.

Btw, there seems to be slight difference in end user prices (with VAT included) when comparing Batronix to Silicon electronics...(maybe due to different VAT amount).

I bought my DS2072 through my company (so minus VAT), but if you send drieg a PM or email about the difference, he might be able to help you out.

[JOHNJB]

[/quote]

Thanks for the measurement..,
So the test on the BNC is almost the same,
Only on the probes, thats intresting, i cannot reproduce that.
How was you setup for the probe testing...??
[/quote]

This is the configuration used (photo).
The coaxial wire as not SWR because finishes with an -30dB attenuator,
As the oscilloscope has no 50H terminator, must place a T whit the 50H load.
The other branch of the T, is connect at BNC of scope.
This small (not at high frequencies) branch approx 8cm. is not well coupled and cause inaccuracies at high frequencies.
I think the measures are very accurate up to 200Mhz.

The probe is connected like in the photo, not used the grund co-codrile tip.

John 

[ve7xen]

I'm happy you figured out a method to make it quicker for yourself (although saved traces [the channel data itself] is not the same as a saved bitmap of the entire screen) - but it doesn't really resolve the issue or shed light on the problem behind it - which might be helpful for other 01.00.02 users here.

Okay I did some more testing on this issue. Saving PNGs definitely takes > 30s, whether from the Storage menu or from the Print button after choosing PNG in storage. BMPs do seem to be quick though, around 2s. I think my confusion was in using the Storage menu to change the Print format, I think I must have not confirmed the setting back to BMP before pressing Print.

It takes you 45 seconds to save a PNG picture - but it takes me 15 seconds. Is this a question of firmware - or different USB sticks?

Could easily be either

Also, would you please mind posting the time (and connection method) it takes to transfer & save a PNG using RUU? This might help resolve things.

6 seconds over Ethernet, from clicking Save on the file picker dialog. BMP is about the same. I don't have a long enough USB cable (or any free ports for that matter...) to test using USB. Thanks for your help

[marmad]

Okay I did some more testing on this issue. Saving PNGs definitely takes > 30s, whether from the Storage menu or from the Print button after choosing PNG in storage. BMPs do seem to be quick though, around 2s.

Unfortunately I'm not around my scope for awhile so that I might check myself. I was fairly certain that PNGs took about 15 seconds to save, but I never timed the other formats. Now I'm wondering if I timed correctly - or if Rigol optimized their BMP -> PNG conversion code in 05. Any other owner want to time a PNG save to USB stick on their DS2000?

6 seconds over Ethernet, from clicking Save on the file picker dialog. BMP is about the same.

Ok, that's the same as FW 01.00.05 - so no changes there. The Rigol only transfers BMP files (RUU must do the conversion to any other image type) so the format shouldn't affect the speed in any noticeable way.

Thanks for doing the further testing 

[TP]

On my DS2072 01.00.02 FW I get the following for saving screen shots to USB sticks:

San Disk 1GB, "Print" 56 sec, "Save" PNG from Storage menu 59 sec
Kingston 2GB, "Print" 57 sec, "Save" 60.5 sec

(Seems kind of long for a file that's only 22KBytes)

[EV]

DS2202, FW 01.00.05

Kingston DataTtraveler 2.0 FAT32 4GB

PNG: Save 20 sec, Print 16 sec
BMP: Save 11 sec, Print 8 sec

[marmad]

On my DS2072 01.00.02 FW I get the following for saving screen shots to USB sticks:

San Disk 1GB, "Print" 56 sec, "Save" PNG from Storage menu 59 sec
Kingston 2GB, "Print" 57 sec, "Save" 60.5 sec

DS2202, FW 01.00.05

PNG: Save 20 sec, Print 16 sec
BMP: Save 11 sec, Print 8 sec

Wow,  so it does appear as if Rigol either optimized their code in FW 05 - or more likely, fixed a bug - since you'd have to write REALLY BAD code to produce something that would take almost 60 seconds to convert an 800x480x24 bitmap to PNG format and save it.

[kape]

On my DS2072 01.00.02 FW I get the following for saving screen shots to USB sticks:

San Disk 1GB, "Print" 56 sec, "Save" PNG from Storage menu 59 sec
Kingston 2GB, "Print" 57 sec, "Save" 60.5 sec

DS2202, FW 01.00.05

PNG: Save 20 sec, Print 16 sec
BMP: Save 11 sec, Print 8 sec

Wow,  so it does appear as if Rigol either optimized their code in FW 05 - or more likely, fixed a bug - since you'd have to write REALLY BAD code to produce something that would take almost 60 seconds to convert an 800x480x24 bitmap to PNG format and save it.

How slow is the image save speed of the DS2000-series compared to other scopes (Owon, Hantek..)? I was surprised how slow these are compared to other (like Tektronix). If I recall correctly, on those more expensive models it won't take many seconds...

[marmad]

How slow is the image save speed of the DS2000-series compared to other scopes (Owon, Hantek..)? I was surprised how slow these are compared to other (like Tektronix). If I recall correctly, on those more expensive models it won't take many seconds...

Well, I don't have another DSO to compare against anymore, but two things to keep in mind:

We're talking about a bitmap image - not the voltage levels of the waveform (which is way faster) - so the speed is linked to the size and depth of the display, which is 800x480x24 bits on the DS2000 series. That's 9.2Mb or 1.1MB. I don't think Tektronix has produced a DSO with a screen resolution higher than 640x480, have they (probably even smaller than that)?

The Owon is 800x600x8; which is 3.8Mb or 480kB. Apparently, aghp (a seller of Owon DSOs) claims that the fugly display on the Owon is IN FACT 24 bit color (but strangely without any anti-aliasing of any screen elements like the Rigol has). I neither know for sure - or care - but I'll say this, if it IS 24-bit color, it's the worst use I've ever seen of 24-bit.

Secondly, the Rigol has a special SCPI command which transmits that screen bitmap to the PC in about 2.3 seconds over USB. Try to do that with the Owon or Hantek.

[marmad]

New version of the Rigol UltraVision Utilities uploaded... details here.

[aghp]

We're talking about a bitmap image - not the voltage levels of the waveform (which is way faster) - so the speed is linked to the size and depth of the display, which is 800x480x24 bits on the DS2000 series. That's 9.2Mb or 1.1MB, The Owon is 800x600x8; which is 3.8Mb or 480kB.

Do you have any data to this argument?

Attached image is authentic OWON -> USB -> PC Transferred bitmap image. Is it 800x600x8?

You make mistakes quite often when you talk about Owon. Selectively forget the truth?
But I'm very lazy to correct all becouse - who cares.

(just random image from some old set of trig test, and not at all best)
Now, marmad, how much data have been transferred? bmp parameters show that there is 800x600x24bit.

Raw data and imagination are two different things.

[marmad]

You make mistakes quite often when you talk about Owon. Selectively forget the truth?
But I'm very lazy to correct all becouse - who cares.

Fine, Kari, I made an honest mistake - I assumed because of the ugly display color scheme that Owon uses - and no anti-aliasing of any screen elements - that it must be 8-bit color. So I'm wrong - big deal. It doesn't change the fact that the image on the 800x600x24 bit display on the Owon looks like a child's toy when compared to the image on the Rigol screen - because Rigol put some thought and design into theirs.

And I don't selectively forget anything - but there is clear evidence that you do. Jesus, man, get a life already. Lurking, hidden most of the time, moving around these review threads I started, trying to make a buck. Go ahead and create some original content of your own on EEVBlog instead of sponging off of mine - I mean, damn, you didn't even have the idea of buying your first SDS7102 on your own - you got that from my review.

[aghp]

Go ahead and create some original content of your own on EEVBlog instead of sponging off of mine - I mean, damn, you didn't even have the idea of buying your first SDS7102 on your own - you got that from my review.

Can not correct your mistakes or lies? Then you come angry. Grow up.

I have started with digital oscilloscopes somewhere around 1980 and after then looked world around also long time ago. Some past years also name Owon and many others.

I come here inside your thread just as I see some lie and now even more about me.
I keep silence normally but some times I see clear mistakes or lies I will correct it.
And after your answer now need correct more.

Just ask Why? Now you continue lies and I want correct also this. "I mean, damn, you didn't even have the idea of buying your first SDS7102 on your own - you got that from my review." <- you really have some problem?  If you tell that you believe or maybe... but you tell it like some kind of truth and in this point it come just to category named lie. So, if you do not know, perhaps it is better to keep it only in own mind or tell that you do not know but still you want say.

Years I have investigated new digital scopes and other test and measurement equipments. For my job, for my hobbies and also for sell some new equipments and not only second hand refurbished equipments what I have much more long time.
But this is from Finland and this you did not know (and it is just one example only):

http://mittalaitteita.lefora.com/

"
22 February 2010 08:33 PM

Pitäisikö valmistautua siihen ajatukseen että laadukkaat huippumerkit tulevatkin joskus Kiinasta?

Tekway, Rigol, Owon (1) , Atten, Uni-T (lempinimi Uni-Toy).

.
.
.





(Image)
20 August 2011 02:50 PM


Ai mikä tämä on?

No se on Owonin  uusi SDS malli.  Owon on itse kehittynyt muutamassa vuodessa kapisesta moskan tuottajasta varteenotettavaksi ja nyt viimeisimpänä iskivät markkinoille aikamoisella uutuudella. (2)

(ei siis todellakaan ole se wanha parjattu Owonin DSTN sekoilu...jossain muutenkin kapisessa mallissa)"

(3)

"

3)  Some day around 2007-2008 I look littlebit more (in real life, not only www) about Owon... from this time I get idea that it is just crap bullshit and I have told it many times in Finland. 

1) Around 2009-2010 I have noted that Owon have developed and I take it to some example names what is good to follow as I tal.. What if some day we can see higher class dgital oscilloscopes may be also Chinese...

2) in some last years Owon have developed from crap to notable manufacturer.
(why I say this. I say becouse whole time I have followed it after time to time.)

But there is (random?) truth... I make finally decision to buy lot of SDS7102's (not for me but for sale and after I have here locally also fast keeped it in my hand and looked  it irl)  just around same time as you start this "famous"  Owon "Rewiev" with lot of opinions but nearly total lack of any kind of real lab tests.

If there do not come more lies I can also keep silence.
Guns are yours.

Do you overall mainly think that things what occurs around  same time have causality?

[andersm]

Attached image is authentic OWON -> USB -> PC Transferred bitmap image. Is it 800x600x8?

Quick image analysis suggests the Owon is using 9-bit RGB and the Rigol 16-bit RGB. Both seem to be using less than 256 colours on screen, so it's possible they're using indexed colour modes.

[aghp]

Attached image is authentic OWON -> USB -> PC Transferred bitmap image. Is it 800x600x8?

Quick image analysis suggests the Owon is using 9-bit RGB and the Rigol 16-bit RGB. Both seem to be using less than 256 colours on screen, so it's possible they're using indexed colour modes.

Perhaps. But if think how much data is transferred, with Owon it is 1,4Mbyte and it takes time becouse also Owon USB transfer to computer or USB memory is not very fast. Is it problem or not it dpends user needs. 
Note, I do not think any kind of competite between Owon and Rigol.  I do not want pick-up Owon to this thread. Only correct wrong claim.

In my mind  Rigol DS2xxx  is one good candidate to "highly recommended" class in 1-2kEuro group.

[digsys]

BOTH these DSOs are about the best selection for their respective NICHE markets !!
For the PRICE, the OWON pretty much cleans up every competitor in that group, with features even equalling some high end.
For the PRICE, the Rigol does well against much "higher" name brands, and has excellent tech capabilities.
BOTH have their issues though, BOTH could be just a bit better. That's the way it is and in ALL tech equipment.
You should see the forum wars in the Digital camera world, which I have been very active in from day 1. This is nothing !!
And now, possibly, Instek are joining the party with their new line-up. We'll have a new player to beat up :-)
Lets Play nice in the sandpit ...

[marmad]

Can not correct your mistakes or lies? Then you come angry. Grow up.

Sure, this from a guy who comes on this thread to correct a mistake by posting:

"You make mistakes quite often when you talk about Owon. Selectively forget the truth?
But I'm very lazy to correct all becouse - who cares."

Very adult behavior.

Do you overall mainly think that things what occurs around  same time have causality?

Well, no, I think in this particular circumstance they have causality because of the private messages you sent me after my review - but I guess that involves selective memory again.

20 August 2011 02:50 PM

I'm not sure why you believe posting something written AFTER my reviews were published (and after you PMed me for more information) proves your point? In case your memory (selective?) needs jogging, you PMed me 6 times between Aug 14th and Aug 19th asking for information about the scope - my review was first published on Aug.8th.

[martinv]

You know your life is good if you have time to argue about oscilloscopes:)

I'm still wondering if the lost data between each screen record using the Record/Playback feature is normal to this scope, all scopes, or a bug? 

I have a question about the Record/Play back functions.  I tried using the serial decode function and found about the maximum I could fit on 1 screen is as shown in the attached picture.

Now I can zoom much further out in the horizontal scale and capture a huge chuck of data then zoom back in to read/decode it. 
I figured this would be a great use for the record and playback,  but I discovered large gaps of lost data between each recorded frame/(screen).  I'm assuming this is normal?

So i'm back to the zoom way out, grab a screen with max data points, then zoom back in to read/decode.   
Instead of scrolling with the tiny horizontal knob, WHY can't this nice big jog wheel be used to scroll quickly forward and back instead of using the little horizontal knob.  Wouldn't this be a huge improvement? Perhaps this could included in a future update.   I feel like hooking up my cordless drill to the Horizontal knob sometimes:)   
I don't have much experience in capturing/decoding data, so please let me know your thoughts and preffered methods of doing this.   
What are some of the other uses for the record/playback feature?

[marmad]

I'm still wondering if the lost data between each screen record using the Record/Playback feature is normal to this scope, all scopes, or a bug? 

Martin, I'm not quite sure why you're re-posting this old message when I answered it here - unless you missed my previous response.

From your post, it doesn't sound as if you understand how the Record feature works - it captures a frame when triggered (up to the maximum wfrm/s of that timebase setting). Any data that is 'lost' is between triggers - exactly like when you run the DSO in 'Normal' trigger mode. If you specify a longer delay time between triggers, more data will be 'lost'.

[martinv]

Sorry,  I did miss your previous reply somehow, yet I recall reading the post before and after, but I also sometimes plug red into black and black into red by mistake.  Then again my job sometimes requires it to be done intentionally!
I do not understand exactly how the record function works, but will read your post and play around some more.  Thanks for the reply.

[marmad]

Sorry,  I did miss your previous reply somehow, yet I recall reading the post before and after, but I also sometimes plug red into black and black into red by mistake.  Then again my job sometimes requires it to be done intentionally!

No problem - the mad unspooling of threads here sometimes means you miss responses   And I'm sorry if I was somewhat short-tempered - it's been a tiring couple of days.

Looking back over your original post, I wonder if the Record function is really suited for your task. Part of the problem is the fact that Rigol calls it 'recording' (with what that implies from our other experiences with recording things) - while many other DSO makers call it 'segmented memory'.

This little chart I clipped from the GW-Instek manual gives a fairly clear picture as to what is happening - just insert the word 'frame' where it says 'segment':



The idea of segmented memory (Rigol's 'record') is not that you capture more continuous data - in fact, it's the opposite: that you save memory space by NOT capturing continuously - but only capturing triggered events when they happen - then waiting for the next event.

So for long continuous streams of data, it's not going to work well - you're better off using the entire 56MPts of memory in a single shot.

I hope that makes it a bit more clear 

[martinv]

...So for long continuous streams of data, it's not going to work well - you're better off using the entire 56MPts of memory in a single shot.

Thanks for that info.  It is much clearer now. I was missing the 'Delayed' ON in the horizontal menu which allows use of the 'Navigation Knob'.  This is great as my last scope force me to turn the little horizontal position knob 100s of turns to do the same thing.