Created attachment 691 [details] Screenshots of behaviour Hi Sigrok, I've experience a few issues with pulseview with a new siglent 1104X-E - Pulse view - (020/10/2020 nightly build - Siglent s/w V6.1.35R2, uboot os V8.1, FPGA V2019-11-15) So far after trying various operating systems Windows 10, Mac osx mojave and Mac osx catalina and usb and network communications and stable builds of pulseview, I have not managed to capture any data. BEHAVIOUR #1 With latest nightly build - On startup The Siglent is recognised via USB and after trying "run", wait a few seconds and then "stop" a few times the log shows " sr: scpi_usbtmc: USBTMC invalid bulk in header. sr: scpi_usbtmc: USBTMC invalid bulk in header. sr: scpi_usbtmc: USBTMC invalid bulk in header. pv: Acquisition took 3.55 s pv: Acquisition took 3.55 s scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT. pv: Acquisition took 8.09 s " and then at some point after running a couple of times the program hangs and I have to force quit. Screen shots of logs attached. The later of which you have to force quit out of and log view will not come to foreground, as if the main window thinks it is showing a dialogue? BEHAVIOR #2 When trying to go into the "Connect to Device" and the selecting the "siglent..." in "step 1:Choose the driver". On selecting any driver the program crashes. REMEDIAL TEST I have also tried the "stable builds" and nightly builds on various operating systems. Stable builds - these don't crash on device selection but they also do not capture any data. I tried a to build the project on mac osx catalina with QT 5.15. It built with warning about depreciated calls. However, again, it did not capture any data. Any help would be gratefully received to resolve this. If you need any further info please let me know. I'd really like to get this running as it is an awesome product. Thank you Andy
I downloaded the latest nightly build 18/11/2020 and the LIBUSB_ERROR_TIMEOUT error is gone. However, still no data captured and selection of a device still crashes the program - only tested on Catalina sr: scpi_usbtmc: Successfully sent SCPI command: 'SANU? C1 '. sr: scpi: Got response: '3.50E+06', length 8. sr: scpi_usbtmc: Successfully sent SCPI command: ':TDIV? '. sr: scpi: Got response: '5.00E-04', length 8. sr: siglent-sds: Current timebase: 0.0005. sr: siglent-sds: Current samplerate: 500000000.000000. sr: siglent-sds: Current memory depth: 3500000. sr: hwdriver: sr_config_get(): key 30000 (samplerate) sdi 0x7f829e7f4270 cg NULL -> uint64 500000000 sr: session: Using thread-default main context. sr: session: Starting. sr: hwdriver: siglent-sds: Starting acquisition. sr: scpi_usbtmc: Successfully sent SCPI command: 'SANU? C1 '. sr: scpi: Got response: '3.50E+06', length 8. sr: scpi_usbtmc: Successfully sent SCPI command: ':TDIV? '. sr: scpi: Got response: '5.00E-04', length 8. sr: siglent-sds: Current timebase: 0.0005. sr: siglent-sds: Current samplerate: 500000000.000000. sr: siglent-sds: Current memory depth: 3500000. sr: session: bus: Received SR_DF_HEADER packet. sr: siglent-sds: Starting data capture for active frameset 1 of 1 sr: scpi_usbtmc: Successfully sent SCPI command: 'ARM '. sr: scpi_usbtmc: Successfully sent SCPI command: ':INR? '. sr: scpi: Got response: '8192', length 4. sr: session: bus: Received SR_DF_FRAME_BEGIN packet. sr: session: Stopping. sr: hwdriver: siglent-sds: Stopping acquisition. sr: session: bus: Received SR_DF_END packet. sr: usb: usb_source_finalize sr: session: Stopped. pv: Acquisition took 1.22 s
Error log of Nightly build 18/11/2020 on Windows 10. sr: scpi_usbtmc: USBTMC invalid bulk in header. sr: scpi_usbtmc: USBTMC invalid bulk in header. sr: scpi_usbtmc: USBTMC invalid bulk in header. sr: scpi_usbtmc: USBTMC invalid bulk in header. sr: scpi_usbtmc: USBTMC invalid bulk in header. sr: scpi_usbtmc: USBTMC invalid bulk in header. sr: scpi_usbtmc: USBTMC invalid bulk in header. scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT. scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT. scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT. scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT. pv: Acquisition took 4.07 s
I'm attempting to use Sigrok/PulseView on Ubuntu 20.04 with a Siglent 1202X-E and am seeing the same bulk data issue. Its currently impossible to retrieve any data from the scope. The ticket is in progress I see but is there any further information I can provide to assist with the fix or is the problem known already?
Hi Hamid, I have a pull request for the X-E series ready, but unfortunately I don't have any idea if/when it's going to get merged since I'm not a core maintainer. I've made a couple of requests for comments but have gotten only radio silence so far. https://github.com/sigrokproject/libsigrok/pull/118 It's worth nothing that performance of USB acquisition is quite a bit slower than TCP acquisition due to the fact that Siglent scopes use tiny 64 byte usb packets. It's still usable though. It would be great to get some feedback on the PR. Are you able to try it out from source?
(In reply to voneiden from comment #4) > Hi Hamid, > > I have a pull request for the X-E series ready, but unfortunately I don't > have any idea if/when it's going to get merged since I'm not a core > maintainer. I've made a couple of requests for comments but have gotten only > radio silence so far. > > https://github.com/sigrokproject/libsigrok/pull/118 > > It's worth nothing that performance of USB acquisition is quite a bit slower > than TCP acquisition due to the fact that Siglent scopes use tiny 64 byte > usb packets. It's still usable though. > > It would be great to get some feedback on the PR. Are you able to try it out > from source? Hi, I built PulseView from the official repo, along with libsigrokdecode from there too and using your libsigrok fork (sds-eseries) it worked immediately, I was able to view the test waveform, which is the first time I've ever seen _any_ waveform out of PulseView. It is surprisingly slow! TCP networking would be nice but I don't have cabling near my scope.
Thanks for trying it out, good to hear it works. Marcel, the original author of the Siglent driver said he'd contact Siglent and ask about increasing the USB packet size from 64 bytes to something more sane. The USB send buffer on (all?) Siglent scopes is 61440 bytes, so they could get some improvement by sending 1 big packet instead of 960 tiny packets. On the TCP side it seemed like the whole waveform can fit into the send buffer and the transfer speed is mainly limited by how long it takes for the scope to fill up the buffer.
(In reply to voneiden from comment #6) > Thanks for trying it out, good to hear it works. > > Marcel, the original author of the Siglent driver said he'd contact Siglent > and ask about increasing the USB packet size from 64 bytes to something more > sane. The USB send buffer on (all?) Siglent scopes is 61440 bytes, so they > could get some improvement by sending 1 big packet instead of 960 tiny > packets. > > On the TCP side it seemed like the whole waveform can fit into the send > buffer and the transfer speed is mainly limited by how long it takes for the > scope to fill up the buffer. Interesting, I wonder why so low? Is their USB stack implemented in the FPGA and they kept the packet size small for that reason? What's the time frame for Marcel asking for the larger packet size, is this something that happened recently, or has it been a while? I wonder if we can poke Siglent about it individually? Also, if the code to handle this isn't in the FPGA, I wonder whether we could modify the scope's code manually? It seems a little nuts to hobble the USB speed like this.
Marcel intended to do it on 4th of February. Haven't followed up with him since then. If you check out uboot dump by Dave @ https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-hack/msg3086126/#msg3086126 Relevant part: usbtmc_para = insmod /usr/bin/siglent/drivers/g_usbtmc.ko idVendor=0xf4ec idProduct=0x1011 iManufacturer=Siglent iProduct=SDS2354XPlus iSerialNum=SDS2PCBC4R0071 [ 35.395239] ######################### usb_gadget_probe_driver 3f05b46c ################## [ 35.403419] usbtmc_bind+++ [ 35.408292] SIGLENT_DEV: SIGLENT_DEV, version: 2007 OCT 06 [ 35.414864] usbtmc_open()++ [ 35.417611] dev->usbtmc_cdev_open ret = 0 [ 35.421636] ret = 0 [ 35.423659] usbtmc_open-- [ 35.426397] show_send_buffer_size = 61440 That might help get you started? It's definitely linux handling the usbtmc protocol there.