Siglent SPD3303D failures on Linux via USBTMC - Page 1
Forum section: electronics / testgear

author: leonerd
author_rank: Regular Contributor
timestamp: October 22, 2015, 11:54:58 pm
content: I've recently got myself the Siglent SPD3303D PSU. I'm having some trouble making it work properly over USBTMC on Linux.It appears just fine as a USB device;dmesgsays:Code:[ 1549.407970] usb 1-1.2: new full-speed USB device number 5 using ehci-pci[ 1549.502781] usb 1-1.2: New USB device found, idVendor=0483, idProduct=7540[ 1549.502791] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 1549.502795] usb 1-1.2: Product: SPD3000 SERIES[ 1549.502799] usb 1-1.2: Manufacturer: STMicroelectronics[ 1549.502803] usb 1-1.2: SerialNumber: SPD30CE4140019It creates a/dev/usbtmc0device node.I can control the power supply just fine by blind-writing down that device node. Any changes made this way are reflected on the control panel and outputs of the device:Code:$ ./usbtmcshSCPI> CH1:VOLT 7.5SCPI> CH1:CURR 0.4SCPI> OUTP CH1, ONSCPI>However, any attempts to read any status information from the PSU all fail:Code:SCPI> CH1:CURR?Error reading device - Connection timed outSCPI> *IDN?Error reading device - Connection timed outThese all happen after a 5 second timeout. If I load theusbtmcdriver module with debugging enabled, I getCode:$ sudo modprobe usbtmc dyndbg==fpm$ dmesg -w...[ 1885.738006] usbtmc:usbtmc_read: usbtmc 1-1.2:1.0: usb_bulk_msg_in: remaining(8192), count(8192)[ 1890.739231] usbtmc:usbtmc_read: usbtmc 1-1.2:1.0: usb_bulk_msg: retval(4294967186), done(0), remaining(8192), actual(0)[ 1890.739244] usbtmc:usbtmc_read: usbtmc 1-1.2:1.0: Unable to read data, error -110I'd almost be willing to give this up as "it just won't work", except that very very occasionally, I can get a response out of it just fine, but only if it's the very first thing I do after powering it up and plugging it in. About three times ever, I have managed:Code:$ ./usbtmcshSCPI> *IDN?< Siglent Technologies,SPD3303,SPD30CE4140019,1.01.01.01.06R1,V1.2Which resulted in:Code:[ 634.834263] usbtmc:usbtmc_read: usbtmc 1-1.2:1.0: usb_bulk_msg_in: remaining(8192), count(8192)[ 634.864384] usbtmc:usbtmc_read: usbtmc 1-1.2:1.0: usb_bulk_msg: retval(0), done(0), remaining(8192), actual(80)[ 634.864396] usbtmc:usbtmc_read: usbtmc 1-1.2:1.0: Bulk-IN header: N_characters(65), bTransAttr(1)[ 634.864403] usbtmc:usbtmc_read: usbtmc 1-1.2:1.0: Bulk-IN header: remaining(0), buf(0000000000e24d40), buffer(ffff8801eb003800) done(0)So my question: Has anyone ever managed to get this PSU to work via USBTMC on Linux?Failing that; does anyone have any technical contacts at Siglent that we might be able to discuss the issue with? This has all the feelings of some minor implementation bug in the PSU's firmware, that could be fixed with a firmware update.

author: bson
author_rank: Unknown
timestamp: October 23, 2015, 12:09:30 am
content: It's worth noting that /dev/usbtmc1 is the first instrument and /dev/usbtmc0 contains a device list of what's present (for discovery). The latter is plain text with a single header line and one line per device. Also lsusb -t gives a device tree that can be useful sometimes.BTW, it probably suffers from the Rigol quirks and needs to have the VID,PID added to the list for special treatment.

