Continuing from my last post, Keysight's oscilloscopes with their MegaZoom asic and the million waveform updates per second it empowers, are very cool, but as somebody looking to design and build my own scopes, something still smells funny here.
All of this is still based (for the most part) on the Standard DSO Model (SDSOM) of oscilloscope architecture, which itself is based in significant detail on the operation of electron-beam-slinging analog oscilloscopes. With the technology available these days for building scopes, I'm not so sure that model is really appropriate any more.
Don't get me wrong: I like analog oscilloscopes. I have an ancient Tek alongside my crappy Owon, and for lots of things it is a pleasure to use. But a digital sampled signal analyzer is a different device and although the display of an analog scope is (for many common uses) still pretty much optimal, the path to get there is quite different and maybe it should work differently!
The very idea of Waveform Update Rate as a metric is based on the processing model inherent in the SDSOM, and it is kind of stupid.
First of all, in the era of persistent displays, I am not sure exactly what it even means. Obviously the LCD display itself cannot be updated a million times per second. I guess it amounts to the number of times per second that something could contribute to the display (eventually) shown on the screen? If what we really mean is "triggers processed per second" then we should call it Trigger Rate!
In the SDSOM, the model is basically: Trigger -> Sample -> Update -> Trigger -> Sample -> Update (etc).
Keysight calls the "Update" part, during which data is ignored, "Dead Time". Which sounds about right.
They have moved away from this model in some ways. At least they have gotten rid of the idea of a distinct Capture Buffer that the user needs to fiddle around with to make tradeoffs between captured data and update rate. Old hands used to things working that way may feel a little adrift without that setting, but what a dumb thing to have to think about! I'm not sure exactly how they got rid of it -- maybe they just pick a value that makes sense and hide it all behind the scenes... but I hope it's more than just that.
Consider the Keysight App Note I mentioned last time: (5989-7885EN): "Oscilloscope Waveform Update Rate Determines Probability of Capturing Elusive Events".
"For example, at 2 ms/div the scope's on-screen acquisition time is 20 ms. If a scope had zero dead time, which is theoretically impossible, the absolute best-case waveform update rate would be 50 waveforms per second (1/20 ms)."
I call BS on the thinking behind all of this. It makes sense in the context of the SDSOM, but not so much if we take a step back and think of the problem outside of that architecture. Two reasons for the BS-calling:
1. (Less important) There is no theoretical reason for us not to update more than once during the on-screen acquisition time -- which means triggering more than once during the time the data is displayed. Suppose that the display is showing 5 waveform cycles. There's no theoretical reason we shouldn't trigger 5 times. In the case of a persistent display (or other aggregate view), we would end up redrawing the same data at different places on the screen, but so what? What we want is for the different triggers to be aligned so they can produce a data-rich view, and the fact that one cycle happens to be visible also off on the right of the screen somewhere is irrelevant.
2. Zero dead time is certainly not theoretically impossible if thinking outside the SDSOM; dead time is an artifact of an obsolete architecture. There is no theoretical reason that makes it necessary to stop sampling or stop triggering just because we are busy drawing!
The principle behind these objections, and the basis of an oscilloscope processing model that I want to pursue, is that the sampling, triggering, and display processes are inherently independent (although obviously related) and operate in parallel.
This idea, which is hardly radical, leads me to a sketch of an oscilloscope architecture that I would like to play with. I will present that in my next post.
No comments:
Post a Comment