Products > Test Equipment

Waveforms/second in Siglent and other scopes -- limits due to capture handling

<< < (3/6) > >>

Someone:

--- Quote from: kcbrown on June 19, 2024, 12:13:30 am ---That presents a situation that no scope I'm aware of can deal with properly.  But the architecture I'm proposing can.
--- End quote ---
Then you'll need to explain it better, instead of a wall of text describing things it will solve but not how it will do that in a new way.

There are already scopes where you can adjust the memory depth of the segments (i.e. change the number of segments/history pages while keeping the total memory use maximised) from 1 to some arbitrary high number.

Maintaining a continuous recording (a la digitiser) falls apart because few scopes have human scales of recording in memory at the full sample rate. Scopes are triggered for a reason. When sample memory is 10x higher than sample rate then it might appear as a feature.

kcbrown:

--- Quote from: 2N3055 on June 19, 2024, 06:36:22 am ---
--- Quote from: kcbrown on June 19, 2024, 12:13:30 am ---..................
There are situations in which you want to be able to see, in "real time", a small but continuously updating subset of the entire capture, and you don't know in advance how long your capture needs to be in order to get everything of interest.  A serial decoding session of something that is emitting messages of arbitrary length at arbitrary times might be a good example of this.  I ran into a situation like this when I was examining the SPI bus used by a computer for fetching data from the BIOS.  I was forced to either perform a single capture of a long period of time, or to perform multiple captures where each was of a fixed width, when the nature of the data I wanted to capture was that it had bursts of arbitrary length activity with arbitrary amounts of dead time between each burst.  That presents a situation that no scope I'm aware of can deal with properly.  But the architecture I'm proposing can.

--- End quote ---


It is hard for me to understand how you don't see contradictions in your own explanations.

Let me try to explain through practical examples.


1. You have bursts of data 10-35 µs in length coming in every 100ms to 2 sec. You have 100 Mpts scope memory. Scope is sampling at 1GS/s. Make note that per your request, you have no knowledge of data beforehand. How many packets of data you can have in memory at any time?

--- End quote ---

100 Mpts of scope memory at 1GS/s gets you 100 ms worth of memory at that sample rate.  If you have no options save for performing a single capture then, with the bursts coming in every 100ms to 2 seconds, clearly you'd only get one burst.

But I'm not arguing that the architecture must use the entirety of memory for a single capture.  As I said previously:


--- Quote from: kcbrown on June 19, 2024, 12:13:30 am ---That remains the case even with the approach I mentioned, because: "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."

But even that might not be sufficiently flexible.  This is so because specifying the capture size in that way means that you're artificially limiting the length of your capture from the time of the first trigger point in the capture, while you might well need to, instead, specify the maximum amount of "dead time" after the last trigger point in the capture.  See below for an example of why you might want to do this.

Rather than breaking up memory into equal-sized segments, it may make more sense to capture sections of trigger activity, even if they're of varying sizes.

--- End quote ---

So let's suppose that the mechanism I describe above is in play.  How many bursts you can capture depends on the capture termination conditions and the signal characteristics.  Let's suppose that the data is an active high signal with a maximum high time of 1 us, so just to keep things safe you define a capture termination condition of 10 us after the last trigger (meaning: if 10 us elapses without the trigger firing, the capture stops and the scope prepares to gather a new capture in the remaining memory).  You also define the maximum amount of capture prior to the capture's trigger to be 10 us, using whatever mechanisms are appropriate for that.  So the capture will contain 20 us of padding plus whatever the length of the burst is.  Now each capture ranges between 30 us and 55 us in length.  With 100 ms of capture memory, that amounts to a minimum of 1818 captures, and (if all bursts happen to be of 10 us duration) a maximum of 3333.



--- Quote ---2. You have bursts of data 10-35 ms in length coming in every 100ms to 2 sec. You have 100 Mpts scope memory. Scope is sampling at 1GS/s. Make note that per your request, you have no knowledge of data beforehand. How many packets of data you can have in memory at any time?

--- End quote ---

