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

[marmad]

More Fun with RUU
and DS2072 with DG4062 ,   I'm in on RdgUU 

A sawtooth Modulated Sawtooth

Nice one Teneyes - a beautiful 3D plot! 

[dougg]

RUU 1.51 did work on W7 native but not particularly well, my DS2202 became unresponsive and remained that way for a while, even after the USB cable was removed.

Ha, ha...  so my software was able to influence your Rigol - even when unplugged? Wow, it's even more powerful than I imagined.   It sounds like you're having VISA/connection problems that are unrelated to my software. Have you tested other SCPI-based software on it?

Revisiting this part of the thread, I think that the reason for the unresponsive nature of my DS2202 was setting Display|Menu_display to 1 second. Try it and like me you may find that many aspects of the user interface, especially the menu buttons become almost unusable.

If you wanted to convince a colleague or a superior that a DS2000 was not worth taking/borrowing from you, then that may be a useful setting. Otherwise you have been warned.

[marmad]

Revisiting this part of the thread, I think that the reason for the unresponsive nature of my DS2202 was setting Display|Menu_display to 1 second. Try it and like me you may find that many aspects of the user interface, especially the menu buttons become almost unusable.

Yes, having the Display Menu set to 1 second is very bad. In fact, as mentioned in other posts, the Rigol firmware routine for hiding the menus is terribly written - hanging up the DSO (and communications with the DSO) while it tries to 'smoothly' scroll the menus away. And to what end? Why do the menus have to 'scroll' away? Why not just have them retract back immediately? I just want hem gone - I don't need animation as they go away. It's one of the worst routines in the firmware - and I don't even bother using it.

But as far as RUU goes: one of the two main reasons I started writing these utilities for the DS2000 series was because I wanted to have a method for dropping markers while in Delayed Sweep (Zoom) mode - and jumping between them. But once I had started writing the software, I discovered the 01.00.05 firmware has a bad bug which prevents full sample memory reading from the DSO - and so to emulate Zoom mode (to display the full waveform in RUU) - in earlier versions of RUU - I was grabbing a bitmap from the DSO and cropping out the picture of the full waveform. But getting a correct bitmap meant that I had to try to make sure that no menus were visible - and since there is no SCPI command to retract the menus - when entering Zoom mode in RUU, I was telling the Rigol to set the Display Menu to 1 second - then waiting a second - then grabbing the bitmap. When you exited Zoom mode, I would set the Display Menu back to whatever the previous setting had been. But of course, this didn't work very well because people would exit differently, etc, etc. Anyway, this is a moot point now since I no longer use a bitmap to display the full waveform and so RUU no longer touches the Display Menu settings.

[Teneyes]

Revisiting this part of the thread, I think that the reason for the unresponsive nature of my DS2202 was setting Display|Menu_display to 1 second. Try it and like me you may find that many aspects of the user interface, especially the menu buttons become almost unusable.

Just checking that with RUU 2.03 this is Not a problem.  I had to time the RUU save during the 1 sec menu display

[dougg]

Tried running RUU 2.03 on W8 as a VM on VBox 4.2.10 . Now that should not be a problem since recent versions don't try to connect to the 'scope until the Connect button is pressed. It could replay canned data (in the data folder) as expected.

The attached screenshot is low resolution but does show pixels being shaved off the top of some of the words in the smaller buttons. And as task manager shows, RUU was consuming almost 100% of the CPU, doing nothing. My laptop's fan and Linux (the host OS) confirmed that W8 was using 100% of the CPU. When I closed RUU CPU usage dropped below 10%.

[marmad]

And as task manager shows, RUU was consuming almost 100% of the CPU, doing nothing. My laptop's fan and Linux (the host OS) confirmed that W8 was using 100% of the CPU. When I closed RUU CPU usage dropped below 10%.

Thanks for the report. Unfortunately, as mentioned before, I don't have any machines around with W8 installed - and the behavior of >90% CPU usage is not happening under W7. When I get a chance to work on the software again, I'll see if I can figure out what might be causing the problem.

[marmad]

