[Request] Automation: Continous capturing

[piro-pp]

I have the use case that i want to continuously observe 2 UART channels, RX and TX, to be able to process the data with further scripts.

I'm using the "Async Serial" protocol analyzer for this. There is the non-automated terminal view for this, that is quite good for human parsing, but doesn't work flawlessly with more than one UART (Async Serial), as the ordering is not strict and line endings may not be as expected by the plugin.

I wrote a script that runs a task to continuously capture x-second fragments to export them to a file or named pipe and it runs a task that reads from that file for further processing. Between each end and restart of a recapturing there is a small delay that may lead to data loss that are of course unwanted.

It is clear that a "real-time" output is not doable, but at least a way to have a periodically updated stream without data loss would be fine.

Also it would be a good to have a "start" function for a Capture that resets the data, but reuses the capture mode, device configuration and the analyzers and doesn't create new capture tabs in the GUI.

[Marcus10110]

Hi @piro-pp,

You can get access to the live UART data while in looping mode using one of our other APIs.
I would suggest looking at our HLA API first. this lets you write a python decoder that processes protocol data from the lower level analyzers as it's produced. In most UART applications, this should be able to run in real time too.
You can learn more here:
https://support.saleae.com/extensions/high-level-analyzer-extensions

This will require a bit of coordination, since you will have 2 instances of your HLA running at the same time. I suggest passing in a setting that they can use to identify themselves.

Alternatively, you could do the same in the C++ analyzer API, by forking our UART analyzer here: https://github.com/saleae/serial-analyzer

You will have the same coordination challenges there too.

Ironically, we use named pipes to connect the analyzers to the terminal in our UI. However it doesn't include the necessary timestamp information required to produce a single ordered stream.

Time sorting multiple analyzers in the terminal view is a priority for us, but it is a challenge, and we haven't committed to it yet. The main problem is that the current terminal implementation does not support inserting, only appending. Our protocol analyzers need to accurately report their progress and guarantee that they won't produce frames from before that timepoint in order for us to be able to guarantee correctly sorted frames. There is a system for that but it's never been validated to this standard, and will likely require modifying each of our analyzers. Alternatively, we could replace the terminal view with something much more complex, but not without a performance hit.