author: leonerd
author_rank: Regular Contributor
timestamp: October 23, 2015, 08:39:07 am
content: Quote from: bson on October 23, 2015, 12:09:30 amAfraid not -usbtmc0being an enumerator device is a feature of the Agilent-written driver, not the one that eventually made it into Linux core.usbtmc0works fine talking to, for example, my Rigol DS1054Z (now I've updated the firmware on it to 04.03.SP1). Also, sending commands tousbtmc0still works fine against the Siglent PSU, I just can't read from it. Except those few rare times.Quote from: bson on October 23, 2015, 12:09:30 amI even tried that; that didn't help either.

author: tautech
author_rank: Super Contributor
timestamp: October 23, 2015, 09:05:26 am
content: Siglent have been informed of this issue by USA and myself.An email from Jexy (tech support) in reply to me:Steve has told me this problem,in the morning.But now ,we can not give you any reply.I 'm waiting for the R&D's answer.They are testing this issue.

author: markmerz
author_rank: Newbie
timestamp: October 23, 2015, 09:50:03 am
content: Hi!I tryed to pair my entrylevel siglent scope and generator with linux lately useing usbtmc driver. (sorry for "regulating" irregular verbs, never sure about them..So far i learned that:reading from scope must be done by chunks no bigger then 1KiB. Otherwise random read errors and timeouth will occur.If reading cycle is implemented "regular way", that is as:while(read(usbtmcfd, buf, buf_size) > 0) { ...then annoying timeout occurs. Reading cycle must be implemented as:while(read(usbtmcfd, buf, chunk_size) == chunk_size) { ...Difference is that we do not expect to read EOF from device.When sending command which does not generate reply then program must not try to read from device. Otherwise 2-3 seconds timeout occurs.Scope does not needs delay between writing command and reading reply but generator needs about 1 second delay after sending command.I posted a link to my experimental software which tries to deal with those quirks in my eariler posts.Maybe those remarks help with you problem.As i restarted my EE hobby couple of months ago after over 20 years pause then i wont at least now try to forge my "siglscope" software to shelf-product. It allready helps me to dive into black art of analog filter designMaybe later..

author: leonerd
author_rank: Regular Contributor
timestamp: October 23, 2015, 01:14:54 pm
content: Quote from: markmerz on October 23, 2015, 09:50:03 amAh. Currently my code is reading 8192 byte chunks. I'll change it to 1024 and see what happens.Quote from: markmerz on October 23, 2015, 09:50:03 amYes - currently I'm only making a singleread()call, not even in a loop. It's the very first one that reliably fails every time. I am never able toread()anything from the PSU at all.Quote from: markmerz on October 23, 2015, 09:50:03 amIndeed I do that - I only even attempt a read if the sent command had a?symbol in it.Quote from: markmerz on October 23, 2015, 09:50:03 amAh interesting. Thing is, I've tried just asking it questions like*IDN?orCH1:VOLT?while it was otherwise idle, and still I get nothing.

author: leonerd
author_rank: Regular Contributor
timestamp: October 23, 2015, 01:18:11 pm
content: Quote from: tautech on October 23, 2015, 09:05:26 amThanks tautech - I shall eagerly await a reply from yourself, Jexy, or Steve - whoever these people turn out to beHappy to assist if I can, testing various bits and pieces. I'm quite familiar now with the inner workings of Linux'susbtmcdriver so I'm happy to insert debug statements, adjust code, etc... as required.

author: leonerd
author_rank: Regular Contributor
timestamp: October 24, 2015, 12:56:50 pm
content: Quote from: leonerd on October 23, 2015, 01:14:54 pmWell, I've even tried it right down at reading in 64byte chunks at once. Nothing at all comes in.

author: leonerd
author_rank: Regular Contributor
timestamp: October 24, 2015, 01:05:08 pm
content: If it is of any help to anyone, I've tried adding the debug flags tousbcoreas well, and additionally I now get:Code:[59882.830212] usbtmc:usbtmc_read: usbtmc 2-1.1:1.0: usb_bulk_msg_in: remaining(8192), count(8192)[59887.831310] usbcore:usb_start_wait_urb: usb 2-1.1: usbtmcsh timed out on ep2in len=0/2048[59887.831325] usbtmc:usbtmc_read: usbtmc 2-1.1:1.0: usb_bulk_msg: retval(4294967186), done(0), remaining(8192), actual(0)[59887.831331] usbtmc:usbtmc_read: usbtmc 2-1.1:1.0: Unable to read data, error -110

author: leonerd
author_rank: Regular Contributor
timestamp: October 29, 2015, 10:14:17 am
content: Ahah! Finally some progress.Jexy, the R&D engineer at Siglent, suggested that the Siglent PSU is quite slow to reply and that I should add a delay of "100msec to 1s" between sending the command and trying to read the reply. Well, it turns out that even a short delay of only 10msec is quite sufficient to be able to read replies nice and reliably now.It's a little upsetting that such a hack is required, but now I can at least make some progress in using it. I'll also have to look into whether that ought to be built into the kernel, or what... Hopefully there'll be a neater solution that involves the kernel blocking a read until data is available - I'd hate to have to delay every single USBTMC command by 10msec just because a few devices are slow.

author: Karel
author_rank: Super Contributor
timestamp: October 29, 2015, 01:37:41 pm
content: Quote from: leonerd on October 29, 2015, 10:14:17 amYou should not. Delays of 10 milliSec. in kernelspace are not done.There's also no need to do so. You can ad a delay in userspace in your program between sending a command and reading the data.However, best solution is to update the firmware... Chinese manufacturers of test and measurement equipment are notorious for writing bad firmware.Specially the part where SCPI is involved, either via LAN or USB. But that's the price we pay for buying cheap equipment.

author: sequoia
author_rank: Unknown
timestamp: June 23, 2020, 11:13:28 pm
content: Quote from: leonerd on October 29, 2015, 10:14:17 amDid Siglent ever fix the firmware for SPD3303D? As seems like SPD3303X/SPD3303X-E suffer from the same, needing about 100msec delay after sending a command, or otherwise unit won't respond...Firmware seems pretty "beta" at most, not using USB IDs belonging to Siglent and reporting "Mfr=1, Product=2, SerialNumber=3":Code:[759554.177152] usb 1-1.1: new full-speed USB device number 20 using xhci_hcd[759554.314072] usb 1-1.1: New USB device found, idVendor=0483, idProduct=7540, bcdDevice= 1.00[759554.314092] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3[759554.314105] usb 1-1.1: Product: SPD3000[759554.314117] usb 1-1.1: Manufacturer: Siglent