Thank you very much for the time spent testing, and please forgive my bad English. I didn't wanted to push for more testing this night, nor to be rude, sorry if I did any of that.Have a nice day tomorrow!

Thank you for running the benchmarking tests. The results are very interesting and very surprising too.

I have prepared another test. This one is doing as suggested in the manual and tries to get it all at once. It sends ":WAV:RES\n:WAV:BEG", then it keeps calling ":WAV:DATA?" until 24000000 bytes are received. It prints the first byte of every chunk received. This is to check that it gets correct data. If the scope has captured a ramp, these numbers will increase through the read.

I had to split it into two separate executables. The "ds4014" executable is for DS2000A and DS4000.

The "ds1054z" executable is only for DS1000Z - it does the same, but skips the ":WAV:RES\n:WAV:BEG" commands. I suspect this approach may work for DS1054Z.

As far as knowing how to transfer data off of the Rigol DS2000 series scopes, marmad is probably the best reference. I would strongly recommend you look into some of his posts for more insight. I good thread discussing some of the issues, and fairly recently was:

Something else to keep in mind, the DS2000A series has up to 56Mpts (megapoints) memory, not megabytes. And you definitely need to do the transfer differently than on the DS1000Z series for optimal results. Sorry I can't give you more than that, but its not something I've played much with.

...but for 1 000 000 points instead of 250 000. Depending on how much free memory the scope might have at that moment, sometimes it can serve up to 1 700 000 points at once. If the response starts with a number after #9000 that is not equal with the expected length, then the request was too big. 1 mil points is usually safe for a single trace and no other scope functions activated.

The 1 mil points is a trick I discovered when I was developing my open source tool, it is not guaranteed to always work. I didn't looked in the programming manuals for the DS2000/4000 yet, so I don't know if they have too a maximum number of points requested at once.

DS1000 definitely can't work with 24 mil points at once, as the v8 benchmark is trying to request:

Let me remove this "Bank of 0 bytes received ..." message. It creates too much clutter. It'll now print this message only when receives something. Still, if it uses 125K Bytes blocks, it'll be about 200 lines of output

Thank you very much for the time spent testing, and please forgive my bad English. I didn't wanted to push for more testing this night, nor to be rude, sorry if I did any of that.Have a nice day tomorrow!

No, your English is perfect! My sentence was too easy to misunderstand as English isn't my native language either. I actually meant that I would actually spend more time to help.

Version 9ConnectedBlock of 406682 bytes starting with 179 received at 0.328 sec.Block of 1984 bytes starting with 83 received at 0.858 sec.Block of 456320 bytes starting with 82 received at 1.092 sec.Block of 3968 bytes starting with 82 received at 1.701 sec.Block of 29760 bytes starting with 83 received at 1.716 sec.Block of 23808 bytes starting with 82 received at 1.779 sec.Block of 21824 bytes starting with 82 received at 1.825 sec.Block of 25792 bytes starting with 82 received at 1.872 sec.Block of 460288 bytes starting with 82 received at 2.137 sec.Block of 450368 bytes starting with 82 received at 2.964 sec.Block of 1984 bytes starting with 82 received at 3.557 sec.Block of 452352 bytes starting with 82 received at 3.791 sec.Block of 454336 bytes starting with 178 received at 4.618 sec.Block of 462272 bytes starting with 178 received at 5.445 sec.Block of 3968 bytes starting with 179 received at 6.053 sec.Block of 31744 bytes starting with 179 received at 6.084 sec.Block of 456320 bytes starting with 179 received at 6.365 sec.Block of 1984 bytes starting with 178 received at 6.958 sec.Block of 466240 bytes starting with 178 received at 7.207 sec.Block of 430528 bytes starting with 88 received at 8.034 sec.Block of 31744 bytes starting with 82 received at 8.611 sec.Block of 462272 bytes starting with 82 received at 8.892 sec.Block of 1984 bytes starting with 82 received at 9.501 sec.Block of 464256 bytes starting with 83 received at 9.750 sec.Block of 438464 bytes starting with 82 received at 10.577 sec.Block of 3968 bytes starting with 83 received at 11.154 sec.Block of 31744 bytes starting with 82 received at 11.185 sec.Block of 460288 bytes starting with 82 received at 11.466 sec.Block of 448384 bytes starting with 179 received at 12.293 sec.Block of 460288 bytes starting with 180 received at 13.104 sec.Block of 438464 bytes starting with 178 received at 13.947 sec.Block of 1984 bytes starting with 179 received at 14.508 sec.Block of 470208 bytes starting with 179 received at 14.758 sec.Block of 5952 bytes starting with 83 received at 15.382 sec.Block of 29760 bytes starting with 83 received at 15.413 sec.Block of 21824 bytes starting with 82 received at 15.460 sec.Block of 21824 bytes starting with 82 received at 15.507 sec.Block of 25792 bytes starting with 83 received at 15.553 sec.Block of 442432 bytes starting with 83 received at 15.819 sec.Block of 1984 bytes starting with 83 received at 16.396 sec.Block of 458304 bytes starting with 82 received at 16.630 sec.Block of 436480 bytes starting with 82 received at 17.457 sec.Block of 1984 bytes starting with 82 received at 18.034 sec.Block of 454336 bytes starting with 83 received at 18.268 sec.Block of 430528 bytes starting with 179 received at 19.079 sec.Block of 3968 bytes starting with 179 received at 19.656 sec.Block of 31744 bytes starting with 179 received at 19.672 sec.Block of 470208 bytes starting with 178 received at 19.953 sec.Block of 3968 bytes starting with 178 received at 20.577 sec.Block of 33728 bytes starting with 179 received at 20.608 sec.Block of 468224 bytes starting with 178 received at 20.889 sec.Block of 1984 bytes starting with 178 received at 21.497 sec.Block of 468224 bytes starting with 178 received at 21.747 sec.Block of 7936 bytes starting with 179 received at 22.371 sec.Block of 470208 bytes starting with 179 received at 22.620 sec.Block of 3968 bytes starting with 82 received at 23.229 sec.Block of 29760 bytes starting with 83 received at 23.260 sec.Block of 21824 bytes starting with 82 received at 23.307 sec.Block of 21824 bytes starting with 83 received at 23.354 sec.Block of 25792 bytes starting with 83 received at 23.400 sec.Block of 478144 bytes starting with 83 received at 23.681 sec.Block of 452352 bytes starting with 82 received at 24.539 sec.Block of 450368 bytes starting with 82 received at 25.366 sec.Block of 136896 bytes starting with 82 received at 26.021 sec.Block of 464256 bytes starting with 178 received at 26.442 sec.Block of 436480 bytes starting with 178 received at 27.269 sec.Block of 3968 bytes starting with 179 received at 27.846 sec.Block of 29760 bytes starting with 178 received at 27.878 sec.Block of 23808 bytes starting with 179 received at 27.924 sec.Block of 466240 bytes starting with 178 received at 28.205 sec.Block of 1984 bytes starting with 179 received at 28.814 sec.Block of 470208 bytes starting with 179 received at 29.063 sec.Block of 31744 bytes starting with 179 received at 29.687 sec.Block of 476160 bytes starting with 169 received at 29.984 sec.Block of 3968 bytes starting with 83 received at 30.608 sec.Block of 31744 bytes starting with 82 received at 30.639 sec.Block of 462272 bytes starting with 82 received at 30.920 sec.Block of 1984 bytes starting with 82 received at 31.512 sec.Block of 466240 bytes starting with 82 received at 31.762 sec.Block of 456320 bytes starting with 83 received at 32.604 sec.Block of 3968 bytes starting with 82 received at 33.197 sec.Block of 31744 bytes starting with 82 received at 33.228 sec.Block of 452352 bytes starting with 82 received at 33.509 sec.Block of 450368 bytes starting with 178 received at 34.320 sec.Block of 31744 bytes starting with 179 received at 34.929 sec.Block of 460288 bytes starting with 178 received at 35.210 sec.Block of 450368 bytes starting with 179 received at 36.052 sec.Block of 1152704 bytes starting with 178 received at 37.238 sec.Block of 452352 bytes starting with 83 received at 38.954 sec.Block of 450368 bytes starting with 83 received at 39.780 sec.Block of 1984 bytes starting with 82 received at 40.373 sec.Block of 472192 bytes starting with 82 received at 40.623 sec.Block of 460288 bytes starting with 178 received at 41.481 sec.Block of 446400 bytes starting with 178 received at 42.308 sec.Block of 444416 bytes starting with 178 received at 43.119 sec.Block of 3968 bytes starting with 178 received at 43.696 sec.Block of 31744 bytes starting with 178 received at 43.727 sec.Block of 25792 bytes starting with 179 received at 43.790 sec.Block of 80934 bytes starting with 179 received at 44.024 sec.Received 24001200 bytes in 44.320 sec.