Now the bursts are 3 orders of magnitude longer.  Let's suppose that the maximum high time is now 1 ms.  Knowing that you have limited memory, you have to compromise on your capture start and termination conditions, so let's suppose you give it 5ms before and 5ms after, for 10 ms worth of padding.  If you can't change your sample rate then that'll give you captures of a duration somewhere between 20 ms and 45 ms, so now you get somewhere between 2 and 5 captures.



--- Quote ---3. You have bursts of data 10-35 µs in length coming in every 100ms to 20 sec. You have 100 Mpts scope memory. Scope is sampling at 1GS/s. You setup scope and let it run. You go to lunch.
Make note that per your request, you have no knowledge of data beforehand. How many packets of data you can find in memory at that time?

--- End quote ---

The answer here is the same as the answer to your first question.



--- Quote ---4. You have bursts of data 10-35 ms in length coming in every 100ms to 20 sec. You have 100 Mpts scope memory. Scope is sampling at 1GS/s. You setup scope and let it run. You go to lunch.
Make note that per your request, you have no knowledge of data beforehand. How many packets of data you can find in memory at that time?

--- End quote ---

The answer here is the same as the answer to your second question.

kcbrown:

--- Quote from: Someone on June 19, 2024, 11:23:21 am ---
--- Quote from: kcbrown on June 19, 2024, 12:13:30 am ---That presents a situation that no scope I'm aware of can deal with properly.  But the architecture I'm proposing can.
--- End quote ---
Then you'll need to explain it better, instead of a wall of text describing things it will solve but not how it will do that in a new way.

--- End quote ---

Perhaps my last reply to 2N3055 will help clarify things somewhat.


--- Quote ---There are already scopes where you can adjust the memory depth of the segments (i.e. change the number of segments/history pages while keeping the total memory use maximised) from 1 to some arbitrary high number.

--- End quote ---

Yes, there are.  But all of them define the screen refresh period (when the trigger fires often enough, of course) on the basis of the capture size, not the displayed time period.  Some scopes (like most Siglent scopes, save perhaps for the most recent models) define those two things to be the same.



--- Quote ---Maintaining a continuous recording (a la digitiser) falls apart because few scopes have human scales of recording in memory at the full sample rate. Scopes are triggered for a reason. When sample memory is 10x higher than sample rate then it might appear as a feature.

--- End quote ---

That may be.  But I'm not arguing that we should dispense with segments.  I'm arguing that we should dispense with the 1:1 mapping between captures and trigger events, that the display update rate should be defined by the time delay between trigger firings or optionally the time width of the display (whichever is longer, if the time width of the display is considered) even if the capture width is longer than both.

Perhaps another way of saying it is: the waveform update rate should be independent of the capture size.


Maybe I can illustrate my point with a question: suppose you're looking at an SPI bus signal, you've got the display zoomed in so that it's showing a single decoded value, and your trigger is set up so that it fires for every value.  How often will your display refresh to show a new value, and how many such values will you acquire in a single capture?  What will happen to the waveform data between displayed values?

What you want to see in real time and what you want to capture are not necessarily the same thing.

Someone:

--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---
--- Quote from: Someone on June 19, 2024, 11:23:21 am ---There are already scopes where you can adjust the memory depth of the segments (i.e. change the number of segments/history pages while keeping the total memory use maximised) from 1 to some arbitrary high number.
--- End quote ---
Yes, there are.  But all of them define the screen refresh period (when the trigger fires often enough, of course) on the basis of the capture size, not the displayed time period.  Some scopes (like most Siglent scopes, save perhaps for the most recent models) define those two things to be the same.
--- End quote ---
Perhaps start with getting the terminology correct. Displays/screens refresh at their own rate (generally some video standard like 24/25/30/50/60Hz) and is basically disconnected entirely from triggering and waveform memory.


--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---
--- Quote from: Someone on June 19, 2024, 11:23:21 am ---Maintaining a continuous recording (a la digitiser) falls apart because few scopes have human scales of recording in memory at the full sample rate. Scopes are triggered for a reason. When sample memory is 10x higher than sample rate then it might appear as a feature.
--- End quote ---
That may be.  But I'm not arguing that we should dispense with segments.  I'm arguing that we should dispense with the 1:1 mapping between captures and trigger events, that the display update rate should be defined by the time delay between trigger firings or optionally the time width of the display (whichever is longer, if the time width of the display is considered) even if the capture width is longer than both.
--- End quote ---
Based on your new explanation above this is all getting even more inconsistent:

