Software & tips for Rigol DS2072 ( DS2000 / DS4000 / DS6000 UltraVision DSOs )

[Karel]

I use this software to control the scope, view live waveforms and download screenshots or memory waveform data.
No need to install 1GB of bloatware (visa, rigol). Works fine for me.

http://www.teuniz.net/DSRemote/

Latest version supports LAN & USB.

[Gandalf_Sr]

I sorta kinda figured that my MSO2072A 'upgraded' would work with this utility but when I try to connect, it tells me...
This Ultravision DSO is not supported in this version.  Contact....
Am I flogging a dead horse?

[gojimmypi]

Hello Mark,

Any progress with V3 and DS1000Z ? Lot of people waiting .... 

Thank you very much !

I'm working on it now (finally have a DS1000Z series to test with) and I'm making progress. I'll post here when there's a new version.

Any plans to open the source? I see it is .NET based, and would like to contribute if possible.

I'm a .Net developer as well! I would enjoy contributing to this project, too! That would be fantastic to see the source on github.

[gojimmypi]

I use this software to control the scope, view live waveforms and download screenshots or memory waveform data.
No need to install 1GB of bloatware (visa, rigol). Works fine for me.

http://www.teuniz.net/DSRemote/

Latest version supports LAN & USB.

Thanks for posting this link! I plan to order a DS1054Z soon, do you know if this software would work with this model? That's awesome it is open source, as well!

https://github.com/Teuniz/DSRemote

[Karel]

Thanks for posting this link! I plan to order a DS1054Z soon, do you know if this software would work with this model? That's awesome it is open source, as well!

https://github.com/Teuniz/DSRemote

Yes. Just make sure your scope is running the latest firmware.

[Juhizo]

Is there any progress on RUU for DS1054Z. Can capture wafeform without intensity gradient, and there isn't any adjustment knobs on UI.

[paulfromsf]

I am using the 2.03 release on a Rigol DS2102A. It is a fantastic utility and is doing 90% of what I need it to (Thank you Marmad for writing and posting to share). I am not sure if it is a bug or if I am missing a setting but when I try to save multiple frames (created by the "Record" function on the scope) in a csv format, frame #1 data is being replicated in the csv file for all subsequent frames despite the frame number incrementing (as well as the time stamp) in the file. I have gone through all of the different settings available on the 2.03 UI but nothing seems to work / address the issue. Does anyone know if this is a known issue, if there is a work around, or am I missing something simple? Any help would be greatly appreciated but at a minimum I wanted to post in case this is a bug so it can perhaps be addressed in any future releases.

[Teneyes]

I am not sure if it is a bug or if I am missing a setting but when I try to save multiple frames (created by the "Record" function on the scope) in a csv format, frame #1 data is being replicated in the csv file for all subsequent frames despite the frame number incrementing (as well as the time stamp) in the file.

Hello ,  I have a DS2000 non A, and I will test the .csv function to verify when I get back home, 5 days.

[marmad]

I am using the 2.03 release on a Rigol DS2102A. It is a fantastic utility and is doing 90% of what I need it to (Thank you Marmad for writing and posting to share). I am not sure if it is a bug or if I am missing a setting but when I try to save multiple frames (created by the "Record" function on the scope) in a csv format, frame #1 data is being replicated in the csv file for all subsequent frames despite the frame number incrementing (as well as the time stamp) in the file. I have gone through all of the different settings available on the 2.03 UI but nothing seems to work / address the issue. Does anyone know if this is a known issue, if there is a work around, or am I missing something simple? Any help would be greatly appreciated but at a minimum I wanted to post in case this is a bug so it can perhaps be addressed in any future releases.

Paul - Check your PMs. I fixed the CSV write bug and compiled a working 3.0 version for you. As I mentioned, it's been over a year since I worked on RUU, but I hope to get back working in earnest on it in another month or so, since there are many new features which I already wrote the code for but haven't had the time to enable in the public releases.

[ionutmarisca]

Looking for an updated version of 3.0 as this is an extremely helpful tool. All I want is the possibility to export to csv in this new version (need all the 4 channels)(there are no buttons available).

[marmad]

Looking for an updated version of 3.0 as this is an extremely helpful tool. All I want is the possibility to export to csv in this new version (need all the 4 channels)(there are no buttons available).

There is no 3.0 version yet that can capture all 4 channels on the DS4000 and export to CSV, although perhaps there will be in the not-too-distant future. But why can't you export the captured waveforms to CSV using the DSO itself?

[Mechatrommer]

All I want is the possibility to export to csv in this new version (need all the 4 channels)(there are no buttons available).

you may try VisaDSO. it can download 4 channels DS1000Z full memory and export to CSV. theoritically, it should work with DS2000 as well, but not physically tested. if you are interested, you may forward your report to the "MAKER".
https://www.eevblog.com/forum/projects/rigol-feat-higher-bitfloat-accuracy-general-purpose-deep-mem-fft-sw/msg900741/#msg900741
http://www.soasystem.com/download/visadso/