I want to thank all the participants for the tests. Here's the summary of what we have found:

Connections

The benchmark program connected to port 5555 of the scope over LAN. We used two distinct methods to read data.

Block method

This is explained in programming manual for DS1000Z series.

:WAV:STAR <block begin>:WAV:STOP <block end>:WAV:DATA?

for example

:WAV:STAR 1:WAV:STOP 250000:WAV:DATA?

Once the data is received, the next set of commands can be sent to the scope. In most cases, it is possible to send the next set of commands earlier - as soon as the scope starts sending the data back. But sometimes such early response doesn't work. Since the early response only gains milliseconds per MByte, there's no reason to use it.

The block method works for every scope and is implemented in version 4 of the benchmark software (attached to post #27). Instructions are in post #41.

Even though the documentation limits the block size to 250000, it is possible to use block size of 1000000, which considerably speeds the transfer up, but we had a failure with DS2072A (see post #51). This method is implemented in version 7 of the benchmark software (attached to post #49).

Stream method

This is explained in programming manual for DS4000 series, except we do not do status queries.

First, these two commands are sent

:WAV:RES:WAV:BEG

The data command follows.

:WAV:DATA?

Each command gets a response which contains some of the data (possibly zero). If we receive zero, we wait 50ms, then issue the data request command again. If it's not zero, we retrieve the data, then send the data command.

This is continuing until all the data is retrieved.

At the end, we do

:WAV:END

This method works on DS4000 series (as expected) and even provides slight improvement over the block method.

On DS2000A, this method is very inefficient because the scope doesn't organize the continuous data stream but rather sends data in blocks of 126976 (0x1f000) bytes. Because block size is small, this is much slower than the block method.

This doesn't work on DS1000Z series at all.

This is implemented in version 9 of the benchmark software (attached to post #61).

I can confirm the datarate for the DS1000z series using USB connection and using a slightly modified version of DSRemote.When changing the value of macro SAV_MEM_BSZ in line 29 in save_data.cpp from 250000 to 1000000,the downloadspeed increases from 0.73Mbytes/sec to 1.7Mbytes/sec.

Somebody else already did the same test using DSRemote some time ago. The question is, do you want to increase the riskof data corruption while, even when following exactly the programming guide, the firmware has proven to be unreliable?Everybody has to decide that for himself. Personally, I prefer to stick with the limit written in the programming guide,i.e. the slow download speed, in order to stay on the "safe" side...(as far as that is possible with Rigol stuff...)

Logged

The difference between theory and practice is less in theory thanthe difference between theory and practice in practice.Expensive tools cannot compensate for lack of experience.