This is a minor update due to a critical bug on Windows that was blocking users from re-capturing again in some scenarios. We are deeply sorry about that.
Note: Analyzers’ data table currently supports only Async Serial, I2C and SPI. We’ll add the rest of the analyzers soon.
This is much more than a minor update (for me) - this has completely fixed the “If you let it run long enough it will hang” problem I’ve been having for a while now. I let it run for 10+ hours (analog and digital capture, in trigger mode) and nary a hiccup or slowdown. AWESOME JOB!!! This is absolutely huge - we can now let Logic 2.2.11 run for days (hopefully) watching for a very rare event. Thank you thank you.
Is the “Packet ID” field completely gone from the SPI analyzer in Logic 2? It seems to be set to 0 for all rows when exporting as Text/CSV, it doesn’t show up in the GUI, and it’s not available for use by high-level analyzers. If so, could we have it back? Otherwise it’s not possible to discern between SPI transactions.
Sorry about that, it’s a high priority on our bug list. In our rush to re-implement the analyzer SDK in the new codebase, this happened, and was then forgotten:
Maybe it’s just me, but I’m noticing a significant delay after I press start, and when the capture actually starts. It is on the order of 2-7 seconds from the time I press start, until the capture begins.
I noticed this because I was all set to capture an event after hitting a breakpoint in the debugger. I hit the start button, then continued execution in the debugger. The Logic had not started by the time the firmware had passed up the point I was hoping to capture - by a lot.
I also found I was clicking on the green start arrow multiple times thinking I was missing it somehow. I wasn’t, it was the delay problem.
This is very repeatable with some Start events taking longer than others.
I used the 1.2.29 version of the software then closed that and tried to load this newest 2.2.11. It said it could not connect to the Logic 8 Pro. I tried many times, it would not work. Then I closed 2.2.11 and tried 2.2.10 and it also said it didn’t connect… but it did. And I could use it.
This is linux on Kubuntu 19.10. Logic 1.2.29 works fine, 2.2.10 would work but said it didn’t. 2.2.11 seems not to work at all. It could be a permissions issue… maybe? But, 1.2.29 works fine. I haven’t gone out of my way to exhaustively test the variables to see if I could find a definite pattern. One thing that was different between 2.2.10 and 2.2.11 is that I unarchived the 2.2.10 version and was running it outside of the appimage file. 2.2.11 was being run directly from the appimage.
So far 2.2.11 is much much better. I am able to run my custom analyzer and it works through a long capture. Captures can run for long periods of time waiting for a trigger without issue.
I am still having the issue where I save a capture and am unable to open the capture file. It will open just fine on my co-workers ubuntu but on my manjaro install it does not open.
Great job with the new version. I’ve finally switch to the alpha release and while most things work great when I enable the option to filter glitches of up to xx samples the software can’t keep up with the stream of data. In order to make it work I have to drop the sampling rate to 50 MS/s which in my projects is not enough. Once I dissable the filter glitches option the software can keep up with the max sample rate. Hope you guys can improve that part soon.
I was able to let Saleae logic capture for a really long time while waiting for a trigger. This apparently took about 26000 seconds.
When the capture is done and I go to trim the data it is quite difficult since the times listed above the signal traces do not match the times listed in the trim window. It appears the the trim window uses all time that elapsed since the recording started and the timeline above the signals is relative to the trigger.
Could the Trim Data window utilize the same time line shown above the signals?
It would be super nice If I could type:
Start Time: -5 sec End Time: +1 sec
and have it work.
Could the Trim Data window utilize the same time line shown above the signals?
Yes. As some of you mentioned, our timing formats are a bit of a mess at the moment
Our plan is to use a single reference point for the entire app, including the trim dialog of course.
Another way to do it is to add a timing marker pair (Ctrl+T) at the edges where you want to cut, then in the “Annotation” -> “Timing Markers” tab, right click the measurement and “Trim to Range”
Otherwise it’s not possible to discern between SPI transactions.