Could a DS4000 owner please post a screensave (preferably .BMP so that it's uncompressed) with channels 3 and 4 turned on, so that I can extract the color values? I can't seem to locate any quickly online - and I hope to start working on the utilities again soon, and I need the original color values to integrate the other 2 channels of the DS4000 into the software (even though you can change it in RUU later if desired). Thanks!

[dpenev]

Hi Marmad,

I have used RUU software to export the scope screen on a remote PC.
It probably not the main usage of the software but let me share my opinion.
My scope DS2102, firmware 00.00.01.00.05, Win 7 64 bit.

I have a Linux embedded hardware which due to some physical requirement is not sitting on my desktop.
I am connecting to the device remotely using ssh and your RUU software appears suitable to export the scope screen on my desktop PC.
I have used TCP/IP interface. I had to enter the VISA instrument name manually. (with USB the scope got detected right away)

I know that the main purpose of RUU is not just to export the scope screen but I am sure lot of people will use it for this as well.

In this respect I have two basic comments:
1. Can we somehow store the TCP visa resources name in the RUU settings so no need to enter each time.
    I think there is good reasoning for this as, the scope is getting its IP using DHCP so its VISA name is suppose to stay the same.
2. Is it possible we have the trace reference marks (those small '1' for ch 1 and '2' for ch 2 marks) on the RUU screen?
3 Of course having the main scope Y, T controls available in RUU would be huge advantage for me but I think I am getting to far

Thank you for the great work, it is really useful!
Dimitar   

[marmad]

In this respect I have two basic comments:
1. Can we somehow store the TCP visa resources name in the RUU settings so no need to enter each time.
    I think there is good reasoning for this as, the scope is getting its IP using DHCP so its VISA name is suppose to stay the same.
2. Is it possible we have the trace reference marks (those small '1' for ch 1 and '2' for ch 2 marks) on the RUU screen?
3 Of course having the main scope Y, T controls available in RUU would be huge advantage for me but I think I am getting to far

Hi Dimitar - thanks for the kind words and support. In response to your questions:
1) Yes, the next version of RUU will have savable settings - which will include a possible IP address for the DSO.
2) Yes, I'm also hoping to have ALL of the settings normally visible on the DSO screen (voltage and timebase settings, trigger level, etc) updated real-time on RUU's screen in the next version.
3) This will likely be something I will add in the future, but I doubt it will be the next version. There are a few other features I'd like to get to first.

[The Chump]

Screenshot of all 4 channels of DS4000 as requested!

Cheers

Alex

[marmad]

Screenshot of all 4 channels of DS4000 as requested!

Thanks, Alex! Just what I wanted. 

[dpenev]

Hello,

I did a quick check of the SPI decoding function of my DS2102.
It is probably useful but it seems to be not as convenience as a regular logic analyzer.
In addition I have observed misalignment between the code and the traces as you can
see on the attached picture. Next time I have tried the code was properly aligned.
It is strange that if you stop the triggering and if you move along the time domain
the decoded SPI code is moving/refreshing very slowly on screen. It behaves as if the code
is calculated real time during the movement but it does not make sense as we have the
signal data in memory and normal it should be decoded only once.
What do you guys think about the decoding of those scope? 

What is also strange is that I set the scope sampling to 100MSa/s, 28M pts, two channels enabled.
In this case the scope is triggering only about 140ms which means14M pts.
I would expect 28M pts. as written on the screen??

I've tried screen capturing into a image on the USB flash storage.
The scope didn't like my Kingston 32GB stick
(detected but said no room on the device (I have more then 17GB free on this stick))
With other smaller flash stick I have managed to write the picture.

Regards
Dimitar         

[marmad]

Hi Dimitar,

You will get many more members looking at your post and replying if you remove it from here (which is normally used for software for the Rigol) and post it in the review thread here.

[marmad]

It behaves as if the code is calculated real time during the movement but it does not make sense as we have the
signal data in memory and normal it should be decoded only once.

All measurements are made on the displayed data, not the sample data - so it makes sense that the decode is also performed on the displayed data.

What is also strange is that I set the scope sampling to 100MSa/s, 28M pts, two channels enabled.
In this case the scope is triggering only about 140ms which means14M pts.
I would expect 28M pts. as written on the screen??

I set the DSO to 2 channels and 28Mpts then set the timebase to 20ms - which makes the sample rate 100MSa/s. I set Display to Dots, then stop the DSO. When I zoom in to 20ns, I see that the dots (samples) are spaced 10ns apart: 1/10ns = 100MHz. I zoom out and the data fills 280ms: 10ns * 28Mpts = 280ms.

I've tried screen capturing into a image on the USB flash storage.
The scope didn't like my Kingston 32GB stick
(detected but said no room on the device (I have more then 17GB free on this stick))

Probably cluster size - most DSOs want 4kB clusters.

[AndyC_772]

I did a quick check of the SPI decoding function of my DS2102.
It is probably useful but it seems to be not as convenience as a regular logic analyzer.
In addition I have observed misalignment between the code and the traces as you can
see on the attached picture. Next time I have tried the code was properly aligned.

I've reported this bug in the DS4000 series. It's really bad if you capture a trace in normal trigger mode, then change the horizontal time base while the scope is still waiting for a trigger, then stop acquisition. The serial decode can be thrown right off the edge of the screen, or it can disappear entirely.

Does your scope correctly save and recall the polarity of the SPI signals and the MSB/LSB setting over a power cycle? That's broken too in the 4000 series, the UI gets inconsistent with the actual decoder.

What do you guys think about the decoding of those scope?

