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

[Chrisalat]

Me too only 1-2WFPS via USB.
CPU load is only 2 or 3 %, that does not seem to be the problem.
But the connect takes very long the traces have no intensity grading.
The scope stays responsive and adding more channels or the FFT do not further deteriorate the WFPS.
I don't really see where the bottleneck is here.

Maybe adding timestamps to the logfile could help understand which command takes the time?

[marmad]

Me too only 1-2WFPS via USB.
CPU load is only 2 or 3 %, that does not seem to be the problem.
But the connect takes very long the traces have no intensity grading.

The traces can't have intensity grading - the Rigol never exports that information. There is an intensity buffer and there is display and sample memory - and what you get from the DSO is display memory (or sample memory). RUU is no substitute for the amount of data present on the DSO screen - you can't process and move that amount of data fast enough to the PC (which is why there are no intensity-grading USB scopes). The RUU screen functions just as a simple information extension of the DSO screen (early versions didn't even have a real-time display).

The scope stays responsive and adding more channels or the FFT do not further deteriorate the WFPS.
I don't really see where the bottleneck is here.

The bottleneck appears to be the DS1000Z, which seems to be slow at sending data. I get 30WPS with a single channel on my DS2000.

Maybe adding timestamps to the logfile could help understand which command takes the time?

I'll see what I can do - but I suspect that the DSO is just slower on every command than the DS2000/4000 (same as the UI).

[marmad]

Ok, new interim version of RUU alpha for DS1000Z owners (RUU 3.00.a04)

There is now a checkbox to turn on and off writing the logfile - although I'm not sure this will make any difference (in WPS) on the DS1000Z with this version.

But more importantly, the logfile now has timestamps (in milliseconds) on the SCPI commands to see where there are speed bottlenecks.

So could a DS1000Z owner please post a new log file again with this timestamp data? I am rewriting the engine to tighten up the code, get rid of redundancies, and improve the speed - so all the gathered information will be helpful.

[Suffer1981de]

Logfile incoming ;-)

FFT is not functioning, RUU doesn't show the math functions. Tried FFT + RUU + Screenshot and RUU couldn't query the oscilloscope. Taking the screenshot took ages so i guess the oscilloscope is too slow for that combination.

Again. If you need something tested (functions whatever) give me a hint what to do ;-)

Btw. going to sleep now. Me tired, me look at clock and sees me up far to late (after midnight here in Germany).

[marmad]

FFT is not functioning, RUU doesn't show the math functions. Tried FFT + RUU + Screenshot and RUU couldn't query the oscilloscope. Taking the screenshot took ages so i guess the oscilloscope is too slow for that combination.

Thanks. There are many things that RUU can't get from the DSO, due to the limitations of Rigol's SCPI implementations. Math waveforms, FFT, etc, etc.

[marmad]

Well, for those wondering why the DS1000Z was getting such low WPS with RUU, it's now clear thanks to Suffer1981de's log file.

Here are the timings from three different groups of two channel display memory transfers on the DS2000 - which average about 8.5ms each. Note that the number of milliseconds between the WAV:DATA? command and the 1400 bytes (or 1200 on the DS1Z) is virtually all on the DSO side;  RUU just waits for the data to arrive from the Rigol:

00000011  :WAV:SOUR CHAN1
00000013  :WAV:DATA?
00000021  :1400         8ms
00000024  :WAV:SOUR CHAN2
00000026  :WAV:DATA?
00000035  :1400         9ms

00000051  :WAV:SOUR CHAN1
00000053  :WAV:DATA?
00000062  :1400         9ms
00000064  :WAV:SOUR CHAN2
00000066  :WAV:DATA?
00000075  :1400         9ms

00000091  :WAV:SOUR CHAN1
00000093  :WAV:DATA?
00000101  :1400         8ms
00000104  :WAV:SOUR CHAN2
00000106  :WAV:DATA?
00000114  :1400         8ms


Now compare that 8.5ms average with the timings from the DS1000Z - which averages (in these groups) to ~91ms: ~10x slower than the DS2000:

00000080  :WAV:SOUR CHAN1
00000081  :WAV:DATA?
00000197  :1200         116ms
00000201  :WAV:SOUR CHAN3
00000202  :WAV:DATA?
00000230  :1200         28ms

00000280  :WAV:SOUR CHAN1
00000280  :WAV:DATA?
00000398  :1200         118ms
00000402  :WAV:SOUR CHAN3
00000403  :WAV:DATA?
00000430  :1200         27ms

00000481  :WAV:SOUR CHAN1
00000481  :WAV:DATA?
00000631  :1200         150ms
00000634  :WAV:SOUR CHAN3
00000635  :WAV:DATA?
00000730  :1200         105ms


Unfortunately, this means that the maximum WPS retrievable from the DS1000Z could likely never be greater than ~10 - and that's assuming you didn't spend time retrieving any other information.

[marmad]

Anyway, I have enough info to continue to the next alpha phase, which will be the finishing of the 2D engine with the Delayed Sweep features included.

One cool new feature which I've already written and debugged is the ability to drag a mouse window over the area of the waveform in RUU which you want to zoom in on.

[echen1024]

I was just about to write about the long (~90mS) delay time, but see you know already. I have gotten it to work, and I think you might know this, but no measurements are displayed as of yet.

[Suffer1981de]

Thanks Marmad for your great work. I'm anxious to see the new features. Keep up the good work.

Greetings

[The Chump]

Hi y'all

Breifly tested with my DS4054 on both USB and TCP. Looks good so far, logs and screenshot attatched.
Windows XP SP3 all up-to-date on a Dell Latitude E5000.

Alex

[mrflibble]

Now compare that 8.5ms average with the timings from the DS1000Z - which averages (in these groups) to ~91ms: ~10x slower than the DS2000:

