Rigol USBTMC/VISA interface is really terrible - Page 1
Forum section: electronics / testgear

author: jeremy
author_rank: Super Contributor
timestamp: July 28, 2015, 03:38:32 am
content: 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!)

author: tautech
author_rank: Super Contributor
timestamp: July 28, 2015, 03:46:52 am
content: Askkwassto add it to her thread:https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg584436/#msg584436

author: miguelvp
author_rank: Super Contributor
timestamp: July 28, 2015, 04:26:49 am
content: 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/

author: jeremy
author_rank: Super Contributor
timestamp: July 28, 2015, 05:40:56 am
content: Quote from: miguelvp on July 28, 2015, 04:26:49 amActually, 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.Quote from: tautech on July 28, 2015, 03:46:52 amThanks, I will do that.

author: miguelvp
author_rank: Super Contributor
timestamp: July 28, 2015, 06:03:37 am
content: 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/#msg676772I 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.

author: Karel
author_rank: Super Contributor
timestamp: August 05, 2015, 07:22:00 pm
content: Quote from: jeremy on July 28, 2015, 05:40:56 amI 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.

author: jeremy
author_rank: Super Contributor
timestamp: August 05, 2015, 10:22:52 pm
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: August 06, 2015, 06:32:07 am
content: Quote from: jeremy on August 05, 2015, 10:22:52 pmNo, the DS1054Z works fine via USBTMC. There is a bug that makes it difficult to downloaddeep memory waveform data in raw mode but there's a workaround for that.Have a look at DSRemote.Quote from: jeremy on August 05, 2015, 10:22:52 pm... 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.Quote from: jeremy on August 05, 2015, 10:22:52 pmInteresting. DSRemote works fine with the DS1054Z without the need to patch the kernel i.e. without the rigol quirk.How do you explain this?

author: pklaus
author_rank: Newbie
timestamp: August 10, 2015, 08:19:20 am
content: Quote from: Karel on August 06, 2015, 06:32:07 amGood 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:[ 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 usbtmcThe/dev/usbtmc0device 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 thescreen update intervalto2000mS!) but currently not via USBTMC!

author: Karel
author_rank: Super Contributor
timestamp: August 10, 2015, 08:58:11 am
content: Quote from: pklaus on August 10, 2015, 08:19:20 amOn 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/USBPost 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...)

author: Karel
author_rank: Super Contributor
timestamp: August 10, 2015, 09:21:37 am
content: Quote from: pklaus on August 10, 2015, 08:19:20 amI 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.

author: pklaus
author_rank: Newbie
timestamp: August 10, 2015, 05:03:20 pm
content: Quote from: Karel on August 10, 2015, 08:58:11 amThanks 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:[ 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 -110The 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)

author: Karel
author_rank: Super Contributor
timestamp: August 10, 2015, 06:55:31 pm
content: 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.

author: pklaus
author_rank: Newbie
timestamp: August 10, 2015, 10:40:28 pm
content: Quote from: Karel on August 10, 2015, 06:55:31 pmWow! 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.

author: Karel
author_rank: Super Contributor
timestamp: August 11, 2015, 06:26:01 am
content: I'm glad to read you solved the problem

author: Hibou
author_rank: Newbie
timestamp: December 21, 2015, 08:26:26 pm
content: 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 awayHowever, today I upgraded to 00.04.03.02.03 and the USBTMC is broken againSimple commands still work but not fetching waveform data from memory. I am using Alex Forencich's Python USBTMC library.

author: Karel
author_rank: Super Contributor
timestamp: December 21, 2015, 08:41:23 pm
content: Quote from: Hibou on December 21, 2015, 08:26:26 pmI guess there's something wrong with that python lib. Here it works fine with usbtmc and latest firmware.

author: Hibou
author_rank: Newbie
timestamp: December 21, 2015, 08:59:40 pm
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: December 21, 2015, 10:57:57 pm
content: Quote from: Hibou on December 21, 2015, 08:59:40 pmIt takes 55 seconds to download 24Mpts via usbtmc.

author: jrpresto
author_rank: Newbie
timestamp: January 03, 2016, 02:56:48 am
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: January 03, 2016, 08:35:45 am
content: Quote from: jrpresto on January 03, 2016, 02:56:48 amHow long exactly?

author: RoGeorge
author_rank: Super Contributor
timestamp: October 20, 2016, 05:12:25 pm
content: This post is just to easily follow the subject.

author: _Wim_
author_rank: Super Contributor
timestamp: October 22, 2016, 10:05:23 am
content: Quote from: RoGeorge on October 20, 2016, 05:12:25 pmIs 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...)

author: Fungus
author_rank: Super Contributor
timestamp: October 22, 2016, 11:59:03 am
content: Quote from: RoGeorge on October 20, 2016, 05:12:25 pmWhat's to follow? The last post here was a looooong time ago.But thanks for reviving it with a pointless post.

author: tai
author_rank: Contributor
timestamp: October 20, 2022, 09:07:32 am
content: 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/408053a0955bf1712a5809240aa5544fI 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