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:
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.
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.
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).
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.
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.
6 seconds over Ethernet, from clicking Save on the file picker dialog. BMP is about the same.
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
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 secDS2202, 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...
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.
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.
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.
"
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)"Quote(3)"
Attached image is authentic OWON -> USB -> PC Transferred bitmap image. Is it 800x600x8?
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.
Can not correct your mistakes or lies? Then you come angry. Grow up.
Do you overall mainly think that things what occurs around same time have causality?
20 August 2011 02:50 PM
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?
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?
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!
...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.