Bus display and continuous trigger


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.


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!

Any progress on the continuous trigger idea? I would like it too. I need to observe jitter in a periodic pulse, and this would be much easier if the Saleae would just continuously trigger on the same falling edge, and update the view accordingly, like an oscilloscope. It would only need to record [window width] of data and stream that small buffer to the PC, repeatedly. On a Saleae with USB3 this would not be a problem I suppose. I can do something similar on my SmartScope, even with USB2.

I know this is more of an oscilloscope feature than a logic analyzer feature, but I guess the Saleae is a mix already anyway, with its analogue channels, and it would be very nice not to need an additional instrument on my desk.

Although we’ve added Trigger View for protocol analyzers since then, we don’t have any updates yet for repeated triggers on edges.

Screen Shot 2020-10-02 at 3.31.08 PM

We’re currently tracking user interest for continuous triggers in edges in the ideas post below before officially committing it to the roadmap.

Feel free to vote/comment on it!

1 Like

I would definitely be interested in this! I was busy searching if there was a way of doing this when I found this thread.

1 Like

@nickantoniades11 Thanks for letting me know! We don’t have any updates on this yet unfortunately, but I did get your vote added in the idea post I shared previously.

Awesome, thanks for that. Otherwise, this is a great product, I am really enjoying using it.

Any update any plan ?

Hi Bear,

The continuous trigger is on the roadmap, but we haven’t started development on it and I don’t want to give an estimate now, since things can change between then and now. I’m really excited about it.

We don’t have bus display on the roadmap at the moment. I posted more feedback in a reply to your other comment.