A capture can contain more than 1 trigger event, your statement which is what the reply was based of. Of course once a capture ends there will be some gap before the next one. What use is retriggering more capture when there is already capture occurring? (that goes back to needing additional hardware if you want to follow that path). As already shown, it's relatively common to show multiple triggers within a single capture window/record.
You're talking about multiple things (unknowingly?) and trying to impossibly simplify it down.
Perhaps so.
It may be that I lack the proper terminology for what I'm trying to explain, or that I'm badly mangling the terminology I'm using. My apologies for that.
Maybe it's simpler if I start from scratch, and define my terms.
Capture: a contiguous set of samples acquired from an analog or digital input to the scope, stored in sample memory
Capture buffer: the memory into which a capture is stored
Capture width: the amount of time the capture covers
Capture window: the range of time covered by the capture
Display buffer: memory containing the pixel data to be shown on the display
Display refresh: an operation in which the display shows the current contents of the display buffer
Display refresh period: the amount of time between display refresh operations
Display sample width: the number of samples the display is configured to show
Display update: an operation in which the contents of the display buffer are updated
Display update interval: the amount of time between display updates
Display width: the amount of time the display is configured to show
Display window: the range of time within the capture (or segment, when the scope is stopped) that the display currently covers
End of capture: the point in time that the capture terminates
Segment: a recorded capture
Start of capture: the point in time that the capture starts
Trigger event: the trigger point which actually caused capture initiation (
https://www.keysight.com/used/us/en/knowledge/glossary/oscilloscopes/what-is-a-trigger-event-in-electronics)
Trigger point: a location within the capture where the waveform characteristics meet the requirements of the trigger configuration
Trigger position: the location in the display that the trigger event (or trigger update event) is shown.
Trigger update event: the trigger point which causes the display window to shift its view
Waveform update event: the point in time when the waveform data is processed for display
As far as I know, all current implementations behave something like this:
1. The scope continuously records sample points into the current capture buffer unless stopped. The current capture buffer is treated as a circular buffer for this. Other available sample memory outside of the current capture buffer is not used for the current capture. Save perhaps for one-shot operation, the capture buffer can be at most half of sample memory (the other half is needed to store the prior capture in case the scope is stopped while acquisition is still happening and no trigger event has occurred since the last capture) or a smaller subset, depending on whether or not segments are in use.
2. When a trigger event occurs, the start of capture is recorded. At this point, the capture window is known and well-defined.
3. If segments are in use and the current capture buffer is filled and contains a trigger event, the oldest segment is thrown away and its sample memory is used for the purpose of continued acquisition.
4. The display window is generally centered within the capture (when it is smaller than the capture. Most Siglents by default have the display window and the capture window the same, thus yielding "what you see is all you get"), though its actual position in the capture can be altered via the trigger position. Regardless of its positioning, its position is fixed on at least a per-capture basis until the scope is stopped (I think some scopes will throw away all the prior segments if the trigger position is changed while the scope is running).
5. The start of capture is a predetermined point preceding the trigger event, half of the capture width prior to the trigger event
6. The end of capture is a predetermined point in time following the trigger event, half of the capture width after the trigger event
7. When the end of capture is reached, the capture is recorded (when segments are in use, which is always the case for Siglent scopes), statistics updated, etc.
8. The display always shows a single subset of time within the capture (in Siglent scopes, the default is that the display width and the capture width always match, such that changing the display width changes the capture width)
9. The display isn't updated until, at a minimum, the capture has completed
10. When the scope is commanded to stop, the scope ceases acquisition immediately if no trigger event has occurred since the last capture, or if a trigger event has occurred, can (depending on implementation) continue to record samples into the capture buffer until the end of capture is reached, at which point acquisition ceases.
11. When the capture width is smaller than some fraction of the display update interval (for this it could be, in principle, as much as half of the display update interval), the capture is processed such that the portion that intersects the display window will contribute intensity towards the final displayed waveform. In this case, when the display update interval is reached, the processed data from all processed waveform portions of prior captures and the current capture will be written to the display buffer.
12. When the scope is stopped, it shows the latest capture. If segments are in use, then prior captures can be reviewed. Movement and zoom within a given segment can be done. No scope I'm aware of makes it possible to view contiguous captures as if they were a single capture, but the standard architecture doesn't prevent that.
13. Decoding and other such operations occur at the segment level.
The approach I'm suggesting involves two different cases:
A. When there are no capture termination conditions defined
B. When there are capture termination conditions defined
For case A:
1. The scope continuously records sample points unless stopped.
The entirety of sample memory is initially used. Memory is treated as a circular buffer. If a trigger point has been seen and the scope exhausts sample memory, then the half of sample memory containing the trigger point at its center is made unavailable to the acquisition mechanism, with the rest being treated as a circular buffer. This is to ensure that if the scope is stopped, at least one trigger point and its surrounding samples are retained.
2. The display window is a conditionally shifting view of the contiguous samples. It shifts whenever one of these conditions happens, whichever occurs the
longest amount of time since the last display window shift:
a. A trigger update event occurs, meaning the trigger conditions are met by a portion of the waveform that is at least a display window's width later than the currently viewed trigger update event, and there is enough waveform data to fill the remaining part of the shifted display window after the trigger update event
b. The display update interval passes
c. The display width period passes (I'd previously been thinking about making this optional, so that the window could shift to the next trigger point regardless of the display width, but intensity grading with that, when the trigger point interval is less than the display width, would yield a confusing display, so I'm abandoning that idea).
3. When the display window shifts, it shifts so that its left edge is located at or after the prior location of the right edge of the display window, such that the latest trigger update event is located at the trigger position.
4. The display window shift will cause all (or some subset, if the scope lacks the horsepower to process all) prior valid window-sized non-overlapping sections of sample memory between the right edge of the prior display window and the left edge of the current display window to be incorporated via intensity grading into the current display. A "valid section" here means one that contains a trigger point located at the trigger position within the section.
5. When the scope is stopped, acquisition ceases and the display shows the last display window it has on hand or, if there is no such window (meaning the trigger conditions were never met anywhere within sample memory), the beginning (in terms of time) of sample memory.
6. When the scope is stopped, movement within sample memory is possible just as it is within a capture of a standard scope. But now, history is not a list of segments, but instead is a list of trigger points within sample memory, and reviewing history means moving between those trigger points, which means placing the trigger point under review at the trigger position and showing the acquired samples around it.
7. Alternatively (and something I'd prefer to be configurable), moving to the next history item would mean moving the display window to whichever trigger point follows the current one and which places the left edge of the display window at or after the current right edge of the display window. Zooming out and moving between history items would result in more movement of the display window each time one moves to the next history item.
8. Alteration of the trigger conditions when the scope is stopped would result in the regeneration of trigger points found in sample memory and, thus, history that can be reviewed. This makes is possible to use the existing acquisition to test trigger definitions.
9. Decoding and other similar operations occurs over the entirety of sample memory, at least when the scope is stopped, unless per-segment decoding is desired.
Case B is identical to case A save for:
1. When the capture termination conditions are met, the sample memory from the start of the current capture to the current sample is saved and acquisition resumes into the remaining sample memory. The capture termination conditions can include a predefined time after the first trigger point seen in the capture, a predefined time after last trigger point seen in the capture, the right edge of the window, a predefined time after start of capture, a predefined time after start of capture when a trigger point exists in the capture, and perhaps others. The idea here is to make it possible for this mechanism to yield behavior identical to traditional scopes, but to also give greater flexibility than that.
2. When acquisition memory is exhausted, the memory from the oldest segment is reclaimed.
3. Until a trigger event occurs, the amount of memory used for the current capture will not exceed the time distance between the left edge of the display window and the trigger position.
4. When the scope is stopped, acquisition ceases immediately unless a trigger event was detected, in which case it continues until at least the right edge of the display window before stopping.
5. Moving to the next history event can involve moving to the next segment, not merely remaining in the current segment.
There are surely some problems that I haven't considered in coming up with the above, and some of them might well be fundamental, and perhaps even fatal. It's one of the reasons for putting this here.
Home
Help
Search
Login
Register
