It is not a analog scope. Retrigger time on digital scope is pretty much nil. Keysight 3000T actually triggers at 20MHz trigger rate without problems. At certain short timebase, retrigger time is about 200ns in segmented mode. They don't even publish this.. Their spec is very conservative here.. In normal displayed mode it is much slower... When looking at trigger out, you will notice that it keeps triggering even while sweep is in progress.. And it is useless for normal scope operation, there are some other uses for this, but for classic scope operation it is not useful.
But...
Digital scope triggering rate is defined by very short time needed for triggering FSM to be primed for new trigger (that can be made very quick) and by time needed for captured data is measured and prepared for display engine, and then with time display engine is ready for new data.
That is the reason that segmented captures are faster, you need to wait for the display.
And when you're displaying data, it has to process all the pixels and data points, those before and after trigger point, whatever should be on the screen.
Overlapping triggered data doesn't make sense, and there are no scopes that do that. That is a waste of memory.
That is why you have long memory scopes, just grab 120 events at the same time and look at that... That guarantees zero (0) retrigger time.
I mentioned the approach I did because I presumed that the truly superior way of doing it would be something that would require so much in the way of software changes that it wouldn't be reasonably feasible for Siglent to do. Namely, that the truly proper way of doing it would be to make the capture (I define "capture" here as meaning a single contiguous set of recorded samples, while a "segment" is a capture plus a trigger point) be variable size, with the minimum size being that of the time width represented by the display and the maximum size being that of the entirety of memory, and the point at which a capture ends is when the time between the last trigger event and the current time exceeds the time distance between the trigger location on the screen and the right edge of the display (if memory is exhausted and the entirety of memory represents a single capture, then you'll have to prune your current capture from the left hand side in order to free it for current samples). You record all of the trigger events that occurred within that capture and that, along with the capture itself, is what you store. Operationally, since the memory acts as a circular buffer, you would need to be able to prune the oldest capture from its left side in order to free memory for the current capture (and it's entirely possible that the oldest capture
is the current capture -- the principle of pruning would remain the same). If the oldest capture contains just a single trigger point then you obviously free up that entire capture for use in the current one.
What the user sees after stopping the scope and going into the history would then depend on his timebase and offset settings. He could change his timebase in order to see more or less of the capture, and playing the history forward would shift his view within the larger capture so that each trigger point would be centered on the trigger location he's selected (center screen by default). If memory contains multiple disjoint captures (as would be the case when the distance between two trigger points exceeds the time between the trigger location and the right edge of the screen at the time the later trigger event fired), then moving from the last trigger point in the previous capture to the first trigger point in the next capture would, of course, show up on the display appropriately as one would expect. The end result is that replaying the history would, by default, look very much like it does now, but with greater ability to examine the waveform associated with multiple closely-spaced trigger events. Zooming out relative to the originally specified timebase would become feasible depending on whether or not multiple trigger events are represented within the currently viewed capture.
This approach has at least a couple of advantages over Siglent's current approach. The waveform update rate can now remain at the maximum the scope is capable of or the rate at which trigger events actually occurs, whichever is smaller. The scope can now potentially store
many more history "segments" than it currently can because each "segment" is just a pointer to a trigger event within a capture and there can be many such pointers for a given capture. Of course, these pointers also take up memory, but clearly a pointer takes up much less memory than even the smallest of captures. And actually, whether or not you need to store the trigger locations depends on whether or not the trigger locations can be reconstructed from the capture data. If they can be reconstructed then you can do that at history viewing time. But whether they can be reconstructed depends on the capture sample rate relative to the scope's native sample rate -- the trigger system always operates at the latter rate irrespective of the former rate.
The problem that I'm trying to solve here is one that other oscilloscopes solve by arranging their capture update rate to match that of what's displayed on the screen while arranging for the final capture to occupy the entirety of memory, so that when the scope stops you can, depending on the sample rate and the amount of time represented by the screen, get much more in the way of capture to examine than just what the screen shows. The Siglent
always gets you captures that are limited to the screen's time width, irrespective of how much memory is available. Instead of using the additional memory for additional off-screen capture time, the Siglent uses the rest of memory for additional historical segments. I rather like Siglent's general approach here, but see no good reason that the capture rate
must be capped by the amount of time represented by the screen. What I'm proposing is a way of getting both a heightened waveform rate
and a larger capture, all the while remaining faithful to Siglent's "what you see is all you get" approach to capture management.
As regards the trigger delay, here's the thing:
if you want the trigger to be delayed by some amount before it can fire again, there is already a direct way to accomplish that: the trigger holdoff value. Given the availability of that value, I see no good reason to impose another arbitrary limitation on when the trigger can fire again, assuming you don't prematurely run out of some resource (like memory) as a consequence of allowing it to fire too quickly.
The history should be a reflection of when the trigger conditions were met and nothing else. If you want to space out the trigger events, you impose a holdoff time.
For instance, for your first request, I would rather that, when I press Single, it doesn't grab a full memory (which on slower time bases can be quite some time too), but to rather not delete history buffers. I didn't know it did that, it shouldn't delete history..
There turn out to be multiple things that cause the history to get nuked. Just moving the waveform up or down will do that, as will shifting the trigger point.
Scope shouldn't start anything immediately in single mode. It has to wait for trigger.
Yes, but if it doesn't even bother to start capturing data before it detects the trigger then you'll get
no data prior to the trigger point. No, if you want data preceding the trigger, you have no choice but to start recording samples immediately when the "single" button is pressed, and you stop recording only after the requisite amount of time past the trigger event. And it can't be any other way, obviously, because the scope simply doesn't know at what point the trigger will fire once you hit the "single" button.
You use Single to capture important trigger event and then stop.
When setting time base and trigger position you setup how long the capture should be, sample rate and trigger position. And scope will get exactly that. If you set up trigger position at half the screen it will be 50/50% pre and post.
And if doing so didn't nuke your history, then it would be perfectly reasonable to do that. But if Siglent
insists upon nuking your history and not even retaining your single capture once you start normal or auto triggering, then it's clearly better for them to use the entirety of memory for the capture than it is for them to
leave the memory unused. But I agree with your general assessment here. See below.
And if they fix that Single works with history buffers you could set set each Single capture to be fraction of the memory, so you could get, say, 10 or 20 events and then analyse and compare them.
Much more useful than grabbing all the memory all the time, even when I need something else. If I want long capture, I just set it for long capture. If you want to look at detail, just zoom in to it.
If zoom mode is awkward to use, than we should pester Siglent to make zoom mode nice and easy to use.
I completely agree. It is certainly better for them to retain the segments across multiple invocations of the trigger buttons (whether "auto", "normal", or "single"), and let the user decide for himself what to do next. As you say, you can manually arrange to use the entirety of memory for a single capture if you so choose -- it's just a question of setting the appropriate timebase and memory depth.
Home
Help
Search
Login
Register