But why can't you export the captured waveforms to CSV using the DSO itself?

with DS1000Z and E at least, saving CSV using built in rigol function takes forever, esp full memory data. downloading raw byte data to PC through USB (visa) and then save to CSV in the PC only cost in minutes..

[Karel]

All I want is the possibility to export to csv ...

Is there a prticular reason it must be in csv format? csv format is a pain in the *** to deal with and the files are huge.

[marmad]

theoritically, it should work with DS2000 as well, but not physically tested.

DS2000/4000 need a different memory-reading routine; it's not automatically compatible.

if you are interested, you may forward your report to the "MAKER".

Is there some reason you're referring to yourself in the third person?

with DS1000Z and E at least, saving CSV using built in rigol function takes forever...

Uh...yeah, Shafri, I know about the speed difference - I've been writing software for the Ultravision DSOs for 3.5 years now. But I wanted to know his reason for requesting the external CSV-saving capability and whether it was frame-related or not.

And BTW, the DS1000Z firmware/MCU is MUCH slower than DS2000/4000 in most respects, although I never tested the file-writing speeds against my DS2000 when I had a DS1000Z.

[Trev4G]

There is no 3.0 version yet that can capture all 4 channels on the DS4000 and export to CSV, although perhaps there will be in the not-too-distant future.

I would be very interested in a version 3.0+ that runs on my MSO4014. I would be happy to test when this is needed.

Trevor

[Mechatrommer]

theoritically, it should work with DS2000 as well, but not physically tested.

DS2000/4000 need a different memory-reading routine; it's not automatically compatible.

i run through DS2000 programming guide. it seems DS1000Z is following (or seems to be compatible with) the DS2000 routine/API, except DS1000Z has some portions updated or explained in more detailed. i have a feeling rigol internal dev.team continue to repolish their API along with the lines of their product, except the boundary is unclear between sw api revision and product models/generations.

if you are interested, you may forward your report to the "MAKER".

Is there some reason you're referring to yourself in the third person?

who is making it is not important. and i've got negative replies about many aspects from "ee specialists". so separating between a personality who frequently involved in a ee forum discussion and a personality who enthusiastic about developing SW is a better idea for now. i dont want to hear... hey, Mechatrommer! you should do this you shouldnt do that etc, in this public ee forum. the only clear path to give advice on SW aspect is in the given link (the MAKER's email ) this is ee forum after all.

[Mechatrommer]

All I want is the possibility to export to csv ...

Is there a prticular reason it must be in csv format? csv format is a pain in the *** to deal with and the files are huge.

thats why saving to wfm in dso unit, is much more sensible action, still it takes longer if not forever to save wfm internally. but then keep working with either csv or wfm on both DSO or PC is less stellar compared to defining a file standard in binary format excelled in speed and space saving for the purpose. i've opened a thread to ask about industry standard, the replies are "quite" plausible, other than a complicated API toolkit HDF5 (iirc) format, there only a few "application specific" format (time to invent a DSO specific or 2-dimensional time series file format)

[marmad]

i run through DS2000 programming guide. it seems DS1000Z is following (or seems to be compatible with) the DS2000 routine/API, except DS1000Z has some portions updated or explained in more detailed. i have a feeling rigol internal dev.team continue to repolish their API along with the lines of their product, except the boundary is unclear between sw api revision and product models/generations.

Well, perhaps it's been changed since I had a DS1000Z and DS2000 sitting on my desk simultaneously, but the last time I checked there was no WAVEFORM:STATUS command on the DS1000Z (as there is on the DS2000/4000).

