Just think about it : how can you have multiple triggers in a single trigger event?
You can't. But that's not what I'm talking about. I'm talking about multiple trigger events
per memory capture, which is quite a different thing.
You set scope to capture 1 sec after trigger. How can you have 1 sec long capture and multiple triggers in that 1 sec at the same time? Trigger event and connected capture are one, atomic event.
That's my point: they needn't be connected in that manner. A trigger event quite clearly exists within the capture but there needn't be a 1:1 mapping between trigger event and capture. That can be a many:1 mapping, yielding multiple trigger events within a given capture.
Consider an architecture in which samples are captured continuously in a circular buffer (until stopped, of course). A trigger event is merely a sample location within the buffer. Quite obviously, it's possible for more than one trigger event to exist within the buffer. This continuous sample recording has to happen anyway for a digital trigger system to work at all, so you already have something like this. The real question is how the memory is managed. That matters a lot. Continuous acquisition and recording means that the memory is going to be continuously written to, but some amount of memory bandwidth has to be available for reads from it to happen, because those reads will be needed for waveform processing, trigger event information storage, etc.
Now consider the history mechanism. As implemented by Siglent, the history mechanism records individual captures in their entirety. Each capture is the result of a trigger event taking place. There is a 1:1 mapping between trigger event and capture as implemented by Siglent. But if implemented as I describe, what this would do is show a history event
per trigger event, even when each capture contained multiple trigger events. You could even do this in such a way as to use no more memory than the current mechanism does (save for the additional event metadata), since overlapping history events could share sample memory for the regions of time that overlap between them.
For instance, suppose you're capturing a sine wave with a rising edge trigger. Suppose your capture buffer is configured to capture 10 cycles worth of time, making your capture buffer a small subset of the total memory in the scope. As currently implemented, this means the trigger would fire at most every 10 cycles, and your history mechanism would thus record one capture every 10 (or more) cycles. But if implemented as I describe, the history mechanism would record one entry every cycle, and each history event would share 90% of its waveform data with the event that preceded it.
In fact, implementation like this could buy you enormous flexibility. Right now, you're hamstrung by your choice of buffer size (whether directly or, as Siglent does by default, as a consequence of the selected timebase's effect on the time width of the screen). But you needn't be. If all the trigger acquisition system did was to record when trigger events took place within the larger buffer, your view of any given trigger event could be as wide or as narrow as you wished it to be
after the fact, limited only by the amount of actual memory and where in the memory the trigger event is stored.
Another advantage would be that if you are performing a single capture, the trigger event would, as it does now, cause the scope to stop capturing points once the end of the buffer was reached. But the difference is that the trigger mechanism would remain active up to the point the end of the buffer was reached, and a history event created for each time the trigger fired. A "single capture" could then result in multiple history events being captured, each one of which could then be examined as usual. Right now you get only one history event, and have to go out of your way to examine later events (using the mechanism you describe below).
Yet another advantage is that you suddenly don't have to worry about memory width at all, though you may want to be able to control the sample rate.
In essence, what I'm describing is decoupling of data capture and trigger capture, such that trigger events are simply pointers into the capture memory.
If you meant that it would be nice to be able for the scope to detect all signal conditions that would be equivalent to trigger conditions in that single long capture, that exist in scopes with search function implemented that way.
That's sort of what I'm talking about, but the difference is that while the scope is running, each encounter of the trigger conditions would, among other things, result in the trigger out state being toggled.
For instance, on my Siglent scope I can directly copy some trigger conditions to search.
In which case scope will trigger, capture one long capture and then also detect all "trigger equivalent" signal points in that capture...
In which case in that captured chunk I have "zero blind time"...
On LeCroy scopes you have WaveScan function that does even more advanced post analysis on captured data. Siglent has similar SignalScan function on SDS7000A..
That goes a long way towards accomplishing the same thing for many circumstances.