Is there a timeline for when analyser support will be added to the MSO api? Ideally being able to setup analysers in the capture and get the output frames of each analyser for a given capture.
@andrew1 In looking through our mso_api, you’re right in that there is currently no function available to set up analyzers. Were you looking for something similar to add_analyzer() from saleae.automation available for our logic analyzers? Let us know if you need any other functionality as well on top of that.
Seconding this request! add_analyzer() parity in the MSO libraries would help me immensely. Or a programmatic way to save a .sal file from a capture that I can then import with the existing logic 2 apis
(I’m working on hardware in the loop testing, so a fully automated flow is crucial to my application)
Hello,
We’re pretty close on this. If it’s not out by the end of next week, please check in on it.
We’re working on two big changes to the Saleae API situation.
First, we’re creating a new headless API implementation of our existing logic2-automation library. Currently, this library & API only supports our logic analyzer devices (no MSO support) and it connects to the Logic 2 GUI software. The new implementation uses the same API (logic2-automation can use it directly, as well as other user generated gRPC clients) but it runs on a new headless binary without Logic 2. This is almost out now. We hoped to ship it today, but had a few delays this week. It should be out next week.
Then, we’re expanding the logic2-automation API to include Logic MSO. We’ll continue to support the existing python mso-api for now, but we’ll recommend everyone switch over to the new system once it’s out. The experience will be pretty similar, except that you will be able to add protocol analyzers, and you will be able to save captures taken with the API and load them into the Logic 2 software.
We’re hopeful that will ship next week too, a few days after the first release.
I’m hopeful this will go smoothly.
This is so exciting! Thank you for the update and for all the work on building awesome infrastructure.
We just shipped headless automation support for Logic Analyzer Devices: Headless logic2-automation Support
MSO is next!
This is great news. Being able to use the logic2-automation api with the MSO would be great. Although there are a few mso-api features which are nice to have like the analog triggers. I assume the intent is to migrate any mso-api specific features into logic2-automation and depreciate mso-api entirely?
Hi Andrew. This is basically correct, although we don’t have to deprecate it right away.
Some quick background.
mso-api is a python wrapper around a native binary (mso_data_recorder.exe) which exists in the same codebase as the Logic 2 GUI’s data processing backend. The new headless API is in the same codebase, and it basically sits on a higher layer of abstraction, but all the code used by mso-api is still used by the new logic2-automation headless server.
The only other difference is that mso_data_recorder used standard in/standard out communicate with python while the new binary uses gRPC. We’re considering building a version without the gRPC layer too, potentially just exposing a C API, although the actual API surface will likely be similar to the gRPC interface.
Basically, mso-api existed at a pretty low level, so it was not going to be easy to add analyzer support, digital trigger support, or save/load support for *.sal files, etc. However there should basically be no difference between the new headless API and mso-api in terms of performance or overhead, unlike the Logic 2 GUI’s automation server, which added considerable overhead.
Although there are a few mso-api features which are nice to have like the analog triggers.
We’re pulling in everything mso-api’s capture system could do. Once it’s out, let us know if you are missing anything. There are a few python-only things that we’re not porting into the logic2-automation library, but would be very easy to release separately. Specifically, all the features that allowed actual data access from python were just python-only implementations that read the exported files from the native binary. Those export formats are unchanged.