i dont want to hear... hey, Mechatrommer! you should do this you shouldnt do that etc, in this public ee forum. the only clear path to give advice on SW aspect is in the given link (the MAKER's email ) this is ee forum after all.

Good luck with that! 


EDIT: Just checked the DS1000Z programming guide (Dec. 2015 version): still no WAVEFORM:STATUS command. So, no, DS1000Z is not exactly following the DS2000/4000 routine/API - at least in terms of continuous reading. Block reading seems to be more or less compatible, but it's a less efficient method to use on the DS2000/4000.

[marmad]

thats why saving to wfm in dso unit, is much more sensible action, still it takes longer if not forever to save wfm internally.

Which is another reason why it it's so damn stupid that Rigol changed the WFM format in the Ultravision DSOs from the previous format in the "E" (and older) DSOs. And they still have not (as far as I know) published specs for the format - although I know that Drieg was trying to get the specs from them quite some time ago.

[Mechatrommer]

Well, perhaps it's been changed since I had a DS1000Z and DS2000 sitting on my desk simultaneously, but the last time I checked there was no WAVEFORM:STATUS command on the DS1000Z (as there is on the DS2000/4000).

you are right!. but the "theoritical" above means based on the assumption that the current DS2000 hardware or api model is not necessitating "WAVEFORM:STATUS" anymore, i mean less capable DS1000Z doesnt have to confirm its wav/data transfer status, you can read a fixed size of chunks continuously, asking the next chunk will either send the next chunk immediately or hold the caller until the next chunk is ready for the transfer. i'd be surprised if DS2000 is too slow at transferring say 1000 bytes sized of chunks continuously.

thats why saving to wfm in dso unit, is much more sensible action, still it takes longer if not forever to save wfm internally.

Which is another reason why it it's so damn stupid that Rigol changed the WFM format in the Ultravision DSOs from the previous format in the "E" (and older) DSOs. And they still have not (as far as I know) published specs for the format - although I know that Drieg was trying to get the specs from them quite some time ago.

lets put wfm format aside alone, even the simple text based csv format, the rigol sw developers cant get it right after so many years. i bought my DS1000Z with original FW and with different CSV format, and now upgraded to the latest FW only few months apart, has different CSV format i'm imagining rigol sw engineer is a 25 years old lad by now (18 when first assigned) who is so busy with other tasks that he cant get a proper course on file format standard. it always freaked me out when i think that the same lad is assigned to formalize the wfm formats across dso/fw generations. another possibility is that for each dso/fw generations, there will be a sw.eng. undergraduate assigned for the task during his/her practical training, which is equally freaking situation. file format standard in rigol is next to a total failure.

ps: i've made visadso to read the latest ds1000z wfm format. but its a retarded hack.

[marmad]

you are right!. but the "theoritical" above means based on the assumption that the current DS2000 hardware or api model is not necessitating "WAVEFORM:STATUS" anymore

Nope, you still need it for continuous reading. But as I mentioned in my EDIT above, you can use block reading for compatibility with DS1000Z.

i mean less capable DS1000Z doesnt have to confirm its wav/data transfer status, you can read a fixed size of chunks continuously, asking the next chunk will either send the next chunk immediately or hold the caller until the next chunk is ready for the transfer.

Sure, but if I remember correctly, transferring a huge waveform from the DS1000Z essentially "locks" up the DSO for the length of the transfer, right? Or have they fixed that? On the DS2000, transferring a maximum-memory-sized waveform does not inhibit the user from, for example, zooming and scrolling through the waveform on the DSO during the transfer - it doesn't affect the responsiveness of the DSO in any way (although, of course, you can't RUN the DSO and overwrite memory during the transfer).

[Mechatrommer]

Sure, but if I remember correctly, transferring a huge waveform from the DS1000Z essentially "locks" up the DSO for the length of the transfer, right?

i've not tested the respond of it while downloading data, but (see below) the dso returned none (zero length data) at least on my unit if requesting large data. requesting larger than 1Mpts data is doomed to this kind of zero byte returned failure. so my method is read many smaller chunks, somewhere 100Kpts per call (rigol advice in programming guide is using 120Kpts) is safer bet from testing, if latency (or incompatibility) is an issue, we may further reduce the chunk size, its slower but it will put less burden to the DSO FW from transferring out large block of data at once, hence "theoritically" it should be more compatible. this is the way i did in VisaDSO. requesting data with many calls also enable us to device our own callback or update function so user wont wait a flat 65 seconds downloading 24Mpts data while screen showing nothing, or cancelling the download process before its completed.

edit: i just tested it, with multiple block read, the ds1000z isnt locked, we still can operate the dso knobs. i guess the dso will pool and process the gui between block read. but as said, request large block of data at once is a failure, so this way is a no go. and looking back at the ds2000 programming example, ":wav:status?", ":wav:data?", "viRead" sequence just look like another variant of "multiple block read", not "read at once" method. and the ds2000 support for ":wav:start" and ":wav:stop" (the MBR method i used in DS1000Z) makes me believe that, ds1000z method of MBR which used these commands is also applicaple to ds2000. no?

[marmad]

and the ds2000 support for ":wav:start" and ":wav:stop" (the MBR method i used in DS1000Z) makes me believe that, ds1000z method of MBR which used these commands is also applicaple to ds2000. no?

Yes, I think that should work fine - I'll give your app a test tomorrow and let you know how it works on the DS2000.

How have you been able to do with real-time reading of the display waveform? I was never able to get above single-digit wfms per second while testing on the DS1000Z (while I can get 40-50 on the DS2000).

[ionutmarisca]

Looking for an updated version of 3.0 as this is an extremely helpful tool. All I want is the possibility to export to csv in this new version (need all the 4 channels)(there are no buttons available).

There is no 3.0 version yet that can capture all 4 channels on the DS4000 and export to CSV, although perhaps there will be in the not-too-distant future. But why can't you export the captured waveforms to CSV using the DSO itself?

Thanks for your response. To be honest, I'm trying to help someone who needs to export to a CSV file all the 4 channels (don't know the actual reason). From what I understand, he can only export one channel at a time or something like this and he needs all the 4 channels. He gave me a .wfm file but I found no viewer, parser, converter that works with this format. I found this thread after searching for other methods. Is there a possibility to export all the 4 channels to a CSV file without using any software?

[tpailevanian]

Can someone verify that the ultravision utility works on the DS2072A-S model?