Oscilloscopes are cool.
As I tinker with ideas for designing and building them, I've been reading about some existing scopes, and (as a result) have also been lusting after the Keysight (nee Agilent nee HP) InfiniVision X-series scopes. Pretty awesome stuff! And also a great example of technological advancement: By rethinking the model of how a Digital Storage Oscilloscope (DSO) works, they came up with a fundamentally new design which led to breakthrough performance improvements.
They are a little (well, a lot) out of my price range, but if I am going to build something I'd like to build something snazzy, so it's a great source for inspiration.
I became curious about how performance of a scope is measured. Besides obvious things like sampling speed and fidelity, and analysis feature lists, a very interesting performance metric is the fraction of incoming data a scope can actually process. I was a little surprised by this, but it does make sense: a scope only looks at a fraction of the incoming data.
I came across a clearly-written App Note from Keysight (5989-7885EN): "Oscilloscope Waveform Update Rate Determines Probability of Capturing Elusive Events". It got me thinking... but first, let me describe the Standard DSO Model (SDSOM), which is closely related to how analog oscilloscopes work, and is still dominant -- especially on crappy cheap scopes like the Owon I have on my bench:
A scope display shows a particular length of time, expressed in time-units per "div", where a div is a gridded section of the display. Typically there might be ten divs visible horizontally on the screen. This rate is called the "timebase" and is one of the most important settings on a scope. The user will crank the timebase knob to see an amount of time that gives a good view on whatever signal she is investigating. For example, a timebase setting of 10 microseconds per div (in my example here) would result in 100 microseconds of data being shown on the screen.
In the SDSOM, the timebase determines the sample rate. If we need to show 10us of data per div and a div is 50 pixels wide, a sample time of 10us/50 = 200ns (5 million samples per second) makes everything nice and easy.
In the simple normal case, some kind of little analog circuit that is watching the signal generates a pulse when a trigger occurs (because, e.g. the voltage passes some threshold). The scope sees that pulse, says "AHA! Something interesting!" It shuts off the triggering circuitry (because it doesn't want more triggers while busy processing this one) and begins sampling. It grabs a certain amount of data and stops sampling. That data (which I will call a Capture Buffer; not sure what the standard term is) gets stored in memory. At a minimum, it should be big enough to fill the screen (100us in my example), but it is usually bigger so you can scroll around to see more data if you want to after the fact. Usually you can select the capture buffer size yourself, or use some default size selected automatically based on the available memory or whatever.
Still following the SDSOM, once the samples are secured in memory, the scope scans through the portion of the memory corresponding to the screen and fills a display buffer with a bunch of lines graphing that sample data, and also updates display elements related to the captured data. It then updates the physical display with the contents of the display buffer. Having done all of this, the scope is ready for more data, so it turns the trigger circuitry back on and waits for a new trigger pulse.
See that it takes time between getting the sample data and re-enabling the trigger. Any triggers that occur while the trigger circuit is disabled cannot be processed. So the performance metric is: how much data is unavalable due to processing overhead?
The answer, in general, is: almost all of it. Really. The scope only "sees" a tiny fraction of the incoming data.
You can measure this if your scope has a "trigger output" which sends an electrical pulse out a port whenever a trigger occurs. On a low-end scope like my Owon, you might get a maximum of 50 triggers per second, give or take. I don't really like this measurement method because it is kind of fiddly. To maximize the rate you have to set the capture buffer to the minimum size available to minimize the time spent sampling -- THAT data shouldn't be counted as "lost" since it is available for viewing and analysis.
So in our example, we can capture 100us of data 50 times per second and the rest is ignored: 5ms of data per second processed means 995ms of data per second ignored: over 99%! And if our timebase was 100ns instead of 10us (implying a sample rate of something like 500MSPS), the trigger rate is still only around 50 per second max... meaning that 99.995% of the data is ignored.
It seems to be normal to call this trigger-processing rate the "Waveform Update Rate" -- which makes sense because it sort of means: how often can the stuff shown on the screen be updated?
I'm certain that even cheap scopes could do better than that if they tried harder, but is it something we even care about? So what if only a little bit of the data gets processed? It's a constant stream so there is always as much data as we can possibly display coming in anyway.
There's at least two reasons we might care: First, if we can display more data on the screen somehow, then we really do want more data available to display. More expensive and capable scopes have methods like "persistence" which can actually display the data from multiple triggers on the display at the same time (mimicking the phosphor persistence of analog scopes). That is useful because you can see the variation between different waveforms (and it looks super cool too if it is done right).
Second, and related, has to do with rare events. Often we use an oscilloscope to help debug hardware that shows flaky behavior, which may occur becuse of occasional glitches or rare variations in the waveforms. If a glitch happens once a second on average and we only see 1/1000 of the data, we'd have to wait 1000 seconds on average to capture it, which is a pain in the ass.
But finding these glitches (and subsequently analyzing them) requires scope features that the cheapest scopes don't have (even if they did capture all the data): how do you find the weird wave? With a persistent display as mentioned before, it would stay visible long enough to actually see it instead of being overwritten 1/50 second after it was drawn. The other option is to have fancier triggering mechanisms capable of distinguishing the glitch from a normal waveform. Since (for example) my Owon really doesn't have any of that capability, there isn't much motivation to optimize the waveform update rate. Eh.
But the Keysight scopes do have those abilities: very sophisticated triggering AND a gorgeous persistent display. So it matters to them. Still for scopes like that a waveform update rate of something in the ballpark of 10,000 per second has been pretty normal, which sounds pretty awesome! At that rate, the processing overhead for each sample/update cycle is only a tenth of a millisecond! But still, especially on fast timebases, the vast majority of the data comes in during those tenths of milliseconds.
The Keysight scopes can do up to a million waveform updates per second! They do this with custom chips and other macho engineering, and it's one of the reasons they are so cool.
Amazingly, though, in common cases, even at a million updates per second 90% of the data is still unprocessed. Maybe that's still a pity and maybe it's not too bad... only the rarest glitches become super painful to wait for when 1/10 of them get seen. So thumbs up to Keysight!
But... something still bothers me about all this. I'll write about that in my next post.
No comments:
Post a Comment