Version 3.5.0.0 only capturing a few samples on Linux

[DevBruker]

Hi, it seems that Logicanalyzer 3.5.0.0 on Linux captures without returning any samples if the post-samples exceeds 4339. The pre-samples range is also limited. The allowed ranges for pre-samples is [2, 29] and for post-samples it is [512, 4339].

During capture the led is slowly blinking and after the fulfilled trig condition (falling edge) the led stops blinking signalling a capture. But, no capture is shown and the "Abort" button is still the only active button. Clicking "Abort" prints the following message to the console: " The port is closed. - at System.IO.Ports.SerialStream.Read(Byte[] array, Int32 offset, Int32 count, Int32 timeout)
at System.IO.BinaryReader.InternalRead(Int32 numBytes)
at System.IO.BinaryReader.ReadUInt16()
at SharedDriver.LogicAnalyzerDriver.ReadCapture(Int32 Samples, Byte Mode) in C:\Users\geniw\source\repos\LogicAnalyzer\SharedDriver\LogicAnalyzerDriver.cs:line 344
"

Tried with 8, 16 and 24 modes without success. It takes about 4-5 seconds from when the led stops blinking to the samples are shown in the LogicAnalyzer (when the pre- and post-samples are in the "allowed" range).

ClCapture fails with error message: " ClCapture capture /dev/ttyACM2 1000000 1 20 1014 TriggerType:Edge,Channel:1,Value:0 out-capture.csv
CLCapture 1.0.0 Copyright (C) 2023 CLCapture

ERROR(S): A value not bound to option name is defined with a bad format. A required value not bound to option name is missing.

--help Display this help screen. ---- rest of output deleted ---- " Should ClCapture version be 1.0.0?

Both LogicAnalyzer and ClCapture works when reverting to the previous version (2.0.0.1).

This is on Ubuntu 22.04 with a standard Pico with no WiFi, using Firmware-LogicAnalyzer-3.5.0.0.uf2.

I would be happy to do further tests if needed. By the way, the extended capture is brilliant!

[gusmanb]

Hi!

Thanks for the report. You are right, I'm checking it in Debian and indeed it has the described problem. This is caused by a bug in .net 6.0 serial port and a change I did to the shared driver. As I introduced the network connection to the W I unified the transfer method using streams, and I forgot that under Linux the serial port using streams gets hung... doh!

I'm going to try to update the applications and the driver to .net 7.0 and check if the problem is solved and in case that it still has this problem I will revert to the old transfer code.

Cheers.

[gusmanb]

@DevBruker I got the problem with the driver fixed, at the end I had to go back to the old transfer code, it's not solved in .net 7.0, there is no new Ports package :(

What I haven't been able to reproduce is the problem with the CLCapture app, I have downloaded the 3.5 version from the repo to the Debian machine, copy-pasted the parameters of the command line from your comment and it worked... The error complains about a missing parameter, is it possible that in the real machine you tried a different command line?

In any case here is the new CLCapture compiled, try if with it the command line gets correctly parsed. Once you confirm if it works or not I will create a new release (it's uploaded to Mega as it is bigger than 25Mb)

https://mega.nz/file/CWhzjTZC#O9Wd4sjj1wT2EKKvkJyKIIsS2wlGyLOZUOoxrF8NQCA

Cheers.

[DevBruker]

Hi, CLCapture works now, even with 131070 samples :) CLCapture is in mode 8 by default? Is it possible to set the mode?

I could not get CLCapture to work earlier because I did not start it as a local version with ./ in front, thereby starting an old version from the path...

Thank you for the prompt reply!

[gusmanb]

Glad it works!

CLCapture chooses the best suited mode based in the channels you select to capture, if the selected channels are below channel 9 it uses the 8 channel mode, if they're below channel 17 then uses the 16 channel mode and for the rest uses the 24 channel mode.

Cheers!

[gusmanb]

New release with the updated driver has been published.

Cheers!