Siglent SPD3303D failures on Linux via USBTMC

[leonerd]

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; dmesg says:

Code: [Select]

[ 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: SPD30CE4140019
It creates a /dev/usbtmc0 device 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: [Select]

$ ./usbtmcsh
SCPI> CH1:VOLT 7.5
SCPI> CH1:CURR 0.4
SCPI> OUTP CH1, ON
SCPI>
However, any attempts to read any status information from the PSU all fail:

Code: [Select]

SCPI> CH1:CURR?
Error reading device - Connection timed out
SCPI> *IDN?
Error reading device - Connection timed out
These all happen after a 5 second timeout. If I load the usbtmc driver module with debugging enabled, I get

Code: [Select]

$ 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 -110
I'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: [Select]

$ ./usbtmcsh
SCPI> *IDN?
    < Siglent Technologies,SPD3303,SPD30CE4140019,1.01.01.01.06R1,V1.2
Which resulted in:

Code: [Select]

[  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.

[bson]

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.

[leonerd]

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.

Afraid not - usbtmc0 being an enumerator device is a feature of the Agilent-written driver, not the one that eventually made it into Linux core. usbtmc0 works fine talking to, for example, my Rigol DS1054Z (now I've updated the firmware on it to 04.03.SP1). Also, sending commands to usbtmc0 still works fine against the Siglent PSU, I just can't read from it. Except those few rare times.

BTW, it probably suffers from the Rigol quirks and needs to have the VID,PID added to the list for special treatment.

I even tried that; that didn't help either.

[tautech]

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.

[markmerz]

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 design Maybe later..

 

[leonerd]

reading from scope must be done by chunks no bigger then 1KiB. Otherwise random read errors and timeouth will occur.

Ah. Currently my code is reading 8192 byte chunks. I'll change it to 1024 and see what happens.

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.

Yes - currently I'm only making a single read() call, not even in a loop. It's the very first one that reliably fails every time. I am never able to read() anything from the PSU at all.

When sending command which does not generate reply then program must not try to read from device. Otherwise 2-3 seconds timeout occurs.

Indeed I do that - I only even attempt a read if the sent command had a ? symbol in it.

Scope does not needs delay between writing command and reading reply but generator needs about 1 second delay after sending command.

Ah interesting. Thing is, I've tried just asking it questions like *IDN? or CH1:VOLT? while it was otherwise idle, and still I get nothing.

[leonerd]

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.

Thanks tautech - I shall eagerly await a reply from yourself, Jexy, or Steve - whoever these people turn out to be

Happy to assist if I can, testing various bits and pieces. I'm quite familiar now with the inner workings of Linux's usbtmc driver so I'm happy to insert debug statements, adjust code, etc... as required.

[leonerd]

reading from scope must be done by chunks no bigger then 1KiB. Otherwise random read errors and timeouth will occur.

Ah. Currently my code is reading 8192 byte chunks. I'll change it to 1024 and see what happens.

Well, I've even tried it right down at reading in 64byte chunks at once. Nothing at all comes in.

[leonerd]

If it is of any help to anyone, I've tried adding the debug flags to usbcore as well, and additionally I now get:

Code: [Select]

[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

[leonerd]

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.

[Karel]

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.

You 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.

[sequoia]

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.

Did 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: [Select]

[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