HLA: support Python dependencies

Jonathan Gjertsen

Support using external Python dependencies in HLAs. Alternatively, support using a different Python executable from an environment controlled by the user.

Originally posted here discuss.saleae.com/t/third-party-libraries-with-hlas where the package of interest was protobuf.

Personally I would like to use Construct (for struct parsing) and scipy (to run curve fitting on analog data)


Activity Newest / Oldest


My script uses it's own Python dependencies.
It injects them via

Works for me, with Logic 2.3.23.


Michael Leonard

Hi everyone, not exactly meeting the requirements posted here, but it may be a feasible workaround for some of you. I have implemented a HLA that opens a socket to transfer and receive AnalyzerFrame data.

You can use this to live stream data out of Saleae, analyze it in any external tool that can talk to sockets (Python included of course), and pass that data back to Saleae to embed into the log.

It does unfortunately mean you need to have a separate 'client' software running alongside Saleae to receive and respond to the data, but if that's not a problem for your use case this seems to work well and would let you use whatever Python dependencies you want.

You can find the extension on the Saleae Marketplace as "Socket Transport" and the source code is here: github.com/LeonardMH/SaleaeSocketTransportHLA

  • J


Same here, I actually am scratching my head how to use this really cool functionality you guys built without any external dependencies. In my case, I need to read a (C) header file and use it to decode the data on the bus. Would be real easy if I could use the packages we already use for this.



This would make extensions a lot more powerful. I like the idea of specifying dependencies in the JSON configuration file. The format can be similar to the PEP standard, e.g.., numpy~=1.16, pandas>=1.0, etc. Or specifying a different Python venv to use works too...

  • R


I strongly agree! In fact I specifically need the Construct module as well. This would make it much easier to re-use existing packet parsers and parsing code in HLAs.