I'll cut to the chase with a question: which operations, aside from the intensity grading operation, require processing of all the data in the buffer? Even the FFT doesn't require that.
An FFT on the entire memory depth is extremely useful and desirable,
Perhaps so. But I didn't ask about that. There is a massive difference between desirable (even if extremely so) and
required.
I asked my question the way I did because I want to know what operations of the scope you
cannot properly do at all unless it is on the entire capture buffer. Glitch detection is a good example of that. Min/max processing is another. And triggering is
clearly another.
the Agilent/Keysight X series dont do it and its a limitation of them. As I keep repeating endlessly, take some of the simple display examples and do your own maths on the required computational load. Just min/max to draw the envelope of the deep memory to a smaller display is computationally expensive enough to prove the point. Moving that sort of data throughput in and out of a CPU is not viable, and requires dedicated hardware resources to achieve the peak rates that current products are doing.
Which current products? And what kind of CPU? You'll get no argument from me that as you increase the sample rate, the demands will eventually exceed what even the fastest CPU is capable of. And you'll get no argument from me that an FPGA or ASIC clocked at the same rate as the CPU would be is going to be a faster solution if done right.
The measurement signal enters the oscilloscope at the channel input and is conditioned by attenuators or amplifiers in the vertical system. The analog-to-digital converter (ADC) samples the signal at regular time intervals and converts the respective signal amplitudes into discrete digital values called “sample points”. The acquisition block performs processing functions such as filtering and sample decimation. The output data are stored in the acquisition memory as “waveform samples”.
Why decimate the data before storing it to the acquisition memory instead of after?
That said, the block diagram they supply for the RTO architecture (page 13) is very much like what I'm envisioning here, but the memory implementation I have in mind would be double buffered so as to ensure that display processor reads from acquisition memory never collide with the writes coming from the acquisition engine.
Its almost like you've never used a scope....
You can decimate before writing to the acquisition memory for modes such as min/max, or hi-res, where the ADC samples at a higher rate than you're writing to the sample memory (because of memory limitations and you want a longer record).
Well, okay, sure, but that's not normal acquisition, is it? I was interpreting the paper as talking about the baseline hardware architecture, not just some optional path that would be useful in certain cases.
Losing information for display purposes is unavoidable here. What matters is what the decimation process did to transform the acquired data into something for the display, and that is very operation-specific.
YES, and some similaifcations are appropriate for some applications. But 2D histograms are the benchmark which almost all scopes today provide.
Right. And frankly, it seems to me that the intensity grading processing would be ideal for an FPGA, because it's something the scope would be doing essentially all of the time and it's something that (at least on the surface) seems simple enough to implement.
You dont know in advance which of the samples in the waveform has the interesting information in them, so the scope needs to parse (process) ALL of them. If you knew where the interesting information was then you'd have captured just that part alone.
You're conflating captured data with processed data. The triggering mechanism is what defines the points of interest, and that absolutely has to keep up with the sampling rate. I've never argued otherwise for that. The rest is a matter of how the UI interacts with the rest of the system.
No, thats the Lecroy slight of hand where they have a banner spec for dead time that is only for segmented captures where the data is not going to the screen at that throughput consistently (a tiny fast burst). If the trigger defines what you're interested in then what are you doing with the deep memory?
Capturing the rest of the data so that it can be looked at and even analyzed after the trigger fires, of course. The trigger defines what you're primarily interested in, not the
only thing you're interested in. In some situations, the trigger might actually not be what you're primarily interested in at all, but instead some sort of indicator that what you're interested is nearby.
Look, ultimately the point of all this processing is to put something on the display that's useful to the operator, right? But the nature of what you're displaying is
fleeting, there for only an instant of time and then it's gone, to be replaced by the next refresh. It's why we have persistence settings at all -- we otherwise would miss events of interest.
Those events that are truly of interest are events that you'll not only want to be able to see on the screen, they're events that you'll somehow want to (if only indirectly) trigger the scope with. Glitch detection and display is one of those cases where you have no choice but to process all of the relevant points, but what else
demands that? Even the FFT doesn't, as long as your FFT implementation preserves the (frequency domain) statistical quality of the capture.
You could wind it down to an acquisition depth the same as the screen size which is a trivial display case.
Sure, you could, but if you did that without retaining the original data, then you'd lose the original data and wouldn't be able to stop the scope (most especially automatically as a result of a trigger condition, or mask detection condition, etc.) and then do things like, say, zoom out to see the bigger picture, or pan to see additional parts of the waveform, or do things like decoding of the trace data that isn't within the time window of the display, or a myriad of other things that wouldn't be practical to do on a realtime basis but are easily accomplished once the scope is stopped.
You could even perform an FFT on the entire buffer at that point.
Preserving data gives you options later that you otherwise wouldn't have. More options is better than fewer options, all other things being equal. Since you can always use a subset of captured data for any operation (even intensity-graded display, if it came down to it) in order to preserve operational speed, I see no downside
whatsoever to providing large buffers.
Put another way, if you have a choice between two scopes that have equal processing capability, but one has more memory than the other, why in the
world would you choose the scope that has less memory???
A: you have long memory and capture something interesting to look at later/slower/in depth
B: you want to capture as much information as possible and display it on the screen
Again, what exactly does (B) even mean here? Your display is limited in size. You
have to reduce the data in some way just to show anything
at all.
A is easy, the interface is slow because to draw the XXMpts of memory to the screen takes a long time. Seriously sit down and consider how long a computer would take to read a 100,000,000 point record and just apply the trivial min/max envelope to it for display at 1000px across.
That's an interesting idea, and proved to be an interesting exercise.
It took 6 milliseconds for the min/max computation on that number of points (in other words, just to determine whether each point was within the min/max envelope), with what amounts to a naive approach to the problem (no fancy coding tricks or anything). But once you add in the output buffer code, it rises to about 135 milliseconds. This is on a single core of a 2.6GHz Intel i5. On the one hand, this was just on a single core, and the nature of the operation is such that I'm writing to the same RAM as I'm reading from (which may or may not matter). But on the other hand, the CPU I tested this on, while not the most modern (2014 vintage), is certainly going to be relatively expensive for embedded use.
So operations like this definitely call for an FPGA or execution on multiple CPU cores. They obviously also call for highly optimized approaches to the problem, which my code most certainly wasn't.
For that 100M points to occupy a sample period of 1/30th of a second or less, the sample rate has to be at least 3GS/s. So that's reasonable, but already outside the sample rate of entry-level scopes. Nevertheless, the above is instructive in terms of showing the limits of a naive approach to the min/max processing problem on relatively modern off-the-shelf hardware.
B is where the magic hardware comes in to do all that work in hardware, but it can also run on stopped traces to speed up case A. Thus a better scope for all uses because it has hardware accelerated plotting.
No doubt. It's more efficient at a lot of things, but again, the processing is the bottleneck.
It looks to me like we're saying roughly the same thing (now especially, after the results of the test you had me perform), but for some reason you seem to believe that if you have more memory, then you
have to scale the processing to match. I disagree with that position, if indeed that is your position in the first place. Keep in mind that the OP's question was about why we don't see scopes with big piles of modern off-the-shelf memory.
Home
Help
Search
Login
Register
