Trigger functionality

I love the trigger functionality you added!

Is there going to be:

  • stop / single trigger?
  • force trigger?
  • a display for time since last trigger event? Maybe also an equivalent of the oscilloscope LED that blinks upon trigger event?
  • complex trigger conditions

I think that connecting several channels to a single channel’s trigger event is a must. It’s much more useful than the ability to trigger different channels independently. If I had to choose, I would prefer a single trigger module for all channels (allows for more advance trigger patterns too), rather than one per channel.

Something that you have the opportunity to do, which oscilloscopes typically don’t do, is listing all trigger events in a recording. On a scope you would try to trigger on an interesting event, then watch the last one of these.

Here you can go on with the recording, mark all of them on the display, and let the user browse through hundreds of events of this type, they’re all recorded anyway. Does that make sense? Wouldn’t it be awesome?

2 Likes

That’s awesome, thanks!

Roger that.

Yes! We can totally do that. That’ll give the “Scope View” something useful to do after a capture has completed anyway.

You mean stop the entire capture based on an analog trigger? Doable, yes.

My thinking was that we didn’t need this since we’re recording everything anyway. ?

Quite doable, yes.

Yes.


This is the first version of this Scope View functionality. We have a lot of work to do both in this feature and across the entire app. Can’t make any promises on which if any of these suggestions makes it in now vs what waits for the v2 of Scope View.

Great stuff Gauthier, thank you!

The more I think about it, the more I see that the scope view would become my main view, rather than the “whole recording view”.

I don’t know about your main user base, but when I pick up this kind of tools, I am nearly always more interested in the faster signals and triggered events, rather than the big picture.

Today I’d use Logic that way: let it record, then always zoom in to interesting events. You have the opportunity to cut out a step for the users here, and not requiring manually searching for the areas of interest. Let alone manually opening a drawer for each channel :fearful:, it looks fancy but would soon get old.

What would be great would be to make it possible to have oscilloscope view as a main view, taking up most of the window, with all channels. I’d rather have an oscilloscope view, and some kind of small minimap for the whole recording (with markings for each trigger event), that would make much more sense to me since the whole view seldom gives anything without zooming in anyway. Maybe a general scope mode with minimap in settings?

With that in mind, force trigger makes sense again I suppose, used to update the scope view with the freshest data.

Stop/single trigger too, I guess (but not only on analog input, that’s not what you meant? Scope view and trigger for digital input is at least as important).

3 Likes

Agreed. The ‘drawers’ will be going away.

Yah this is an interesting one. I could see a single slider that splits the screen between the scope views and the main ones.

Interesting. We have yet to build scope view for digital although that is the intention. It’s not clear to me how useful this will be but we’ll have to try it and find out. With a smart enough trigger it could be really good.

My feeling is that there are two modes: the “what’s going on” mode, and the “I need to dig into this” mode. Previously, we only supported the latter.

I think that intelligently identifying ‘events’ in the zoomed out view (triggered might be good enough as you suggest) is a big deal to improve the main display. The minimap is an interesting approach and we have considered. Not everyone’s data will be ‘bursty’ - so in those cases this is less useful. Nevertheless it’s on the radar.

Thanks for the awesome response!

Then I’ll give you my use case. I program a chip, when I debug I often need to check which functions run, in what order, and how long they take. I typically set a GPIO at the start of the function, and clear it at the end. I do that for several functions, 2 to say 8 of them. Then I want to trigger on the start of one of these functions, and see how the other functions did around it.

Sometimes I want to trigger when the start of a function was late, compared to reference. I want to see the events where the delay between edge of channel y and the edge of channel x is more than I expect.

It would also be useful to let analyzers trigger, but it’s a bit more advance. Something like trigge if SPI says 0xaa.

Another use case: my main chip controls another chip with say 4 digital control signals. I want to observe the timing of these control signals, therefore it’s useful to trigger on one of these signals. It doesn’t feel very appropriate to make these signals analog, only to get the trigger functionality.

2 Likes

I personally love the use case of profiling / instrumentation and I think there’s so much potential capability that could be built up around it. The digital trigger live view makes sense here, thanks.

Yep, makes total sense, thanks!

We are going to do this for sure. Probably like this: One of the digital trigger options will be “protocol”, which will trigger for every new analyzer result item that is added to the list view. By adding a filter to the list view, the user can narrow down the results that cause a trigger. Something along those lines. Probably the trigger can either specify its own ‘filter’ or use the filter on the main list view. Needs a bit of flushing out, I’ll be working on more it this week.

I second this (the scope view would become my main view): it would make it much more comfortable to look at more or less periodic signals. (while being able to stop recording and explore history…

2 Likes