Products > Test Equipment
Waveforms/second in Siglent and other scopes -- limits due to capture handling
(1/6) > >>
kcbrown:
I've been asked to start a new thread on the topic, since this originated in the Magnova scope thread: https://www.eevblog.com/forum/testgear/magnova-oscilloscope/?all


--- Quote from: 2N3055 on May 17, 2024, 07:09:39 am ---
--- Quote from: kcbrown on May 17, 2024, 02:38:11 am ---Not really.  Even with those options, Siglent's DSOs don't behave the way I described as regards a trigger mechanism decoupled from the memory depth.

--- End quote ---

What you are explaining is exactly explanation of search /"whateverscan " as implemented on some scopes.

--- End quote ---

Which scopes?  Certainly not Siglent, unless it's changed since the 2000X+ series.

On the Siglent, each history item is a complete capture.  There is no overlap between them in terms of time, at least that I've ever seen.  If it worked the way I described (for those who haven't seen it, I described it here: https://www.eevblog.com/forum/testgear/magnova-oscilloscope/msg5503027/#msg5503027), then there would be overlap between the history items, and furthermore it would be possible to zoom out within a history item such that other trigger events would become visible even if the original time range covered by the history event's capture was smaller than the total size of memory.  Moreover, one could then zoom way in while the scope is running, see the waveforms updating on the screen in the way one would normally expect (with persistence and everything), stop the scope, and then examine the history items, replay them, etc., just as we can do so now, but with the added advantage of being able to zoom way out from within each history item to see what surrounded it.  There would be no need for a "search", because the trigger events would have already been recorded and become part of the history.

In essence, the entirety of memory becomes your capture buffer, and trigger events are then just pointers to locations within it, and history items are merely trigger events as well.

No scope I know of implements things in quite that fashion.  History items, in particular, seem to be coupled to some predefined time length (whether the result of the timebase selection, or the predefined capture buffer size divided by the sample rate).  The way you tell is that if it implements it as I describe, then the time distance between history items can be smaller than the time width of the screen as it was when the trigger fired.  I know of no scope for which that's true.



--- Quote ---But you don't seem to understand how it works. For instance, on Siglent touch scopes, triggering is decoupled from memory capture. It runs at full speed, on incoming buffer and pretty much simply timestamps where the trigger happened while scope is endlessly filling circular buffer. Trigger event is simply pointer to memory location in a way, and a mark that scope should process data.

--- End quote ---

Then why can't you zoom out from within any history item and see other trigger events from within that zoomed out view of the history item?  At least, I've never been able to do that on any of the scopes I have (including my 2104X+).


--- Quote ---It is not triggering that results in rettriger blind time. It is processing of data.

--- End quote ---

That presumes that processing of data can't happen in parallel with the triggering mechanism.  I'm skeptical.  The main issue I see with this is parallel memory access.

