Will there be any utilities that can work on.sal files directly?
I’ve poked around with it and found that the binary files that are compressed inside are different than the binary files that are output by the export function.
Will there be any utilities that can work on.sal files directly?
I’ve poked around with it and found that the binary files that are compressed inside are different than the binary files that are output by the export function.
Hey @Scarzer. Unfortunately, we don’t have any plans to develop any utilities outside of our Logic 2 software to work with .sal files.
You’re right, the binary files are very different formats.
Is there any specific use case for preferring to work with .sal files directly over the standard export files?
I found the .sal file to be somewhat more convenient in being able to send around than a directory of binary files.
The ability to get an export of the binary data from the .sal without opening up Logic 2 is ultimately what I was trying to achieve. With the idea that I would receive a .sal from a colleague and be able to export and run a script on the output without having to leave my terminal. And then automating that process.
We are walking in the same boot. It is PITA that sal files format is not documented.
I personally would not need any utility to be provided. Just a format description.
In the old times somewhere there were some mentions that the data there is serialized with boost and it depends on a lot of things (sample rate, etc.) so documenting it would not be straightforward.
+1 for any kind of documentation on the .sal format to minimize the amount of GUI interaction needed for automated captures.
This request seems to be more needed than we initially thought. I just created an idea post below:
Please vote and comment to help with getting this on our roadmap.
I understand it’s not really a “feature” per say, just really a documentation exercise. Nonetheless, still requires cycles from the team, and therefore a roadmap evaluation before committing to it.
Hiya, I was wondering if there was any updates on being able to interact with .sal files without opening up the GUI.
Some documentation or any sort of path to be able to export to CSV or binary without opening up the GUI.
@Scarzer No updates as of yet, and this is not officially on the roadmap. We’re still tracking the idea I’ve posted here before we commit to it. Please add your votes/comments to it as it may help us with prioritization!
Just throwing out an idea.
Maybe once simulation mode finally gets supported by V2 there might be a path forward for users to develop their own solution for this. Users could export their captures from V1 to a specified file format (V1 SDK allowed for plugins to define their own Export options, something that I think is still missing in V2) and then create a plugin (or maybe an HLA) that reads in the file and reproduces the waveforms using simulation mode.
Of course there are plenty of complications to this approach, but maybe this would be sufficient for those asking for such a migration path. This approach might be more inline with Saleae protecting IP and reducing scope. Users would have the option to develop as complex of a migration tool as they see fit.
SAL file looks to be ZIP file. it cointains separate Bin file for each channel + json file with metadata. Bin file format is described here: Binary Export Format - Logic 2 - Saleae Support
The bin files in the *.sal archive are not the same as the exported binary format documented at that link.
We do provide a python example for working with the exported binary files, which are definitely the best way to work with recorded data outside of the software.
The *.sal bin files contain the original data, but they also include a significant amount of pre-computed metadata specifically for accelerating rendering and other operations. It’s very application specific.
Hi
I have a use case really similar to the one described here. I’d like to convert binaries files back into the .sal binary format in order to re-open the capture on Logic2. Having a bit of detail on how the .sal bin file is actually formatted would be really helpful to do that.
The point here is actually to stay in the very nice Saleae environment to do my work and not have to use other tools. The work I’m doing implies comparing captures taken with my Saleae 16 pro , with capture taken with another hardware. I’d love to import external binaries to use the power of Saleae analysers on it too.
Thanks @udepyp! I just added a comment and vote for you in the idea post that you shared.
Hi, there
I have a very similar case. I would like to write a converter in order to translate the .sal files into my analysis software. I do not want to open the software to export csv or binaries. I personally think both hardware and software are really great - but I would like to use more specific analysis-software, so I need to convert the data.
It took me almost one day to realize that the format of the exported binary and the binary in the zip file differs. Nervertheless, after a couple of hours I am able to decode the analog-file from the .sal. If this is a wish, I can share information about this.
Unfortunately, I’m really not able to decode the digital file. And I really to not understand why there is no documentation available (@Saleae: Is it really programmed in such an ugly way that you do not want to share it? )
Hope that somebody can give me a hint? or can look in it too?
I’m guessing that (due to the space reduction in the binary from the zip) that there are no timestamps saved, but time differences. Further reductions might be achieved by saving n from n/samplerate (so you are saving integers instead of floats), but I was not able to find any relations
If @SALEAE does not want to share this info: Maybe you can write a small exe for .sal-into-.bin translation, so that we do not have to open logic2?? Even better would be a small API - provide a library with that stuff. Would be great if one can run the logic analysers in that api too
Georg
Hi Georg,
Thanks for sharing your situation!
The reason we don’t want to publish an official format for our *.sal file contents is because then we’ll need to commit to keeping that documentation up to date, and ideally avoid making breaking changes to the format, in case it breaks 3rd party integrations. For example, the old save format of the Logic 1.x software went through 24 serialization changes over the life of that application, including several complete overhauls of the format. (The very first version used XML files, and would base-64 encode the data. it took forever)
Instead, we want to do exactly what you mentioned - provide a .sal-into-.bin translation, through a API of Logic 2. This way, we can change our internal file format to our hearts content without needing to make a public API & documentation release each time we do that.
We’re collecting , reviewing, and organizing user feedback on API needs now, and I recommend adding any suggestions you have to the ideas post here: Application / Automation API - Logic 2 - Ideas and Feature Requests - Saleae
That said, this use case is very core and will be supported well.
If you’re interested in getting digital or analog data back into the Saleae software, please support that feature request by adding your use case in the comments here: Provide a method to import external data into Saleae logs - Logic 2 - Ideas and Feature Requests - Saleae
I do have a quick question - how many save files are you trying to convert? Could you tell us a little bit more about your use case?
Hi,
sorry for my late reply.
In my case we have connected the saleae-device to an automized industry-machine, because we would like to acquire more data from then machine than it is provided currently by the hardware of the supplier (Digital and Analog Signals). Currently we can start and stop a sequence only manually. We have many succeeding processes and they are all stored one after each other. So we need to seperate the data into these blocks in our later analysis. In details we need a more detailed analysis in order to do statistical analysis of these individual processes.
My wishlist for Saleae:
Oh your question. We are doing roughly 50000 processes (each ~1-2s) per day (6.25MS/s digital, 1.25kS/s analog). Currently we are only storing on demand (for debugging) some sequences of 10min in total.
1st priority wish: Provide a DLL with the file-IO, so that I can load a sal-file and access it channel-by channel for digtal and analog. (Similar to what you are doing for the analysers). I can also offer my help here!
Georg