Bug 1565 - Saleae16 clone continuous dumping stops after a couple seconds
Summary: Saleae16 clone continuous dumping stops after a couple seconds
Status: RESOLVED DUPLICATE of bug 762
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Driver: saleae-logic16 (show other bugs)
Version: 0.5.2
Hardware: x86 Linux
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-26 17:38 CEST by cand
Modified: 2020-06-30 18:01 CEST (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cand 2020-06-26 17:38:24 CEST
I have a mcupro saleae logic16 clone, 2018 variant. Using libsigrok 0.5.2 and sigrok-cli 0.7.1, continuous dumping stops after a couple seconds.

https://sigrok.org/bugzilla/show_bug.cgi?id=1134#c3
says it only happens with gregani firmware, but it happens for me using both gregani and the official one extracted from Logic%201.2.10%20(64-bit).zip.

sigrok-cli --channels 0-2 -c samplerate=20m --continuous -o dump.sr -l 3 2> log

sr: ezusb: uploading firmware to device on 1.23
sr: ezusb: setting CPU reset mode on...
sr: resource: Opened '/opt/sigrok/share/sigrok-firmware/saleae-logic16-fx2.fw'.
sr: ezusb: Uploading firmware 'saleae-logic16-fx2.fw'.
sr: ezusb: Uploaded 4096 bytes.
sr: ezusb: Uploaded 1121 bytes.
sr: ezusb: Firmware upload done.
sr: ezusb: setting CPU reset mode off...
sr: saleae-logic16: Waiting for device to reset.
sr: saleae-logic16: mcupro Saleae16 detected.
sr: saleae-logic16: Opened device on 1.24 (logical) / usb/1-1.2.4.4 (physical), interface 0.
sr: saleae-logic16: Device came back after 2002ms.
sr: session: Starting.
cli: Received SR_DF_HEADER.
Press any key to stop acquisition.
sr: saleae-logic16: receive_transfer(): status LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED received 75264 bytes.
cli: Received SR_DF_LOGIC (401408 bytes, unitsize = 2).
sr: saleae-logic16: receive_transfer(): status LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED received 75264 bytes.
cli: Received SR_DF_LOGIC (401408 bytes, unitsize = 2).
...snip...
sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 5632 bytes.
cli: Received SR_DF_LOGIC (30016 bytes, unitsize = 2).
sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes.
sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes.
..snip...
sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes.
cli: Received SR_DF_END.
sr: session: Stopped.
sr: saleae-logic16: Closing device on 1.24 (logical) / usb/1-1.2.4.4 (physical) interface 0.


md5sums:
80af10cd7c0d0cd8ba69d3bc60baa9f8  saleae-logic16-fx2.fw
d2e77817138276f4e9d73f56e3275ac9  saleae-logic16-fx2.fw-open-gregani (renamed when testing)
Comment 1 cand 2020-06-26 17:45:12 CEST
https://sigrok.org/bugzilla/show_bug.cgi?id=866 seems related. If I turn the sample rate down, it takes longer to stop, and on higher sample rates it stops quicker.
Comment 2 Soeren Apel 2020-06-27 12:48:02 CEST
Hi, this is expected behavior with sigrok-cli as of now. sigrok-cli has an inefficient data processing pipeline but as no one's working on that, it is what it is.

*** This bug has been marked as a duplicate of bug 762 ***
Comment 3 cand 2020-06-30 18:01:37 CEST
For future people entering here by google: some other bug said the vcd format works better, but for me it was only marginally better. However "-O binary" lets me dump with low enough cpu use for high sample rates. 25 MHz tested working for 10 seconds, on 3 channels.

Converting that to vcd or other formats then has the trick that you have to pass "-I binary:numchannels=16" - it saves by default the maximum channel count your hw can do, even if you're only recording a couple channels.