I loved 1.x. It’s the reason I was getting all of my customers to buy Saleae devices. But the 2.x experience has left something to be desired.
Besides getting used to UI which, coming from 1.x, is less intuitive; I’ve got some nits.
(Ubuntu 20.04).
-
Everytime I start it up, I get the annoying notification telling me to install udev rules that are already present (after previously following the instructions). So I have to dismiss the notification every…single…time I start up Logic… I already have notification fatigue; I don’t need it from my test equipment. My Logic16 is found no problem.
-
How do I change the default filename when I export to CSV? It seems to be forced to be “digital.csv”. If I’m creating a series of tests, I want to just edit a dialogue instead of having to drop into my filesystem browser (or shell) to rename digital.csv to something else before going back to hit the export button.
Thanks for the feedback! I’ll address the first item now. The second we’ll need to review with Neel and Tim to discuss, and we’ll likely have follow up questions.
The logic 2.x software explicitly checks to see if our rules file is present, and if it’s not, it shows that notification.
The software isn’t very smart about it, it blindly checks to see if /etc/udev/rules.d/99-SaleaeLogic.rules exists. If it doesn’t, it shows that notification.
Seems like we might be able to replace that with an actual udev test command, we’ll need to look into it.
Could you send us the full path, including the file name, to the udev rules file you installed? I’m curious if it’s in a different directory, has a different file name, or if our existence check is failing for some reason.
Well, I feel pretty dumb now.
[hpeyerl@e7470 /etc/udev/rules.d]
$ ls -ald 99-SaeleaeLogic.rules
-rw-r--r-- 1 root root 866 Aug 6 2021 99-SaeleaeLogic.rules
[hpeyerl@e7470 /etc/udev/rules.d]
$ pwd
/etc/udev/rules.d
Fixed. Sorry.
Glad it was an easy fix. I was worried there was a new udev rules path now, or that somehow our app didn’t have permissions to check for the file’s existance.
About the export file name. We’ll be reviewing that feedback internally, but some quick background about why it works that way now. When exporting both analog and digital data at the same time to CSV, we create 2 csv files, named analog and digital, because there isn’t a good way to mix the data in one file, since we use different sample rates for each.
The original idea is that the process would automatically create a new folder with the user selected name, but the folder would always contain the same file names.
Later, we changed the folder selection process so users could directly select the folder where the files will go, rather than select the folder that will contain the new folder created by export. However, it’s not a great solution.
Understood. Maybe “foo_analog.csv” and “foo_digital.csv” instead of creating a folder?
Anyway, I’m not a UX person so who knows.
Thanks.
3 Likes
A better and still light weight solution is to get a name from the user then append _d and _a (or something else if that it too cryptic) to the user supplied name.
Edit: Bah, didn’t scroll down far enough before replying! Must be the obvious solution
2 Likes
@P.Jaquiery @hpeyerl We’re discussing internally about how we might want to solve the export file naming issue that your brought up.
Assuming that you would like to keep all your export files in a single folder (all named differently), can you share some examples as to what kind of captures you are taking, what relevant information each export file contains, and what you do with the export files afterwards?
In short, we would like to get an idea of some typical workflows that involve exporting data, which could help guide us towards the best way to solve this.
In my case, I was doing some post-processing of various DVT scenarios.
- Reset the target
- Start a capture
- Launch a python script
- Wait for script to exit
- Stop capture,
- export CSV
Repeat above with different arguments to our test scripts. Then take the CSVs and drop them into a spreadsheet or post-process using python/matplotlib. It would be nice to name the export according to the arguments of my test script. That’s what I ended up doing; I’d alt-tab switch to my terminal window and 'mv digital.csv foo-test_200hz_6ms_10k"
Now that I see this: GitHub - saleae/python-saleae-cli: basic command line utility to automate the Saleae Logic software using the ppannuto python-saleae library
I realize that would probably be a better way to deal with my situation.
1 Like
For Logic this is a very occasional thing for me, but with other software it is a major feature. The best context (but not the best software) I can think of is Sky X which I use to manage an astronomical camera on a telescope. There I frequently want to capture a series of images, often with changes to the filter used between images. The naming issue is solved by having a base name and allowing parameters in the name, then following the whole lot by an incrementing serial number.
Come back to me when you are ready to brainstorm the way parameters might be handled.
1 Like
@hpeyerl
Thanks! I’ve added some notes with regards to your request in 2 different feature request posts. I’ll relay your notes back to our product team as well.
By the way, thanks for detailing your workflow. That makes a lot of sense why you would want to name export files a certain way on every export. If we could add the ability for export file naming with the snap of a finger, I’m sure our entire team would be all for it.
@P.Jaquiery
Thanks, and will do! I recall you bringing this request up some time ago as well (at least if my memory serves me correct). I’ve taken note of your comment in the “file-selection-for-export” feature request above. Both your use cases and workflows seem similar to several others who have requested this feature.
Further to my scenario above, we were discussing some variation in oscillators that we were seeing after a manufacturing run. I suggested the idea of incorporating a Saleae Logic unit onto our bed of nails fixture and capturing our clk for a short period of time under various test conditions in an automated (python) fashion, then post-processing and recording min/max/mean in our PVT dB. I didn’t realize (until reading this thread) that the python-saleae library was limited to 1.x and not available on 2.x.
1 Like