Trigger on Both Rising and Falling

is there any way to trigger on falling and rising edges I do have a toggling GPIO to indicate change, while my oscilloscope can catch all events, the Saleae can not because it can only react on ether falling or rising _ it is though very common to trigger also on both. Instead there is the Pulse it is good thing for bus starting tact, but not so much for indicator signals.

@a.scheunemann Thanks for writing in! This is unfortunately not possible, however, it has been requested quite a few times, so we’re aware of the need, and your use case absolutely makes sense! We’re tracking all requests for more triggering options (including this one) in the idea post below.

I’ve added a comment for you to track your need for this as well.

1 Like

Just a quick follow-up suggestion on this –

If the Analyzer SDK were updated to allow it to trigger the capture (LLA and HLA), then you could trigger on almost any condition(s) programmatically. As long as the analyzer was able to keep up close enough with the streaming data, the capture buffer could retroactively mark the trigger time based on whatever edge/sample the analyzer marked as the trigger point.

Extending this concept, the Analyzer SDK could also allow you to set timing markers so you could track multiple trigger points (or any other interesting points) thereafter – allowing a fast ‘search’ and/or navigation jump to the time of each marker placed by an analyzer. As long as the API allows you to label the marker (set the note string), then you could also easily add custom ‘tags’ at useful points in the timeline, too.

Ultimately, exposing & mapping more of the various internal control/event/UI primitives to the various APIs would add support for more use cases w/o needing to implement them all directly in the software. These features could be helpful at different levels – in the analyzer SDKs (LLA, HLA), in the automation API, and even in a new interactive API (i.e., add a new scripting engine to control/automate the UI? Reuse/extend the HLA python capabilities with an interactive console/shell window?)

interesting yes I was thinking also to just do all the work in capture after recording but it become heavy files. sure absolutely possibel. I know you suggest to extend the API for all that and seems a large set of feature from your idea.

setting markers based on patterns could be interesting too, I can see that.

My concern though is with the fundamental both edge trigger that should be a option in any trigger. Nearly all measurement equipment that I ever head on my desk hat the 3: pos. neg. and both edges but the Saleae has not.

I respect your creativity but I would like to point this particular lag out which can not be that big of a deal to implement.

Hi @a.scheunemann

For triggering on both edges, I agree that it should be implemented as a supported feature directly without needing an extra API. However, it currently is not implemented. I think there are many ‘should be easy to add’ features that have not (yet) been added, so that is why I suggested that Saleae could extend their API ecosystem for more DIY support and make it easier to just add it yourself, if you can’t wait until Saleae has the capacity/priority to add it for you.

Meanwhile, you can change your debug signal from using a 1x toggle to 2x toggle, and then you can trigger on a single polarized edge (as long as the back-to-back toggles are greater than the minimum sample period apart). Otherwise, toggle/set on event, and clear periodically in a background/idle task … I know this is not as ideal as having a ‘both edge’ trigger, but it might work for you until that is implemented.

Otherwise, one of my favorite things about Saleae is the huge capture buffer capacity. If the thing you’re looking for happens within seconds/minutes, you can just do a manual start/stop capture and record everything (Looping Mode instead of Trigger Mode with a big enough buffer). Then:

  • use the ‘detect edge’ feature to find your ‘trigger’
  • use delete before/after this point to crop the capture as desired
  • Save the trimmed results

Pro: you see everything, including earlier events you might have missed in a ‘trigger’ and supported now
Con: more manual effort, and not as easy to automate as having the dual edge trigger feature.

I used to use my Saleae like I used my scope, and missed all the advanced triggering mechanisms that my scope had. Once I got used to using it as a massive data capture tool, I didn’t miss the triggering mechanisms as much (especially for digital only captures): capture everything, then just post process & trim as needed. Now I miss the big capture buffer when I go back to my scope, as I fight to tune my triggers & repeat tests just so I can actually get the right snapshot captured.

thanks for your elaboration. In my case I have many small captures each a different experiments and in this case I am very interested in timing trigger signals not so much in decoding. that’s how this came up. I will see how it effects the more special cases in my verification set and come back to your suggestions. Meaning I will not implement them now …need to get some report done have found my way to work around it - much more lame but gets the job done for now.

But please Saleae team add the both edges trigger we here will not be alone with this need.

:rabbit_face: