General comments/questions on Logic MSO

Hi all, I have been using the Logic MSO for a bit over a month now and have some comments/ideas I’d like to share.

  • I know there is supposedly going to be proper math-channel support added in the future; one thing I feel may complement the use-case of two channels acting as a differential-pair would be to designate them as such in the GUI and have matched/linked controls of the signals (i.e. if one is changed in scaling/offset also scale/offset the other to match). A special symbol in the waveform tabs/info-bar could help indicate this mode is active on the channel and perhaps color-code to show which channel it is linked with.
  • In a similar mindset and just a general quality-of-life feature I personally would appreciate is an option to “lock” the scroll-wheel and mouse adjustments in the waveform view on making vertical scale/offset adjustments. I have many times accidentally changed a channel’s scaling by careless hovering over the voltage-scale (the translucent bars) and intending to use the scroll wheel to zoom in but instead causing the scaling to change. Or accidently intending to pan the waveforms horizontally, but moving up/down and changing the offset. A lock function that prevents manipulation of these seems sensible to me (I know about the “Fixed Range” function, and this is a great feature, but fills a different and probably more important need in general). (Or maybe key-binding reconfiguration would also solve this)
  • Are there plans to support the MSO using the other Logic2 API? Or plans on the MSO API to support a case where you want to keep the Logic software open so that you may continue to interact/adjust the settings there and have a simple way for scripts to trigger an export process to grab the MSO data for post processing?
    • Maybe this functionality already exists, and I have not dug into the APIs sufficiently yet.

Possible bugs

  • This might already be well known, but I have seen what seems to be rogue/runaway memory usage in the logic analyzer decoding. This may be due to the logic analyzer plugins that may fall behind on processing data, but the analog waveforms already reached the memory limits. If this is what is happening, I am wondering if there could be a dual memory/pool limit defined, one specifically for analog waveform data and one for the logic analyzer decodes. Anyways it’s not a huge issue, but it does happen frequently enough, that I hope Saleae is already working on solutions/thinking about the best way to handle whatever is going on here.
  • I have been playing around with the MSO API and one thing I noticed is that there seems to be an incompatibility between using the “mso_api.Capture.from_dir()” on a binary-capture that was saved manually via the GUI. It seems like a trivial bug where all I need to do is rename the expected files to remove any prefix in the filename that the GUI enforces (obviously the MSO API should probably support the user-specified filename prefixes). For example, if I click Menu->File->“Export Raw Data”, and click “Binary”, and then “Export”, it requests a filename (base name of the file). If I enter “a”, then this produces files such as: “a_analog_0.bin”, “a_analog_1.bin”. If I then try to load these files using the “mso_api.Capture.from_dir()” it will fail to load. Renaming these to “analog_0.bin”, “analog_1.bin” and everything works just fine.

@Jonathan Thanks for sharing all of your feedback with us! I’ll take a closer look at each bullet point with the rest of the team here and we’ll share our updates with you soon.

Hi @Jonathan, Thanks for all the feedback! There is a lot in here, but I wanted to reply to a few things now.

First, we’re working on a lock feature right now for vertical and horizontal settings, although it might not be what you’re looking for specifically. We’re also adding a viewstate undo button, which might just be what you need to quickly fix accidental viewstate changes after their made.

The lock feature is focusing in on locking down the capture parameters. For example, today, the sample rate and buffer length of MSO, when in trigger mode, are derived from the screen coordinates. (for example, if you’re looking at a range of time from -1ms to +5ms, that is the buffer size we’ll use. We’ll also select a sample rate based on this for you, although that can be overridden today). This lock feature will basically decouple this, so you can zoom and pan the display without the sample rate or buffer length changing on you. This is handy for cases where it’s important you capture a long, high frequency burst of activity in its entirety, while allowing you to zoom and pan around without tossing your acquisition settings out the window. We’re planning on offering independent locks for vertical and horizontal.
This doesn’t lock your ability to zoom or pan the display though.

Regarding viewstate undo, this is a great general feature for just backing out the last viewstate changes you made. I find it especially handy for these typical situations:

  1. I mess up using the marquee zoom and end up looking at the wrong thing. (We need to improve the marquee zoom system too)
  2. I am zoomed out, I see something interesting, so I zoom in, then I can just use the back button to get back to my prior view quickly and accurately.
  3. I accidentally do the wrong thing. (my mouse is easy to accidentally horizontally scroll, so the undo feature is quick to back this out)

It’s pretty similar to the navigate back button in code editors, where it doesn’t actually undo anything, but it just moves you back to whatever you were looking at earlier. It will use the standard browser keyboard shortcuts for navigation, and it’s also bound to the forward & back buttons on your mouse if you have those (which I find quite handy)

We have looked at more aggressive scroll locking in the past, although I find that if I need to activate a feature to prevent me from making a mistake, then I’ll still end up forgetting to activate the feature first.

Do you think this may address your issue?

We have a lot of quality of life improvements in the works right now.

Regarding the Logic MSO API, yes, I do want to merge that into the existing Logic 2 API, and continue to invest in it. Our current goal however is trying to improve the core Logic MSO user experiences based on user feedback and internal testing. We have a long way to go before we’re satisfied with it.

Hi Mark,
Thanks for the response.

The undo + vert/horz lock sound good enough to me (the diff-pair assignment would be neat though, but certainly not a high-importance feature).

This lock feature will basically decouple this, so you can zoom and pan the display without the sample rate or buffer length changing on you.

  • Awesome news! Definitely a feature that helps with QOL.

Do you think this may address your issue?

  • Yes, I will be a pretty happy camper with these.