Most certainly, the "always on" history segment capability isn't dependent upon WYSIAYG, and I did note that. But it is a part of Siglent's approach to things, and I think it's a good choice because, firstly, it ensures that memory is always used to its fullest even if the user configures a smaller capture size,
How is that any different than configuring the DSO to use full memory size and using it as a single acquisition? At one end you reason you want to see what you get but on the other end you find a variable (!) number off-screen acquisitions in history mode good to have. Why is having multiple individual acquisitions off-screen in memory good while having off-screen data from a single acquisition is not good?
Because multiple individual acquisitions represent multiple trigger events (each one corresponds to a trigger event), while a single large-memory capture represents a single trigger event. Sure, the capture
might contain additional trigger events but, of course, you have to explicitly search for them. The same is true even with segments, of course, because the amount of time you captured in a single segment could contain multiple trigger events. But the presence of multiple captured segments
guarantees that you'll see multiple trigger events irrespective of your timebase and other capture settings, assuming they happened and the scope noticed them. That, of course, is true of all segment systems.
The Siglent approach allows for both a single full memory capture and a multi-segment capture, simply by changing the timebase and memory depth appropriately. It allows you to use all of the memory in a single acquisition if you like, and it's not like it's hard to set that up: set your memory depth to the maximum, set your timebase large enough that the scope shows all of your memory being used, and you're done. But if you
explicitly tell it to use less than full memory depth, just as you can with the other scopes, it will use the remaining memory for additional segments automatically (as long as your capture is using less than half of the memory, of course), while the other scopes
don't use the additional memory for anything at all (at least that I've seen).
Now, of course, you can generally get all scopes that do segments to do roughly the same thing. Roughly. But how much work you have to do in order to achieve it varies. With the Instek, for instance, I have to enable segments, then I have to specify my memory depth, then I have to specify the number of segments I want (the maximum the scope allows me to set this to is dependent on the memory depth, which is why I had to do that first), and then if I care about the time duration of a capture (if, for instance, I'm looking to maximize the capture rate while capturing enough time per capture to see the problem), I have to configure my timebase such that the scope's sample rate divided into the memory depth gets me a time duration that meets my requirements.
With the Siglent, you set the timebase so the screen covers the capture length you want,
optionally set the memory depth to act as the upper bound on the capture size (e.g., if you know you'll want some minimum number of segments), and you're done.
That is the difference between segments being an afterthought and segments being first-class objects that are baked into the system from the start.
I can't remember the specifics now, but Instek's segment implementation (as an example) has some arbitrary limitations, and conflicts with some of the other features the scope makes available. And that almost certainly wouldn't be the case if segments were a first-class object in the implementation, instead of an afterthought.
You need to seperate two things here: user interface and acquisition engine.
It might even be more complicated than that. There's also the processing that happens in between, which from the point of view of the UI might happen in the background or the foreground but would still (more likely than not) have to care about segments all the same.
For the acquisition engine segmented recording is nothing more than cycling the acquisition position counter between a lower and higher boundry (start & end point). In fact most (if not all DSOs) have segmented recording at the base of the operation of the acquisition engine in order to have double buffering (*). Once the acquisition is done the acquisition position counter and trigger point are stored and the acquisition is handed over to the rendering engine. This is not rocket science to implement (been there, done that).
Of course. The difference is that additional segments over and above the one used for double buffering aren't necessarily accounted for throughout the firmware, but they
would be if the segmenting system itself is a first-class mechanism in the firmware. If you do
everything through the segmenting system, as Siglent seems to, then everything you do will automatically account for it because the standard way of getting at the data will be through the segmenting system.
It depends on the user interface on how the segments are displayed & handled. There is a wild variety of ways and depending on what you need one DSO may be better suited than the other but this doesn't mean segmented recording as a base has been added as an afterthought. Displaying segments is not GW Instek's strong suit but they have a rather unique feature which allows to do statistic analysis on the recorded segments.
Right. But the one example I can think of off the top of my head with respect to the Instek is the FFT. It will
not display the FFT as processed for each segment. It will display only a single FFT trace regardless of what the segment contains.
Maybe that's a bug, but in a way, that's the point: the segments aren't first-class objects that are always used, so the notion of the "current segment" wasn't considered for the FFT. I'd wager that in Instek's firmware architecture, you have to go out of your way to get the data from the current segment. But that's just a wild guess on my part.
I could swear there's another feature that conflicts with the segment system on the Instek (maybe the pass/fail mask test? I'll have to experiment to find it again).
So how useful are segments anyway? Obviously useful enough that most of the scope manufacturers have implemented it. But I find Siglent's "always on" approach to be the preferred one. You don't have to use it if you don't want to, but it's always there anyway, just in case you do. That's sort of like the "zoom out" capability you like: it's always there in case you need it. The difference is that the "zoom out" capability hinges on the time length of your buffer being larger than your screen's time width, but even on scopes like the Instek that is something that is
not guaranteed! But I expect that for most scenarios, it'll be there for you. The same could theoretically be said of the Siglent, but there's only one situation in which it won't be there: when you've told it to use the full capture buffer *and* your timebase is long enough to result in the scope having to use more than 50% of the available sample memory for the capture.
Home
Help
Search
Login
Register