--- Quote from: kcbrown on June 20, 2024, 09:22:59 pm ---So let's suppose that the mechanism I describe above is in play.  How many bursts you can capture depends on the capture termination conditions and the signal characteristics.  Let's suppose that the data is an active high signal with a maximum high time of 1 us, so just to keep things safe you define a capture termination condition of 10 us after the last trigger (meaning: if 10 us elapses without the trigger firing, the capture stops and the scope prepares to gather a new capture in the remaining memory).  You also define the maximum amount of capture prior to the capture's trigger to be 10 us, using whatever mechanisms are appropriate for that.  So the capture will contain 20 us of padding plus whatever the length of the burst is.  Now each capture ranges between 30 us and 55 us in length.  With 100 ms of capture memory, that amounts to a minimum of 1818 captures, and (if all bursts happen to be of 10 us duration) a maximum of 3333.
--- End quote ---
So you say you want the segments independent of triggers, yet they should be only from triggers + some additional padding before ... and after some definition of "idle".

That padding might be some novel feature but it sounds rather complex to implement and produce a useful UI for that isn't confusing.

Why not just have your segments be larger than your expected largest packet? and position the trigger within that to have pre and post padding? We have this right now and you're asking for some minor improvement over that, at great complexity.


--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---Perhaps another way of saying it is: the waveform update rate should be independent of the capture size.
--- End quote ---
Technically/literally/mathematically/physically impossible.


--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---Maybe I can illustrate my point with a question: suppose you're looking at an SPI bus signal, you've got the display zoomed in so that it's showing a single decoded value, and your trigger is set up so that it fires for every value.  How often will your display refresh to show a new value, and how many decoded values will you acquire in a single capture?
--- End quote ---
That depends on so many variables its impossible to answer (many of those are hidden or stochastic! and can only be determined by testing the specific application).

As far as I can tell you're trying to extend the zoom out nonsense with a new dimension of:
"why cant my scope do both at the same time"
Well, that's because it would need to double/duplicate various parts of the system for this imagined need. Just use two scopes if it's that important to have both high waveform update rate, and a continuous/wide acquisition of the same events.

kcbrown:

--- Quote from: Someone on June 20, 2024, 10:04:28 pm ---Perhaps start with getting the terminology correct. Displays/screens refresh at their own rate (generally some video standard like 24/25/30/50/60Hz) and is basically disconnected entirely from triggering and waveform memory.

--- End quote ---

Apologies.  I meant display update rate, i.e. the rate at which what the display is showing is updated.


--- Quote ---
--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---
--- Quote from: Someone on June 19, 2024, 11:23:21 am ---Maintaining a continuous recording (a la digitiser) falls apart because few scopes have human scales of recording in memory at the full sample rate. Scopes are triggered for a reason. When sample memory is 10x higher than sample rate then it might appear as a feature.
--- End quote ---
That may be.  But I'm not arguing that we should dispense with segments.  I'm arguing that we should dispense with the 1:1 mapping between captures and trigger events, that the display update rate should be defined by the time delay between trigger firings or optionally the time width of the display (whichever is longer, if the time width of the display is considered) even if the capture width is longer than both.
--- End quote ---
Based on your new explanation above this is all getting even more inconsistent:

--- Quote from: kcbrown on June 20, 2024, 09:22:59 pm ---So let's suppose that the mechanism I describe above is in play.  How many bursts you can capture depends on the capture termination conditions and the signal characteristics.  Let's suppose that the data is an active high signal with a maximum high time of 1 us, so just to keep things safe you define a capture termination condition of 10 us after the last trigger (meaning: if 10 us elapses without the trigger firing, the capture stops and the scope prepares to gather a new capture in the remaining memory).  You also define the maximum amount of capture prior to the capture's trigger to be 10 us, using whatever mechanisms are appropriate for that.  So the capture will contain 20 us of padding plus whatever the length of the burst is.  Now each capture ranges between 30 us and 55 us in length.  With 100 ms of capture memory, that amounts to a minimum of 1818 captures, and (if all bursts happen to be of 10 us duration) a maximum of 3333.
--- End quote ---
So you say you want the segments independent of triggers,