If I'm not mistaken, the trigger re-arm time is always longer than the amount of time represented by the capture buffer.  And if that's so, then that proves my point.  What I describe decouples things such that the trigger re-arm time is essentially a constant, just long enough for the scope to reset the hardware associated with the triggering mechanism (e.g., registers and other things that are used in the FPGA logic), record the event time and other required items associated with the trigger event, and to, if necessary, resume capturing (presuming that capturing isn't independent of trigger re-arm).


--- Quote ---In fact, the frequency counter uses parts of edge trigger mechanism to count frequency...
And that works very fast .....
But it only counts and that is fast to do.

--- End quote ---

True enough.  I'll have to play with it with very long capture lengths to see how it behaves and how often it updates under those conditions.

kcbrown:

--- Quote from: kcbrown on May 23, 2024, 05:56:53 am ---
--- Quote from: 2N3055 on May 17, 2024, 07:09:39 am ---In fact, the frequency counter uses parts of edge trigger mechanism to count frequency...
And that works very fast .....
But it only counts and that is fast to do.

--- End quote ---

True enough.  I'll have to play with it with very long capture lengths to see how it behaves and how often it updates under those conditions.

--- End quote ---

Yep, that works just as you described, even with very long captures.  That proves that the approach I described can potentially work.

It occurs to me that the rate at which the trigger point is recorded doesn't have to keep up with the rate at which the trigger fires.  When necessary, the trigger points can be "backfilled", with the history mechanism built from recorded and backfilled trigger points.  The trigger point recording just has to fire often enough to keep the display processing mechanism happy and reasonably accurate (for things like glitch display and such).

Now, I should note that you obviously want the option of limiting your capture size, not for the purpose of determining how long the trigger delay is (that's a separate setting), but rather so that if the delay between trigger firings is longer than what you're interested in, then you can ensure that the capture memory isn't used up needlessly by waveform data you'd have no interest in.  So you'll want to be able to define the maximum width of a capture.  To make sense, the width of a capture when defined like this would have to actually be some integer fraction of total capture memory.

What would the history look like if you use that mechanism?  No different than it would if you used the entirety of memory for a capture, save for one thing: the degree to which you could "zoom out" from a given history event trigger point would be limited by the capture size.  You could still have multiple trigger events per capture, and thus multiple history events per capture, and the history mechanism would still simply switch you between views of a given capture.  The difference is that instead of a single large capture in which all history events are contained, you'd have multiple captures in which those events are contained.
nctnico:
One thing you need to keep in mind is that history mode is often of limited use. Doing analysis, decoding, search through a bunch of acquisitions in the history / segmented buffer is often harder or impossible compared to having a single, long capture. Abilities differ vastly between oscilloscopes and there is little functional overlap amongst manufacturers. For example: Keysight is the only manufacturer (I know of) which supports showing a decode table for all segments in the memory (with the ability to hop from one segment to the other based on selecting a row in the decode table). GW Instek OTOH supports doing statistical analysis / measurements over segments in memory. In most cases the segments are treated as seperate, non related acquisitions which reduces the usefullness. You coud get a lot more information if you can do analysis / measurements which spans all or a selection of segments.
TomKatt:

--- Quote from: nctnico on June 11, 2024, 11:04:42 pm ---One thing you need to keep in mind is that history mode is often of limited use. Doing analysis, decoding, search through a bunch of acquisitions in the history / segmented buffer is often harder or impossible compared to having a single, long capture. Abilities differ vastly between oscilloscopes and there is little functional overlap amongst manufacturers. For example: Keysight is the only manufacturer (I know of) which supports showing a decode table for all segments in the memory (with the ability to hop from one segment to the other based on selecting a row in the decode table). GW Instek OTOH supports doing statistical analysis / measurements over segments in memory. In most cases the segments are treated as seperate, non related acquisitions which reduces the usefullness. You coud get a lot more information if you can do analysis / measurements which spans all or a selection of segments.

--- End quote ---
This is one reason I think I’d really like to try a Pico scope….  Seems like using the pc for some kind of buffer / storage would allow that kind of flexibility.  There’s probably a limit to how quickly you can go for the timebase, but still…
kcbrown:

--- Quote from: nctnico on June 11, 2024, 11:04:42 pm ---One thing you need to keep in mind is that history mode is often of limited use. Doing analysis, decoding, search through a bunch of acquisitions in the history / segmented buffer is often harder or impossible compared to having a single, long capture.

--- End quote ---

That seems to argue in favor of the approach I described, wherein history elements are mere references to trigger locations within captures and not to captures themselves.  What I describe makes history elements a many-to-one mapping onto captures, such that you can have many history elements within a single capture.  What you're talking about here is with respect to captures, and the history mechanism in the case you describe is merely a means of reviewing those captures.  One reason history mode is of limited use is that in all the implementations I've seen, it's mapped one-to-one with captures.  But with a many-to-one mapping, the number of captures you have can be as little as one while the number of history elements will be as many as there are trigger events in the capture.  Multiple captures with that kind of architecture would be useful only if you explicitly need uncaptured dead time between trigger events, which can be the case if the time between events is much larger than the amount of time of interest, or so large that a single capture would exceed the memory capacity of the scope.

Regardless, I agree, you really do want the ability to perform analysis on all selected or stored captures, not just the one being viewed, as you mention.

Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod