Rigol USBTMC/VISA interface is really terrible

[jeremy]

Hi everyone,

Just a heads up to anyone thinking of purchase a rigol (I have a DG1022 and a DS1054Z, both have the same problems) to use it in some sort of automation context: the rigol implementation of the USBTMC class is not standard, to the point where the linux kernel has a communication mode specifically for rigol devices (and it still doesn't fully work). It regularly misinforms the host about how much data it has to send, and there is a non-deterministic dead-time after sending a command in which new commands are just ignored (this isn't documented anywhere). There is also no way to tell if your command has been ignored other than the scope does not respond.

There also seems to be a "bug" (it's not really a bug so much, it just simply doesn't work) in the RAW waveform readout in which it just sends you back random garbage. I'm pretty sure it's not my implementation (and I've tried it using the supported NI-VISA; same result), because if I set it to NORMAL it works just fine, but in NORMAL mode you only get a maximum of 1.2kpts of waveform. I've sent an email to rigol support about this, but I'm not sure what sort of response I'm going to get.

I'd honestly fix these problems myself if someone would just release an open source USB oscilloscope already (no screen, no buttons, just two BNCs and a USB connector please!)

[tautech]

Ask kwass to add it to her thread:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg584436/#msg584436

[miguelvp]

Or instead, try Teunis van Beelen's program with full source, that Karel posted in this thread:

https://www.eevblog.com/forum/testgear/free-ds6000ds1000z-software/

[jeremy]

Or instead, try Teunis van Beelen's program with full source, that Karel posted in this thread:

https://www.eevblog.com/forum/testgear/free-ds6000ds1000z-software/

Actually, if you read the source code for Teunis' application, it only uses the NORMAL mode (or at least, it doesn't change the mode). And it also relies on the linux kernel driver. But this is not withstanding the fact that the rigol just simply returns the wrong data in the RAW mode.

Ask kwass to add it to her thread:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg584436/#msg584436

Thanks, I will do that.

[miguelvp]

Yeah, in:
http://www.teuniz.net/DSRemote/

They note the kernel patch needed.

And on the thread Karel mentioned a bug in the firmware that was notified to Rigol, so the more reports the better.

I haven't tried to do RAW captures yet, just DATA (screenshots) using alex.forencich's vxi11 python based control:

https://www.eevblog.com/forum/testgear/python-based-instrument-control/msg676772/#msg676772

I had to change the MTU size to avoid the TCP/IP packets from being split making it too slow.

Also I have a DS2000 series so the programming is different than the DS1000z series.

[Karel]

Or instead, try Teunis van Beelen's program with full source, that Karel posted in this thread:

https://www.eevblog.com/forum/testgear/free-ds6000ds1000z-software/

Actually, if you read the source code for Teunis' application, it only uses the NORMAL mode (or at least, it doesn't change the mode). And it also relies on the linux kernel driver. But this is not withstanding the fact that the rigol just simply returns the wrong data in the RAW mode.