--- End quote ---

I didn't say I want the segments to be independent of triggers, I said I want to remove the 1:1 mapping between the two.  Quite obviously, a segment should contain at least one trigger event and should be generated as a consequence of at least one trigger event.



--- Quote ---yet they should be only from triggers + some additional padding before ... and after some definition of "idle".

--- End quote ---

The padding before is something we can already define in scopes currently, and usually get by default: it's all the captured points that precede the trigger that the capture is oriented around.

It's the padding afterwards that we can't currently define in the way I described.  Right now that "padding" is defined relative to the first trigger event in the capture, and what I'm suggesting is that it be optionally defined relative to the last trigger event in the capture.



--- Quote ---That padding might be some novel feature but it sounds rather complex to implement and produce a useful UI for that isn't confusing.

--- End quote ---

Complex to implement?  Perhaps.  It's hard to see how it would be terribly complicated.  It can be as simple as "stop the current capture after X amount of time since the last trigger was seen".

It does mean that captures would then be variable length, whereas right now their length is predefined.  How much of an effect would that have on current implementations?  I simply can't say.



--- Quote ---Why not just have your segments be larger than your expected largest packet? and position the trigger within that to have pre and post padding? We have this right now and you're asking for some minor improvement over that, at great complexity.

--- End quote ---

Because that presumes I know what my largest expected packet will be.  That's not a given, at all, and my original SPI bus example should make that plain.

Moreover, it forces me to sacrifice capture memory, because it forces the capture length of every capture to be the maximum expected length.  And for what?  What benefit do I get from capture memory that contains waveform points that I have no interest in?



--- Quote ---
--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---Perhaps another way of saying it is: the waveform update rate should be independent of the capture size.
--- End quote ---
Technically/literally/mathematically/physically impossible.

--- End quote ---

Really?

If my display width is 1 millisecond, my capture length is 100 milliseconds, and my trigger firing rate is every microsecond, why can't I update the display every 17 milliseconds by shifting the display's time position within the capture by 17 milliseconds (there's clearly no need to update it every millisecond.  17 milliseconds corresponds to 60 Hz), and have the usual intensity grading on the basis of the prior 16 milliseconds worth of waveform?   What's technically/literally/mathematically/physically impossible about that?

What's technically impossible about the trigger firing every time its conditions are met (after the minimal re-arm period, of course), irrespective of the capture size or the display width, and having it activate the external trigger-out line each time?   This already effectively happens for the frequency counter, so clearly that it fires doesn't automatically imply that it has to be used for everything it could be used for, right?


--- Quote ---As far as I can tell you're trying to extend the zoom out nonsense with a new dimension of:
"why cant my scope do both at the same time"

--- End quote ---

Yes, why can't it?  That question is the fundamental basis of all improvements.  That, of course, doesn't necessarily mean that what I'm suggesting is possible (though I don't see how/why it isn't), but if it truly can't do both at the same time, then it would be helpful to know why.



--- Quote ---Well, that's because it would need to double/duplicate various parts of the system for this imagined need.

--- End quote ---

What would need to be duplicated in order to accomplish what I describe?   The display is simply showing some part of the already-captured waveform.  That's the case even with current implementations.  The trigger is simply firing on the basis of acquired points.  That's also the case even with current implementations.  All I'm suggesting is a change in how and when the system displays the waveform, and how and when the system begins a new capture in memory.  So far, it seems the most complicated part is the notion that captures could now differ from each other in length.



--- Quote ---Just use two scopes if it's that important to have both high waveform update rate, and a continuous/wide acquisition of the same events.

--- End quote ---

That's certainly one approach to some of it, but it doesn't address the problem of what to do when you need variable-length captures.  It doesn't address my SPI bus example.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod