Implement better view for decoded protocols


The decoded protocols area is really neat but it's HARD to read. One value per line is really nasty when the protocol is async serial and forms words. Another example is canbus. The traditional view would be for all data bytes to be on the same line so it is easy to see them all at once. I'd like to see the decoded protocol area better format the output based on which protocol is being decoded.

This might be problematic because it seems as if all of the registered protocol handlers dump their output into the same window in time correlated order. That's a really, really odd choice. Each channel should have it's own decoded protocol area to the right of the channel so that each one has a nice view of only that protocol / channel.


Activity Newest / Oldest



RobN Jul 11, 2018
I ended up saving the protocol output to a CSV file, converting that to *.xlsm (Excel with macros), and writing a simple macro to convert the USB data so that everything from the SYNC to EOP is on one line, and just save the start and end times for that group of messages. It was about 30 lines of code.

IPD Jul 11, 2018
I would also agree that better views would be nice.

For I2C - a tree (+/-) view would be useful.
Every Start event could be a new level and then every transaction up to the next start or stop would be at that level and could be expanded / collapsed.
This would make examining the starting transaction the highlight and then expand to see what was under if needed / interested in that transaction.

Also, it would be nice if the Decoded Protocols could be popped out / undocked / new windowed. So it could be viewed separately and resized.

Then filters on the starting transactions could be applied to see the summary of transactions to a particular device in a nice compact form.

AJG Jul 11, 2018
An example of how protocol decoding could be displayed better:

Jan Kok Jul 11, 2018
Strongly agree! The Logic UI is awesome when looking at _signals_ on the scope-like display, for debugging low-level drivers, making sure chip select and interrupt lines are working properly and so on.
BUT, when working at a higher level, when you want to look at the _data_ that is read and written to a device, the Logic UI is hard to use. That's why my Logic has been sitting on a shelf for many months, and I've been using a dedicated I2C/SPI analyzer from another manufacturer. They have a spreadsheet-like full screen display that shows one transaction per line. Each line shows the start time, the duration of the transaction, the number of bytes transferred, and the first 12 bytes transferred. Clicking on a line causes all of the bytes transferred in the transaction to be displayed in another pane. It's so much easier to understand what's going on at a high level when looking at that sort of one line per transaction display.
What I would suggest for Logic is that clicking on a button on an analyzer should bring up a separate window with a spreadsheet-like display such as described above.
If Saleae could implement that feature, Logic would be even more usable and versatile than the competing product. One serious limitation of the competing product is that it only looks at MOSI, MISO, CLK and CS lines. It can't show other signals, such as an interrupt line coming out of a SPI peripheral. If we can't see the interrupt line, and the system that we're debugging hangs, we can't tell if the peripheral failed to assert interrupt, or if the MCU is ignoring the interrupt. So, being able to view other signal lines along with the SPI bus data would be very useful.
A couple of other ideas to consider along with this one:
* Make it easy for users to write their own analyzers. For example, it would be extremely useful to be able to decode and display transactions in a high-level fashion, as commands and meaningfully formatted data, rather than just a line of hex bytes.
* Make it easy to compare traces collected at different times, and highlight the differences. (Also need to be able to mask out unimportant differences, such as times and sequence numbers, so those differences aren't highlighted.) That would make it easier to compare good and bad traces and track down the cause of the differences.
* Some other suggestions have mentioned wireshark. I'm not familiar with it, but from a brief web search, it looks like it might be useful for analyzing and even comparing bus transactions.

Joris Jul 11, 2018
I agree, that this is super awesome but could be improved.
For example for SPI mode, it would be great to somehow indicate which bytes are sent during the same chip-select session.

Mohan M Aug 25, 2019
A couple of basic features that are missing:

1) The decoded protocols window must be resizable. I consider this a really basic feature which should have been there from the get go.

2) Clicking on an item in the decoded protocols windows brings up the section of the IO capture. But it should work vice-versa also. That is, clicking on the decoded protocol should go to the corresponding item in the decoded protocols window. This really helps in walking through the capture.

We have taken the time to implement a custom protocol analyzer. But these two features are holding back convenience and efficiency. I hope Saleae will enable the above two features to make Saleae a better tool. Knowing that Saleae is well supported is important to our company; the more convenient it is to use the more users in our company will order and use Saleae analyzers.

Joe Garrison Sep 4, 2019
Hi Mohan, thanks very much for the improvement items. Both of these should make it into the Alpha fy the end of this month (September). The Alpha isn't 100% ready for prime-time use yet, but will be in the next couple of months. discuss.saleae.com

Mohan M Nov 7, 2019
Hi! Have these ideas been incorporated into any builds yet? I'm specifically looking for these 2 features:

1) The decoded protocols window must be resizable. I consider this a really basic feature which should have been there from the get go.

2) Clicking on an item in the decoded protocols windows brings up the section of the IO capture. But it should work vice-versa also.

Tim Reyes Nov 12, 2019
Hi Mohan, sorry for the delay with these features. #1 is available now in the latest Alpha release below (Alpha 12):

As for #2, this is still on the roadmap. We plan to have this ready in a future Alpha release, perhaps Alpha 14 or 15.