Saleae

Bus display and continuous trigger

Hi,

I have 2 feature request for the new interface

The first one is Bus display.
I often have to look at state machine and there is actually no convenient way of displaying them.
Maybe it could be interesting to split the signals that are display vs the one that are selected for capture.
So that you can select what you want to display and display them as stand alone signal or bus or even protocol decoder.

The second one is continuous trigger.
In one use case I have an heartbeat every minute and I’m interested by the last one that happen when my code crash. So instead of capturing the first heartbeat pulse with a One-time trigger, i will need a continuous trigger to re-trigger on each an so getting the last occurrence of it.
Bonus point if I can configure pre-trigger buffer duration and post-trigger duration independently.

Thanks

Hi Bear, thanks for the help!

Agreed. Both ‘protocol-only channel’ and ‘bus view’ are on the roadmap. This probably will change but they currently are on the board for Q1 2020.

Do you mean that you want to trigger on, and save a capture for every single heartbeat?

What do you think about recording in “Looping” mode - where the application continually holds on to the most recent N GB of data, and allows you to stop at any time, such as after you see a crash? Right now the Alpha software mostly works for this, although it’s hard-wired for a 2GB limit.

Thanks Bear!

No I don’t want to save every single heartbeat in independent capture but honestly it could be a nice feature so you can compare all the trace.

The fact is that with Looping capture it rely on me to be present in front of the software to stop.
And I’m trying to actually capture a crash that happen within a 2 to 8 hour window and we run it during the night so definitively I need to rely on the client software to keep the interesting point, cause else when i arrive in the morning everything would have disappear depending the buffer depth and when my issue arrive.
Something that works in a way that “if there is a trigger save it, and if there is already one discard it” would do the tricks for me

Ahh, I get it now - the application will have ‘stopped by itself’ by crashing, and you just want to have a trace of what happened just before and up to that point.

Super interesting situation - my first thought was that the pulse trigger could work, but it currently won’t…

I think a good solution could be to allow for a trigger ‘after no activity for X seconds’ or similar.

I’ve added this to the board. This is an important case, thanks!

Yes in my case it would do the tricks. :grinning:

But as you already have the pulse trigger it might be easy for you to just have a setting like :

  1. trigger on first pulse and stop
  2. Continuous trigger on pulse (always align to the last that happen)
  3. Trigger after X pulse (to get a particular one)

As you are thinking of bus display also bus trigger could be a point without going to complex trigger of big LA.

Good case, thanks.

Hum… This isn’t very compatible with the current architecture but is interesting to think about how it would work. Imo setting up multiple captures like this (where the latest one could, if it finishes on its own, overwrite the previous one) is something that we totally need to support via the upcoming automation API.

We will have a bus display; thinking about it now, the way we may implement it is as a “viewer” for a protocol analyzer - meaning that a ‘parallel’ protocol analyzer will convert multiple channels into a single bus value, and display it in the style of a bus view. This way we could use ‘trigger on protocol’ to implement such a trigger.

If we can make it super easy - then the best way for users to make crazy arbitrary triggers in the future might just be to write them in a few lines of code. Not sure!

Thanks Bear!