Created attachment 223 [details] lwla1034 timeout I bought a Sysclk LWLA1034 as it shows as fully supported in the sigrok wiki. Unforutnately on both Windows and Linux I can't get it to last more than 5 seconds of capturing. Pulseview doesn't start capturing at all, and the CLI stops after 5 seconds with a timeout. Changing the sample rate/number of channels doesn't help, and it's connected directly (no hubs) through a good USB cable. My builds of the various sigrok parts work fine with an 8CH fx2 "clone". The Windows binaries tested were downloaded development snapshots. Hopefully it's a simple fix... are there minor hardware variations maybe? I've attached a log of: $ sigrok-cli --loglevel 5 -d sysclk-lwla --samples 4g
That USB timeout should not happen, but it only occurs eventually after a long sequence (more than 4 seconds) of correctly working status polls: sysclk-lwla: Captured 11 words, 4112 ms, status 0x64. The fact that it's still at 11 words after 4 seconds likely indicates that your signal source is not toggling. Make sure it's all connected correctly, and perhaps try the original Windows software to verify. It still shouldn't randomly time out on USB requests (the polling could theoretically continue almost forever without a signal source), but I think that's a separate problem you might not even see otherwise.
Note that the 40 pin connector with the probe leads needs an unusually high insertion force to fully connect, to the point that one fears it might break in the process. If your connector can easily be wiggled to the sides, it's not fully inserted yet.
(In reply to comment #1) > That USB timeout should not happen, but it only occurs eventually after a > long sequence (more than 4 seconds) of correctly working status polls: > > sysclk-lwla: Captured 11 words, 4112 ms, status 0x64. > > The fact that it's still at 11 words after 4 seconds likely indicates that > your signal source is not toggling. Make sure it's all connected correctly, > and perhaps try the original Windows software to verify. > > It still shouldn't randomly time out on USB requests (the polling could > theoretically continue almost forever without a signal source), but I think > that's a separate problem you might not even see otherwise. Thanks for the reply. I didn't have a signal source connected when I took this log. Just to rule that out as a possible cause I will connect it to something and get a new log file. The (partially translated, unreliable) Windows software that came with it does start a sucessful capture.
(In reply to comment #3) > I didn't have a signal source connected when I took this log. Just to rule > that out as a possible cause I will connect it to something and get a new > log file. Right, please do. BTW you can also log from PulseView, using the same "-l 5" command line option.
Created attachment 224 [details] lwla1034 timeout (with signal input)
Created attachment 225 [details] lwla1034 pulseview log
(In reply to comment #4) > (In reply to comment #3) > > I didn't have a signal source connected when I took this log. Just to rule > > that out as a possible cause I will connect it to something and get a new > > log file. > > Right, please do. BTW you can also log from PulseView, using the same "-l 5" > command line option. Both attached. The pulseview log shows me starting pulseview, forgetting to connect the device, connecting it, setting 10MHz & 2G samples, and hitting run a couple of times. Thanks!
(In reply to comment #7) > Both attached. The pulseview log shows me starting pulseview, forgetting to > connect the device, connecting it, setting 10MHz & 2G samples, and hitting > run a couple of times. Interesting. PulseView fails immediately after initialization, whereas sigrok-cli fails initially, gets the device working on retry, and then runs just fine for 4 seconds. As to forgetting to connect -- I assume you mean plugging in the USB cable? What happens if you start PulseView with the device already plugged in? It should show up in the device selection box automatically. About the sigrok-cli run: It seems your signal source has a fairly low toggling rate. What happens if you connect a higher-speed signal, so that the internal buffer fills up before that ominous 4 seconds mark? It would be quite interesting to see if it is able to retrieve the captured samples in that case. In any case, that's a really weird bug. It makes little sense that it would always fail after 4 seconds -- the timeouts are per USB transfer, not for the whole session. Could you also attach the dmesg output showing what happens when you plug in the USB cable? Thanks a lot.
(In reply to comment #8) > (In reply to comment #7) > > Both attached. The pulseview log shows me starting pulseview, forgetting to > > connect the device, connecting it, setting 10MHz & 2G samples, and hitting > > run a couple of times. > > Interesting. PulseView fails immediately after initialization, whereas > sigrok-cli fails initially, gets the device working on retry, and then runs > just fine for 4 seconds. > > As to forgetting to connect -- I assume you mean plugging in the USB cable? > What happens if you start PulseView with the device already plugged in? It > should show up in the device selection box automatically. Yes - just in case you wondered what the bunch of "0 devices found" (or similar) was. With it already connected, it does behave as you describe - automatically selects it, and defaults to 1M samples at 125MHz. > About the sigrok-cli run: It seems your signal source has a fairly low > toggling rate. What happens if you connect a higher-speed signal, so that > the internal buffer fills up before that ominous 4 seconds mark? It would be > quite interesting to see if it is able to retrieve the captured samples in > that case. (log file to follow) > In any case, that's a really weird bug. It makes little sense that it would > always fail after 4 seconds -- the timeouts are per USB transfer, not for > the whole session. > > Could you also attach the dmesg output showing what happens when you plug in > the USB cable? Thanks a lot. [43402.637508] usb 3-3: new high-speed USB device number 35 using xhci_hcd [43402.811946] usb 3-3: New USB device found, idVendor=2961, idProduct=6689 [43402.811950] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [43402.811951] usb 3-3: Product: LWLA-1034 v1.0 [43402.811953] usb 3-3: Manufacturer: www.SysClk.com
Created attachment 226 [details] lwla1034 log with faster signal