I think you are wrong. DSRemote (Teunis' application) uses the normal mode and the raw mode, depending on which functions of the program you are using. If you don't believe me, have another look at the sourcecode.

The so-called "Rigol quirk" in the Linux usbtmc driver is only for Rigol devices that uses the product id's 0x0588 and 0x04b0.
The DS1054Z uses product id 0x04ce, so I think you are wrong again. Again, if you don't believe me, have a look at the Linux kernel code.

[jeremy]

Hi Karel,

You're right, it does use the raw mode. So it seems this is a 1000z model problem.

The rigol quirk actually applies to all rigol devices. If you look in the kernel source, for a very long time the only supported device was the DG1000 function gen. Teunis sent in a patch only recently to enable the 6000 series.

Of course, I patched the kernel driver to include the 1000z before testing this, otherwise barely anything would work.

[Karel]

You're right, it does use the raw mode. So it seems this is a 1000z model problem.

No, the DS1054Z works fine via USBTMC. There is a bug that makes it difficult to download
deep memory waveform data in raw mode but there's a workaround for that.
Have a look at DSRemote.

The rigol quirk actually applies to all rigol devices. If you look in the kernel source, ...

... then you will see that the rigol quirk is used only for rigol devices that uses product id's  0x0588 and 0x04b0.
The DS1054Z uses id 0x04ce, so the rigol quirk is not used for the DS1054Z.

Of course, I patched the kernel driver to include the 1000z before testing this, otherwise barely anything would work.

Interesting. DSRemote works fine with the DS1054Z without the need to patch the kernel i.e. without the rigol quirk.
How do you explain this?

[pklaus]

Interesting. DSRemote works fine with the DS1054Z without the need to patch the kernel i.e. without the rigol quirk.
How do you explain this?

Good that it works fine for you. For me, it doesn't. My kernel message log shows the following errors when plugging in my DS1054Z:

Code: [Select]

[ 127.657767] usb 2-1.6: new high-speed USB device number 5 using ehci-pci
[ 127.741956] usb 2-1.6: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 80, changing to 10
[ 127.741965] usb 2-1.6: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[ 127.741969] usb 2-1.6: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
[ 3927.846240] usbcore: registered new interface driver usbtmc

The /dev/usbtmc0 device is there but it doesn't even react to *IDN?.
I'm running the Arch Linux kernel 4.1.4-1-ARCH with its stock usbtmc kernel module.

DSRemote works OK via LAN (if I set the screen update interval to 2000mS!) but currently not via USBTMC!

[Karel]

DSRemote works OK via LAN (if I set the screen update interval to 2000mS!) but currently not via USBTMC!

On your pc, and I'm sorry to read that. Here DSRemote works fine with USBTMC on OpenSuse 13.2.

Anyway, you could try to investigate what's going on on the usb bus by using wireshark:

https://wiki.wireshark.org/CaptureSetup/USB

Post the usb traffic file here, maybe somebody can shine a light on it.
Just complaining "it does not work!" is not going to solve your problem.
(Assuming you want to solve the problem...)

[Karel]

My kernel message log shows the following errors when plugging in my DS1054Z:

Code: [Select]

[ 127.657767] usb 2-1.6: new high-speed USB device number 5 using ehci-pci
[ 127.741956] usb 2-1.6: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 80, changing to 10
[ 127.741965] usb 2-1.6: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[ 127.741969] usb 2-1.6: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
[ 3927.846240] usbcore: registered new interface driver usbtmc

I remember seeing those messages as well at home when connecting the DS1054Z.
I'll check again tonight but I guess it has nothing todo with your problem.

[pklaus]

On your pc, and I'm sorry to read that. Here DSRemote works fine with USBTMC on OpenSuse 13.2.

Anyway, you could try to investigate what's going on on the usb bus by using wireshark:

Post the usb traffic file here, maybe somebody can shine a light on it.

Thanks Karel, that's a good suggestion. I attached the wireshark capture to this post. It seems as if the *IDN? write succeeds but the successive read operation is strange: It takes exactly five seconds for the packet with the answer to arrive (the timeout of the read operation used in DSRemote?) Then the package with the actual answer to *IDN? arrives but the URB status is: No such file or directory (-ENOENT) (-2).
Something seems to be wrong there.

I recompiled the kernel module with #define DEBUG 1, and loaded that module. The kernel output was more verbose then but I cannot really interpret were this is going wrong:

Code: [Select]

[ 116.536363] usbtmc 1-1.5:1.0: usbtmc_probe called
[ 116.539555] usbtmc 1-1.5:1.0: Trying to find if device Vendor 0x1AB1 Product 0x04CE has the RIGOL quirk
[ 116.543748] usbtmc 1-1.5:1.0: Found bulk in endpoint at 130
[ 116.546456] usbtmc 1-1.5:1.0: Found Bulk out endpoint at 3
[ 116.549079] usb 1-1.5: GET_CAPABILITIES returned 1
[ 116.551017] usb 1-1.5: Interface capabilities are 0
[ 116.553192] usb 1-1.5: Device capabilities are 0
[ 116.555265] usb 1-1.5: USB488 interface capabilities are 6
[ 116.557708] usb 1-1.5: USB488 device capabilities are f
[ 116.560376] usbtmc 1-1.5:1.0: Using minor number 0
[ 116.562422] usbcore: registered new interface driver usbtmc
[ 155.809476] usbtmc 1-1.5:1.0: usb_bulk_msg_in: remaining(2097152), count(2097152)
[ 160.817424] usbtmc 1-1.5:1.0: usb_bulk_msg: retval(4294967186), done(0), remaining(2097152), actual(64)
[ 160.821577] usbtmc 1-1.5:1.0: Unable to read data, error -110

The first lines come from loading the module. It detects the scope and creates /dev/usbtmc0 there.
The last three lines correspond to me trying to connect with DSRemote (see the packets from the wireshark capture)

[Karel]

Actually, it's the timeout (5 sec.) of the usbtmc kernel driver.

It looks like you are running an old firmware: 00.04.03.
Can you try to upgrade to 00.04.03.SP1 and see what happens?

Also, try to connect the scope with another, high quality, usb 2.0 cable, if possible to a port on the back of your pc.

The reason I ask is the following. Contrary to most other instruments which uses USB 2.0 FS (full speed, 12 Mb/s),
the DS1054Z uses USB 2.0 HS (highspeed) connection at 480 Mb/s.
There are a lot of cables that pretend to be USB 2.0 compatibel but can cause problems at HS.
Also, the connectors on the back of the pc are usually mounted on the motherboard.
The connectors on the front uses an extra cable plus connectors inside the enclosure of the pc.
It doesn't harm to exlcude these possible source of errors.

[pklaus]

It looks like you are running an old firmware: 00.04.03.
Can you try to upgrade to 00.04.03.SP1 and see what happens?

Wow! That really fixed it 100%!!! Works perfectly now! Thank you for the hint!

This is what helped: Upgrading from 00.04.03.00.01 (2015-05-05) to 00.04.03.01.05 (2015-06-16). That made USBTMC finally working with my Linux machine!

I didn't believe it would help because the 16 fixed issues from the changelog file don't even mention USB / USBTMC / etc.
But it works now.

Thanks again!

*update*:  and for the record: all this is with the unmodified usbtmc.c kernel module shipping with the current kernel version 4.1.

[Karel]

I'm glad to read you solved the problem 

[Hibou]

Just a note of caution, if you are thinking of upgrading to firmware 00.04.03.02.03:

I had been struggling to get USBTMC to work with my DS1000Z, then I upgraded to firmware 00.04.03.01.05 and all the problems went away   However, today I upgraded to 00.04.03.02.03 and the USBTMC is broken again   Simple commands still work but not fetching waveform data from memory. I am using Alex Forencich's Python USBTMC library.

[Karel]

Just a note of caution, if you are thinking of upgrading to firmware 00.04.03.02.03:

I had been struggling to get USBTMC to work with my DS1000Z, then I upgraded to firmware 00.04.03.01.05 and all the problems went away   However, today I upgraded to 00.04.03.02.03 and the USBTMC is broken again   Simple commands still work but not fetching waveform data from memory. I am using Alex Forencich's Python USBTMC library.

I guess there's something wrong with that python lib. Here it works fine with usbtmc and latest firmware.

[Hibou]

Thanks Karel. That is really helpful feedback. I will try debugging the Python USBTMC library, rather than waiting for another firmware update.

Incidentally, can you tell me what transfer speed you get with USBTMC for waveforms from the DS1000Z in RAW BYTE mode? With the Python library it was taking about 9 seconds to get 12M samples, which is only just over 10 Mb/s. I was wondering if it limited by the scope or possibly the Python USB implementation.

[Karel]

Thanks Karel. That is really helpful feedback. I will try debugging the Python USBTMC library, rather than waiting for another firmware update.

Incidentally, can you tell me what transfer speed you get with USBTMC for waveforms from the DS1000Z in RAW BYTE mode? With the Python library it was taking about 9 seconds to get 12M samples, which is only just over 10 Mb/s. I was wondering if it limited by the scope or possibly the Python USB implementation.

It takes 55 seconds to download 24Mpts via usbtmc.

[jrpresto]

It does take a very long time with both ascii and byte modes when using python.  I'm using VISA drivers with latest firmware on python 3.4.  Does anyone else have any better results with another method?  When pulling 4 channels of data for pulse analysis, this is going to get very slow. 

[Karel]

It does take a very long time ...

How long exactly?

[RoGeorge]

This post is just to easily follow the subject.

[_Wim_]

This post is just to easily follow the subject.

Is you press the "notify button" at the bottom of thread, you get the same result without posting (otherwise all subscribed users get an update about this not so interesting post...)

[Fungus]

This post is just to easily follow the subject.

What's to follow? The last post here was a looooong time ago.

But thanks for reviving it with a pointless post.

[tai]

I used to workaround the issue by only using it on Windows (with UltraSigma driver), but finally decided to move my setup to Linux. As DS1000-series is still popular today, this quick script (rigolcap.py) might help other people on Linux as well:

https://gist.github.com/tai/408053a0955bf1712a5809240aa5544f

I also submitted a fix to python-usbtmc to get DS1000 (and maybe DS2000) working.
If anyone can confirm this works with other Rigols, please submit your input.
https://github.com/python-ivi/python-usbtmc/pull/62