Hi, > While I do not have a legacy DSLogic, I do have a U3Pro16, so let me know if > you need any help testing your changes. I left a comment on the GitHub PR > with > some initial findings I found.
I went through the comments and pushed some updates to the PR today: - Change the buffer-deinterleaving worker thread to use a queue instead of a single buffer. This decouples USB transfers from data processing, i.e. the deinterleaving of the buffer (to convert from dslogic format to the format sigrok is expecting) is not blocking or slowing down USB transfers. This helps avoiding buffer underruns and receive errors especially at high sample rates. It comes at cost of additional memory consumption during reception but the buffers are immediately released once data postprocessing is done. - Proper handling of usb buffer underruns. It happened to me at high sample rates that in case of underruns the received data stream got misaligned with regards to the channels, i.e. I observed "channel swapping". This is fixed now. - Continous/streaming mode is now enabled by default which addresses some of your comments you added to the PR: By using streaming mode, the data is updated in real time in pulseview and not only at the end of the capture. Since I improved now the deinterleaving of the buffer (as described above) the streaming mode can be used also along with high sample rates. The limits are: 1GHz: Max. 3 channels 500MHz: Max. 6 channels 250MHz: Max. 12 channels If you try to enable more channels for one of these sample rates, pulseview will silently ignore it and immediately stop the capture again. If the U3Pro16 is connected to a USB2 port, capturing 16 channels works reliable up to 20MHz, if you want to go for higher sample rates, numbers of channels needs to be reduced. Would appreciate if you could test the latest updates. Thanks, Christian. _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
