It would be very useful to be able to access common measurement (1.x) and measurement extension (2.x) parameters via the socket API. File I/O is a bottleneck and it would be great to avoid writing then reading and post-processing data for simple things like peak-to-peak or dBV analog measurement (extension for dBV conversion via the flexible python extension capabilities in 2.x).
Activity Newest / Oldest
"Hi, a feature request: ability to name the channels, and to add notes. Adding autonomous measurements would also be great, but I assume that's a lot more complex than just adding the ability to name a channel.
This is super helpful software though. Makes integrating with a larger test setup much more manageable."
"I’m wondering what is the best way to count edges/periods from Python. Is it possible to do with the Automation Script only or I should be using the Automation Script + a custom Analyzer that would count edges+time?"
I'd like to see an API where I can get data via a measurement extension, not just an HLA."
Hi Lane, I have created a High Level analyzer which opens a socket and streams data out (and accepts data) containing AnalyzerFrames.
I think the AnalyzerFrame and Measurements API are different so this might have to be done as a separate extension, but perhaps it would be possible to extend to cover measurements as well?
thank you very much for sharing, I tried it out and it looks really pretty good! And opens additional options!
I consider also to feed the data toward a Server with REST API, but that would have needed to import the "request" package, what is not in standard Saleae - Python packages.
The import via the workaround (sys-path, etc) failed, due to the further dependency on urllib3, that uses some special init steps, which are not covered by the Saleae package handling.
I will then retry with plain socket package, since you provided such an excellent example. :-)
Thanks for posting this! I added a comment for you in our idea post for automation:
Though, I didn't merge your idea entirely since it's technically not the same request, but instead, a feature add-on to automation.
Thanks Tim! I did not post it as a comment in the 2.x API thread as I would be happy if the functionality were available for 1.x--no need to wait for 2.x. Of course, extensions need to wait for 2.x (unless these are getting added to 1.x).
We would no longer extend functionality for the 1.x version. Instead, all updates related to automation would be specifically for the 2.x app.
I will need to wait for the 2.x API then. I will follow the thread on that. Any idea when that will be? I didn't see a projected release date. Please point me to this as I missed it. Thanks!
We unfortunately don't have a release date to share right now. We'll be sure to update the idea post for it as soon as we commit to one.