Alpha 12

It’s probably it. Take the img above. Suppose I edit it and cut the channel 2 graph (spi clock) with the little arrows indicating the clock phase and paste it right below where’s written Channel 2, in a way that the graph overlaps with the channel name box. That’s the issue.

Technically none of the above. It happens when I maximize it, close and open Logic again. Apparently it remembers that the last time it was maximized, and it tries to open itself the same way, there you have it.

Btw, what about the colored channels?

I’ll try reproducing the error. That’s super helpful, thanks!

What about colored channels? :slight_smile:
There are colors next to the channel label (a vertical line). What am I missing here?

Try Logic 1.2.29 beta and you’ll immediately notice it. The lines in white in the img. I posted are colored in that version on top of the the vertical line you’re talking about.

Thanks for the feedback! I’m not 100% clear on what you’re referring to.

In the 1.2.29 Beta, there are two places where you see the channel color:

  1. the vertical bar on the right of the channel label.
  2. the digital traces themselves are colored, if enabled in the settings.

In case #1, we have the same style in the new application, but the vertical color bar is narrower:

Pictured: Left: alpha software. Center: 1.2.29, default trace coloring. Right: 1.2.29, with trace color enabled in the options

Are you asking us to bring back the option to colorize the traces? Or just make the vertical color bar wider? or something else?


I tried to follow your steps on Ubuntu 16 and it seems to work fine. We’ll give it a try on Ubuntu 19 as well and we’ll keep an eye on it.
Linux distros are always a challenge :slight_smile:

Please provide icons (.png) so I can make great shortcuts.
Also; the white squircle is not very neat for linux, probably nor mac , because of expectation of transparent background.

So please provide squircle-less/transparent version.

Please improve the way decoded data is displayed. Once I zoom out, they fade really quickly.
the 2x 4x etc zoom setting of current release is not even affecting the vertical size of the data.
please use more height for a narrower, higher font, and/or alternating positions like this:

0x00    0x34    0xAB    0x02    0x59    0xFB
    0xA3    0x39    0xFF    0x00    0x73    0x2B

and/or handle consecutive bytes better and display like longer strings:
23,AD,12,54,2D(hex) or 23,AD,12,54,2D(hex)

whenever ve look at such data, we do know what we are looking for/at , and repeating “0x” does not help that much as we do not expect mixed radix except when selected.

1 Like


I’m using Kubuntu 19.10

1 Like

This is a good way to optimise screen space on decoders. Vertical values for hex and ASCII.


@rani : please see comments/suggestions above ^

Thanks for the reminder (and sorry about the delay) :slight_smile:

Please provide icons (.png) so I can make great shortcuts.
Also; the white squircle is not very neat for linux, probably nor mac , because of expectation of transparent background.

I’ll ask our designer. It shouldn’t be a problem.

Please improve the way decoded data is displayed.

You’re right, but unfortunately, we’re currently using our old analyzers and there isn’t much we can do with their output. However, we are working on the next version of analyzers (and high-level analyzers) and that problem should be solved as part of it. By the way, if you hover over a result, it’ll open a tooltip with the decoded data. I know that it’s not what you want, but maybe it’s still helpful :slight_smile:

Sorry for the late response. Interesting idea.
I’m not a fan of this design tbh, we should (and we will :slight_smile:) come up with a better solution for that.

I’d love to learn more about your use case. When and why do you want to view the trace in a zoomed-out mode but still be able to read the protocol results data? Why is it better than using the sidebar table for example?

Thanks for the feedback and the idea!

My searches are now for I2C Write , (all I can predict is the Write and address), hence, I search for it, but to discover & verify, it is of no use to zoom inn all the way onto the request address I searched for.
What is needed then, (when clicking on such search result) are the following bytes and ACS/NACS.

I hope you better understand the use case.
Searches are most likely to be for a place in time, not to review this one byte. The following bytes are often most important.

I may need to search for this address 20 times, because I wish to verify response one particular (of the 20 possible) command-bytes after the address.
Of course, this could be accomplished by being able to search for two consecutive bytes, but still, even then, the main focus would be the following (or preceding) data, not close inspection of those two bytes.

I hope this describes better my case.

I think that I understand better now. It’d be helpful if you could share a screenshot :pray:
We’re planning a couple of things that could be helpful:

  1. Scrolling to a protocol result in the data table by clicking on it on the graph. We might also add an option to auto-scroll the table as you move the graph (TBD).
  2. “Show context” button in protocols results table that will show the results before and after the selected row (i.e. clear the filter but keep that row “centered”).
  3. High-level analyzers - in your case, you’d be able to rename the address field and change its color. This way, you can easily find the relevant frames.

What do you think?

This is the .png version of the icon.
Unfortunately, I don’t have a transparent version, however, it won’t be too hard to remove the background if you want to :slight_smile:

Sounds great, especially the high-level analyzer, even I do not know how easy&powerful it will be :slight_smile:

You asked for a screenshot, here is a screenrecording of the current workflow.
Another idea I had that would simplify search would be to still show all data, but change background color of matched lines.

Also, this thered: How to look up in "decoded protocols" contain some discussion about this topic.

1 Like

If we’ll do our job well, they will be easy&powerful :wink:

Thanks for sharing the screen recording, it’s really helpful!
We’d love to have more of this, as it gives us a better understanding of your workflow. We’ll start asking our users to share similar videos with us.