Magnova oscilloscope

[kcbrown]

Hello,

the high wfms/s can only be achieved with small memory. With 3 Gpts/s, 36 kpts already require 12 us. The maximum wfms/s that can be achieved here is less than 84 kwfms/s. With larger memories than about 12 kpts, the specified 230000 wfms/s will not be achieved.

Best regards
egonotto

The above is a relatively old message but I've not seen anything in response to it.

Whether or not high wfms/s can be achieved with large memory depends entirely on the implementation.  Yes, with a standard/typical implementation, the wfms/s that's achievable will depend on the capture length which, in turn, is usually at least somewhat dependent upon the timebase.

But nothing (at least in principle) prevents multiple trigger events from being recorded per memory capture.  And it's the trigger event capture rate which is generally regarded as the basis for wfms/s.

In essence, what you state above presumes that there's only one trigger event that's recorded per memory capture.  That may be how most scopes are implemented, but I don't know if it's necessarily true that they must be implemented that way.

[nctnico]

Hello,

the high wfms/s can only be achieved with small memory. With 3 Gpts/s, 36 kpts already require 12 us. The maximum wfms/s that can be achieved here is less than 84 kwfms/s. With larger memories than about 12 kpts, the specified 230000 wfms/s will not be achieved.

Best regards
egonotto

The above is a relatively old message but I've not seen anything in response to it.

Whether or not high wfms/s can be achieved with large memory depends entirely on the implementation.  Yes, with a standard/typical implementation, the wfms/s that's achievable will depend on the capture length which, in turn, is usually at least somewhat dependent upon the timebase.

But nothing (at least in principle) prevents multiple trigger events from being recorded per memory capture.  And it's the trigger event capture rate which is generally regarded as the basis for wfms/s.

In essence, what you state above presumes that there's only one trigger event that's recorded per memory capture.  That may be how most scopes are implemented, but I don't know if it's necessarily true that they must be implemented that way.

Agreed. This way of parallel/dual acquisition has been debated before and turned out to be a very hard concept to grasp for many so I'm not sure if any oscilloscope manufacturer is going to implement a parallel acquisition mode.

Edit: come to think of it, I actually designed a data acquisition/ oscilloscope product which does exactly this about 10 years ago. Long buffer and short buffer combined. It is used on a large scale at a bunch of labs across the world.

[2N3055]

Hello,

the high wfms/s can only be achieved with small memory. With 3 Gpts/s, 36 kpts already require 12 us. The maximum wfms/s that can be achieved here is less than 84 kwfms/s. With larger memories than about 12 kpts, the specified 230000 wfms/s will not be achieved.

Best regards
egonotto

The above is a relatively old message but I've not seen anything in response to it.

Whether or not high wfms/s can be achieved with large memory depends entirely on the implementation.  Yes, with a standard/typical implementation, the wfms/s that's achievable will depend on the capture length which, in turn, is usually at least somewhat dependent upon the timebase.

But nothing (at least in principle) prevents multiple trigger events from being recorded per memory capture.  And it's the trigger event capture rate which is generally regarded as the basis for wfms/s.

In essence, what you state above presumes that there's only one trigger event that's recorded per memory capture.  That may be how most scopes are implemented, but I don't know if it's necessarily true that they must be implemented that way.

Just think about it : how can you have multiple triggers in a single trigger event?

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.

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.
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..

[kcbrown]

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.

[tautech]

Yes KC but you overlook how the more upmarket Siglent DSO's can manage memory.
SDS2000X HD models and above offer a fixed mem depth option of whatever size you select it to be which at max mem depth offers an order of magnitude more zoom out than many other popular scopes.

Processing all that memory and buffers does not come without a cost in wfm/s.

As for analyzing captures and any trigger events they might contain, the Search function works just fine for that and any other random events you might set the Search function to find.

[kcbrown]

Yes KC but you overlook how the more upmarket Siglent DSO's can manage memory.

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.

SDS2000X HD models and above offer a fixed mem depth option of whatever size you select it to be which at max mem depth offers an order of magnitude more zoom out than many other popular scopes.

Which is nice as far as it goes.  But does it perform multiple trigger events within that same max memory depth?   If it does, I'd not heard of it.

Processing all that memory and buffers does not come without a cost in wfm/s.

That's my point.  It doesn't necessarily have to.  That it does is precisely because the memory depth and trigger rate are tightly coupled in the current design.  Nothing prevents the trigger mechanism from operating completely independently of the memory depth.  Coupling them in that manner is a design decision.

There are certainly going to be design consequences for doing things the way I described.  It may be, for instance, that one might have to sacrifice some amount of capture rate in order to free up enough memory bandwidth to make reading from the memory while a capture is going possible.  It may be that more high-speed memory is necessary in order to facilitate some of the operations that are happening.   It may be that the memory architecture itself would have to be segmented to make reads from one segment simultaneously possible with a capture being written to a different segment.

As for analyzing captures and any trigger events they might contain, the Search function works just fine for that and any other random events you might set the Search function to find.

No doubt.  But that comes at the cost of the history mechanism.  The wonderful thing about the history mechanism is that you can see the capture as it was around the specific trigger point it references, and you can then play it forwards at the rate you desire (or single-step it) and see how the capture changes around the trigger point.  But as it is right now, the minimum time distance between trigger points is defined by the buffer size (whether defined explicitly or by the screen's time width).  Right now, a history item includes both the trigger point and the capture around it.  With what I am talking about, those are decoupled: the history item would then be the trigger point only, and it would be what amounts to a pointer into the entire buffer.  Zooming out from a given history item could thus reveal later (and earlier) history items, and scrolling through the history items would simply cause your view of the buffer to shift based on which trigger point you're currently examining.

My original point still stands: the wfms/s value's dependency on the buffer size is an engineering choice, a consequence of the capture architecture that has been chosen.  It needn't be that way necessarily (and changing it to something like I described may well yield other tradeoffs), but it is that way for current implementations, and Siglent is no exception to that.

[tautech]

An interesting discussion KC and one where wise old owls like RF Loop could enlighten us more.

Trigger events are replicated on Trig Out which could more closely reveal what's going on.
Some fun might be to monitor Trig Out on another scope and attempt to use it as the trigger source for the same source waveform. < Just me thinking aloud and wonder if it can be done and what it might show. 

[egonotto]

Hello,

I think you can do it the way kcbrown suggests. But I suggest discussing it in a new thread, since it doesn't have much to do with Magnova.

Best regards
egonotto

[2N3055]

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.

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

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.
It is not triggering that results in rettriger blind time. It is processing of data.
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.

But as Egonotto said, that discussion, in depth should be relegated to somewhere else.

[kcbrown]

But as Egonotto said, that discussion, in depth should be relegated to somewhere else.

Done: https://www.eevblog.com/forum/testgear/waveformssecond-in-siglent-and-other-scopes-limits-due-to-capture-handling/