Logic 2.2.11

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.

Download Links

Join our forum and share your experience - captures and screen recordings are welcomed!

Join our Alpha Users Mailing List to be notified about the next release!

Bug fixes

  • Trim slider values were incorrect after trimming
  • Terminal was producing non-critical errors
  • Terminal failure was blocking users from re-capturing
  • Session termination failure
  • Memory leak in analog data
1 Like

@markgarrison just installed 2.2.11 and I can confirm that I’m now seeing all the lines of GPS capture I shared :+1:

1 Like

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.


Maybe we should start giving badges based on your longest capture duration :wink:

1 Like

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? :slight_smile: 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:

U64 AnalyzerResults::GetPacketContainingFrame( U64 frame_id )
    return 0;

All the packet related functions were stubbed to get it to compile, and I think when analyzers started working, it was forgotten as a TODO.

This breaks a number of analyzers.

1 Like

Long Delay after Pressing Start

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.

We’re looking into this. Looks like it’s related to some cleanup code. We’ll keep you posted.

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.

Capture in question:

1 Like

Click start to seeing sampled data seems to be substantially longer than with 2.2.9 and channel updates sometimes are staggered.

Not a major issue, but it feels like a regression.

Note: this is using a mixture of 10 digital and 4 analogue channels with 4 x Async Serial and 1 x I2C @ 100MHz and 6.25MHz.

Start delay is probably worse after a long previous capture.

Yup, @markp mentioned it earlier today. We found the bug (mainly on Windows), and we’ll release a fix on Thursday hopefully.

Thanks for letting us know!

1 Like

Hi @rani,

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.

Thanks a lot!

1 Like

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.

1 Like

We’ve never tested the app on Kubuntu, only on Ubuntu, therefore I’m not sure what the issue is. @markgarrison any ideas?

Thanks a lot!

the software can’t keep up with the stream of data

We’ll look into that. We haven’t optimized the glitch filter performance yet (sorry about that).

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 :blush:
Our plan is to use a single reference point for the entire app, including the trim dialog of course.

This apparently took about 26000 seconds

This is awesome! :fist_left:

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”