Created attachment 160 [details] output of "sigrok-cli --driver=uni-t-ut61e:conn=1a86.e008 -O analog --samples 3 -l 5" The device (UT61E) works properly, but after a call to "sigrok-cli --scan" (which also doesn't find the device), it stops working: $ sigrok-cli --driver=uni-t-ut61e:conn=1a86.e008 -O analog --samples 3 P1: 0.000000 V DC AUTO P1: 0.000000 V DC AUTO P1: 0.000000 V DC AUTO $ sigrok-cli --scan sr: fx2lafw: Failed to get manufacturer string descriptor: LIBUSB_ERROR_PIPE. sr: testo: Failed to get manufacturer string descriptor: LIBUSB_ERROR_PIPE. sr: testo: Failed to get product string descriptor: LIBUSB_ERROR_PIPE. The following devices were found: demo - Demo device with 12 channels: D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 A2 A3 $ sigrok-cli --driver=uni-t-ut61e:conn=1a86.e008 -O analog --samples 3 sr: uni-t-dmm: HID feature report error: LIBUSB_ERROR_PIPE. sr: uni-t-dmm: HID chip init failed: -1. After unplugging the device and plugging it back in, it works again (up to the next "sigrok-cli --scan"). When the device is unplugged, no "sr: ... LIBUSB_ERROR_PIPE." lines are printed, so all three of them are probably related to the DMM, and not some other USB device: $ sigrok-cli --scan The following devices were found: demo - Demo device with 12 channels: D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 A2 A3 Happens on an USB2 and an USB3 port. Also happens if the commands are run with root permission. The used libusbx library has version 1.0.19.
Confirmed, I'm seeing this as well on an UT61E with the same cable VID/PID. I'll look into this. Note however, that an unspecific scan cannot find the device, you have to provide the VID/PID for the scan to work (this is pretty much unavoidable since the same VID/PID could be almost any device, it's not specific to this cable or this DMM, unfortunately). $ sigrok-cli -d uni-t-ut61e:conn=1a86.e008 --scan The following devices were found: uni-t-ut61e - UNI-T UT61E with 1 channel: P1 $ sigrok-cli -d uni-t-ut61e:conn=1a86.e008 --samples 1 ... If the specific scan (see above) is used, the error behaviour doesn't happen. This might hint that some other other libusb-scanning for another driver confuses the DMM cable.
Even lsusb -vvv breaks the driver. The problem is: iManufacturer 1 (error) iProduct 2 (error) sigrok drivers: fx2lafw testo both access those properties in scan() A trivial fix would be check for VID:PID before accessing those fields, but that wouldn't really fix the problem coming out again in some other driver. If sr_usb_find has some way to blacklist so that it can give the device only when asked would work. However lsubs -vvv will still break the cable again. Also when trying to open uni-t device, there should be informative error message if LIBUSB_ERROR_PIPE is received. This is HW problem.