It'll be nice when it works, but right now it has stupid bugs that should never have escaped the developer's desk, much less any kind of beta testing programme. It's quite shameful for an extra cost option - and such an expensive one - not to mention surprising on a scope which otherwise seems to work so well.

I've tried screen capturing into a image on the USB flash storage.
The scope didn't like my Kingston 32GB stick
(detected but said no room on the device (I have more then 17GB free on this stick))
With other smaller flash stick I have managed to write the picture.

Rigol's USB driver is as fussy as they come. I've been recommended Integral brand sticks, preferably <4GB.

[dpenev]

Hi Marmad,

Thak you for the tip about the right thread

What is also strange is that I set the scope sampling to 100MSa/s, 28M pts, two channels enabled.
In this case the scope is triggering only about 140ms which means14M pts.
I would expect 28M pts. as written on the screen??

Ooops. On my settings I forgot to account the pre-trigering data apparently
I had 50% pretrigered data. So data length acquired is OK

All measurements are made on the displayed data, not the sample data - so it makes sense that the decode is also performed on the displayed data.

OK probably i still haven't get the whole philosophy of the scope but I have to admit Rigol can easily optimize the decoded code showing on screen. Sometimes it is misaligned, it moves jumps by jumps and now it is difficult to follow if you think consequently in time.
Even if they don't keep the whole decoded code in memory but only for the displayed data they could pre calculate one screen ahead and behind which could make the movement smooth.     

I had in the past bad experience with the uClinux on blackfin with big SD cards.
Do you guys know if uClinux is running this scope?
 
AndyC_772,

Does your scope correctly save and recall the polarity of the SPI signals and the MSB/LSB setting over a power cycle?

Yes I got firmware version ...005 and the polarity and msb/lsb seems to be correctly preserved over power cycle

Regards
Dimitar

[marmad]

OK probably i still haven't get the whole philosophy of the scope but I have to admit Rigol can easily optimize the decoded code showing on screen. Sometimes it is misaligned, it moves jumps by jumps and now it is difficult to follow if you think consequently in time.
Even if they don't keep the whole decoded code in memory but only for the displayed data they could pre calculate one screen ahead and behind which could make the movement smooth.     

Have you tried using the decoding table? The decoding table displays the decoded data and the corresponding line number and time in table format. It can be used to observe longer decoded data to solve the problem that some data could not be seen clearly on the screen.

[marmad]

What do you guys think about the decoding of those scope? 

I haven't used it all that much - just tested it here and there. To me, it seems like it's ok if in a pinch - but it doesn't replace a logic analyzer, which I would use for any serious decoding work. I do like using the advanced triggers and segmented memory to catch data bursts for deviation analysis.

[dpenev]

Hi Marmad

Quote from: dpenev on Yesterday at 08:39:45 PM

    OK probably i still haven't get the whole philosophy of the scope but I have to admit Rigol can easily optimize the decoded code showing on screen. Sometimes it is misaligned, it moves jumps by jumps and now it is difficult to follow if you think consequently in time.
    Even if they don't keep the whole decoded code in memory but only for the displayed data they could pre calculate one screen ahead and behind which could make the movement smooth.     


Have you tried using the decoding table? The decoding table displays the decoded data and the corresponding line number and time in table format. It can be used to observe longer decoded data to solve the problem that some data could not be seen clearly on the screen.

Yes I have seen the decoding table but I seems to trust the decoding more seeing the actual traces at the same time
Lets hope that the small glitches around the serial decoding will get improved with the next firmware revision

Regards
Dimitar

[Teneyes]

Nice acknowledgement to Marmad by Dave on
https://www.eevblog.com/forum/blog/eevblog-451-rigol-ds1052e-vs-ds2072-oscilloscope/msg213908/#msg213908

[EV]

@Marmad

I tried to save Display in Bitmap mode, when "Cursor Track" was on. Scope was in stop mode while saving. I got errors as in the pictures and picture was not saved. When using "Cursor Manual", picture was saved correctly.

[marmad]

I tried to save Display in Bitmap mode, when "Cursor Track" was on. Scope was in stop mode while saving. I got errors as in the pictures and picture was not saved. When using "Cursor Manual", picture was saved correctly.

Thanks, EV - I'll look for the problem when I get a chance.

[EV]

Also saving with "Cursor Auto" works ok.

[EV]

I saved two pictures. Pic-1 is saved by RUU and Pic-2 is saved with scope. Pic-2 can not be saved by RUU because it has cursor window at the left upper corner. You can get the cursor window off choosing cursor mode off and then rotating multi purpose knob to get mode to track and pressing the knob.

[Teneyes]

@EV  ,  Hello  that pulse looks like your JW pulse generator, was that S/N 32 or 60,
The Pulse does show nice bandwith on your Rigol.
I still have to build my JW pulser.  my 1st SMD project.