00000080  :WAV:SOUR CHAN1
00000081  :WAV:DATA?
00000197  :1200         116ms
00000201  :WAV:SOUR CHAN3
00000202  :WAV:DATA?
00000230  :1200         28ms

...


Unfortunately, this means that the maximum WPS retrievable from the DS1000Z could likely never be greater than ~10 - and that's assuming you didn't spend time retrieving any other information.

Is that 100+ ms the time elapsed before you start getting any result packets from the DS1000Z? Or is that time elapsed before you received the final packet? Not that it should really matter all that much for 1200 words. But yes, that does look to be ridiculously slow on the DS1000Z. Looks to be either intentional or a firmware booboo, since it's rather unlikely the underlying hardware is that slow in retrieving the data.

[marmad]

Is that 100+ ms the time elapsed before you start getting any result packets from the DS1000Z? Or is that time elapsed before you received the final packet? Not that it should really matter all that much for 1200 words. But yes, that does look to be ridiculously slow on the DS1000Z. Looks to be either intentional or a firmware booboo, since it's rather unlikely the underlying hardware is that slow in retrieving the data.

It's the time from right after issuing the :WAV:DATA? command until right after receiving the last packet of waveform data  - plus the few microseconds needed to extract the effective bytes from the TMC data description header.

[marmad]

Marmad, I know this is just a DS1000 & DS4000 test.
but something to watch for is the Pts for a DS2000 when in Auto Memorydepth mode.
The DS2000 was in Auto mode with 700pts , and RUU showed  280pts,

But, Teneyes, 280pts is actually the correct number of points at your settings: 2G * 10ns * 14 = 280. It can't be larger than that.

The Rigol doesn't actually show the correct sample size when < 700 - it just shows * before the number to indicate that it's less than that.  But RUU always shows the correct value    Play around with the memory settings and you'll see that it's true.

[marmad]

Slightly improved alpha version of RUU (RUU 3.00.a05)

1) Removed some redundancies to speed up waveform display when just a single channel is on. I now get ~40WPS with my DS2000 (single channel).

2) Added channel input impedance display for DS2000 / DS4000 (see image)

[marmad]

Breifly tested with my DS4054 on both USB and TCP. Looks good so far, logs and screenshot attatched.
Windows XP SP3 all up-to-date on a Dell Latitude E5000.

Alex

Thanks, Alex. I'm impressed with the speed of the DS4000 display memory transfers. Can you please tell me how many waveforms per second (WPS counter - top right) with just a single channel on? Maybe attach a log file for just a single channel? Thanks again!

[Wim13]

small bug, when starting RUU 05, the traces are off 1 block, see picture,
when switching between 1 and 1.5 and back to 1 is it oke.

The screen updates increases when going to 1 trace, to 4 updates per sec.

[marmad]

small bug, when starting RUU 05, the traces are off 1 block, see picture,
when switching between 1 and 1.5 and back to 1 is it oke.

The screen updates increases when going to 1 trace, to 4 updates per sec.

Thanks, Wim. Is this the first alpha version you saw this bug?

[Wim13]

it was in earlier beta also, but forgot to mention everytime...

[marmad]

it was in earlier beta also, but forgot to mention everytime...

Hmm.... odd that no one else has mentioned it. But I'll look for the problem.

[marmad]

small bug, when starting RUU 05, the traces are off 1 block, see picture,
when switching between 1 and 1.5 and back to 1 is it oke.

Found the problem and fixed it: RUU 3.00.a06

In fact, the software is just writing over the normal DS2000/4000 14div screen with 2 blank divs and shifting everything 1div left for the DS1000Z.

[Wim13]

indeed, it starts correct now....

[Wim13]

Connected to the DS2000, i got 8 screen updates per sec., see picture.

I lookd into my network sniffer, and checked the time between the ethernet frames,
it was on the DS2000 much faster exchange rate then on the 1000.

The ds1000 is slow in the tcp/ip. Also Visa uses such small packets in ethernet,
max packet size i saw was about 70 to 80 bytes per frame.

In my case on the DS1000 , 2 channels about 2 screens per sec, on the DS2000, 8 Scr/s

Happy, the DS1000 also has a command for transferring a complete screen, maybe that will be fast.

[marmad]

In my case on the DS1000 , 2 channels about 2 screens per sec, on the DS2000, 8 Scr/s

On my DS2000 (FW 02.01.00.03) w/RUU 3.00.a06 @ 2ns/div, I get (best case):

       1CH / 2CH
USB   43 / 24   WPS
TCP   22 / 11   WPS

[skrap]

I just tested RUU_3_a06 now on my DS1000z.

I can confirm that logging do affect the performance a lot.

Running 1 channel, 1Gsps, 6Mpts on the cal. waveform gives me:
Logging off: ~25 wps
Logging on: ~1-3 wps

I just did a quick check of the performance of the process in ProcessExplorer (sysinternals) and found that the number of I/O drop alot when logging is enabled. I took a screenshot that makes it more clear I hope.

This is awesome by the way!

[marmad]

I can confirm that logging do affect the performance a lot.

It can definitely affect the total WPS. I stuck the logging in (very simply and quickly) just to figure out any possible bottlenecks caused by particular SCPI commands on the DS1000Z. But that information has already been gathered, so it's not really necessary anymore.

Running 1 channel, 1Gsps, 6Mpts on the cal. waveform gives me:
Logging off: ~25 wps
Logging on: ~1-3 wps

Wow, that's a great figure! I assume you must be using USB. Can you please also post your figures for 2, 3, and 4 channels on (no logging required)? The best case figures will always be at the smallest time base (2 or 5ns/div) since that's when the DSO has the most blind time - and so has the most free time to respond to data requests.