Oscilloscopes' averaging speed

[mmm22]

The oscilloscope specs usually include the Waveform Update/Refresh Rate (which is not thoroughly defined). I have never seen specs for the acquisition speed in the averaging mode. Do any of the models have such specification? Can it be derived from the Waveform Update/Refresh Rate?

[tautech]

The oscilloscope specs usually include the Waveform Update/Refresh Rate (which is not thoroughly defined).

It is specific to any scopes settings and its ability to push data points through the system at whatever its memory depth is set to and the sampling speed.

I have never seen specs for the acquisition speed in the averaging mode. Do any of the models have such specification? Can it be derived from the Waveform Update/Refresh Rate?

Wfps will divided by the average setting.

Typically the higher the sampling rate the greater chance of detecting a particular trigger setting which is of higher importance than Wfps which need only be pushed from the display buffer to the display fast enough for the display not to flicker.

The things that matter for a DSO are the sampling rate, mem depth, a powerful trigger suite and a fast processor to handle all the data in a timely way so the UI is not laggy.

[Someone]

The oscilloscope specs usually include the Waveform Update/Refresh Rate (which is not thoroughly defined). I have never seen specs for the acquisition speed in the averaging mode. Do any of the models have such specification? Can it be derived from the Waveform Update/Refresh Rate?

Mask testing is an adjacent specification that is more common, but averaging mode is an unusual application so few specifications are produced for it. More confusing is that "averaging" mode might not be average but some sort of IIR filter, and the implementation methods vary wildly from scope to scope.

But as an example, the Keysight X series with their headline update rates drop right back to 10's of kHz in averaging mode. So it pays to test specific devices if this is the bottleneck in your application.

The things that matter for a DSO are the sampling rate, mem depth, a powerful trigger suite and a fast processor to handle all the data in a timely way so the UI is not laggy.

Far too general a concept, I'd say this instead:
The things that matter for a DSO are entirely application specific

[tautech]

The things that matter for a DSO are the sampling rate, mem depth, a powerful trigger suite and a fast processor to handle all the data in a timely way so the UI is not laggy.

Far too general a concept, I'd say this instead:
The things that matter for a DSO are entirely application specific

Not so much with the modern DSO.
When the data passing through the scope is continually pipelined into a History buffer you have it captured, albeit only for a short while if your trigger settings are not correct.
The DSO's feature set be it adequate then determines if it is suitable for any unusual/obscure application.
With the increasing mem depths of new DSO's there is always the option of exporting the captured data for post processing.

[DaJMasta]

Keysight is actually one of the better manufacturers for telling you about acquisition speeds at varying settings (I seem to remember a fair bit of detail on various waveform updates per second), but yeah, this is basically all up to the applications processor in most cases and will be highly variable and probably not specified.

Slower waveform update per second scopes will probably run a larger fraction of their normal update rate in averaging mode because the overhead for doing the average can be done more in the background, whereas a scope that has a very high waveform update rate has to spend a larger portion of its time doing more averages and has less downtime between waveform updates to work.

There may be scopes that have something like this integrated into the memory controller or some fpga before interfacing with the applications processor, but I don't know of them that support this specifically.  If you're looking for smoothness of display, you can always use persistence mode to get the look without actually having to do the math of the averaging, and if you're looking for the resolution enhancements, you could try eres mode for more effective bits taken care of quickly because it can be done with consecutive samples.

I think partly because averaging mode is inherently a less response-oriented display mode, it's not necessarily prioritized... but I don't think I've ever seen it specified.  It could be the kind of thing that a PC based scope wouldn't specify it because increase to system CPU or memory would speed it up anyways, and I would expect a lot of firmwares could probably improved on the speed if they prioritized it.

[SilverSolder]

Agilent (Keysight) had (has?) a high resolution mode when Averaging is set to 1.  (e.g. 5462x/4x)   This mode just averages any excess samples during slower sweep speeds to reduce noise.  Works very well and should - in principle - not affect update speed in any way.

[Someone]

Agilent (Keysight) had (has?) a high resolution mode when Averaging is set to 1.  (e.g. 5462x/4x)   This mode just averages any excess samples during slower sweep speeds to reduce noise.  Works very well and should - in principle - not affect update speed in any way.

Its often a separate acquisition mode "High Resolution" or something similar.

The things that matter for a DSO are the sampling rate, mem depth, a powerful trigger suite and a fast processor to handle all the data in a timely way so the UI is not laggy.

Far too general a concept, I'd say this instead:
The things that matter for a DSO are entirely application specific

Not so much with the modern DSO.
When the data passing through the scope is continually pipelined into a History buffer you have it captured, albeit only for a short while if your trigger settings are not correct.
The DSO's feature set be it adequate then determines if it is suitable for any unusual/obscure application.
With the increasing mem depths of new DSO's there is always the option of exporting the captured data for post processing.

The OP is asking about a very application specific function/capability. When you want to cut through noise the processing capabilities and their throughput are the important characteristics. Exporting and processing the data does not come close to the throughput that the acquisition hardware can achieve. There are still significant architectural differences which can and do impact the choice of scope.

fast processor /= high data throughput

[Someone]

There may be scopes that have something like this integrated into the memory controller or some fpga before interfacing with the applications processor, but I don't know of them that support this specifically.  If you're looking for smoothness of display, you can always use persistence mode to get the look without actually having to do the math of the averaging, and if you're looking for the resolution enhancements, you could try eres mode for more effective bits taken care of quickly because it can be done with consecutive samples.

Eres is adjacent to high resolution acquisition modes, they both reduce measurement noise on a given capture at the expense of bandwidth. Averaging multiple acquisitions reduces noise in the signal correlated to the trigger. If you are trying to see past noise uncorrelated to the trigger then averaging can cut right through that where eres or high resolution would be of no use.

[DaJMasta]

Eres is adjacent to high resolution acquisition modes, they both reduce measurement noise on a given capture at the expense of bandwidth. Averaging multiple acquisitions reduces noise in the signal correlated to the trigger. If you are trying to see past noise uncorrelated to the trigger then averaging can cut right through that where eres or high resolution would be of no use.

Sure, but eres can be implemented without going back through storage memory to do averaging of multiple waveforms, so it's much less likely to decrease performance of the acquisition system and can be done in the memory controller instead of some post processor with access to the sample memory.

Not the same, but you can get similar value from it in some situations.  If you're really after small signal performance, you probably want to be looking for a higher resolution ADC anyways, since that will come along with a lower noise frontend amplifier and you'll get some of the dynamic range you get from averaging without any waveform update per second performance penalty.  1000 waveform updates a second at 12 bits is going to yield a better signal than 10000 waveform updates a second with averaging at 8 bits in terms of detail and low noise filtering - which is what I assume the point of the averaging is for.

[Someone]

Eres is adjacent to high resolution acquisition modes, they both reduce measurement noise on a given capture at the expense of bandwidth. Averaging multiple acquisitions reduces noise in the signal correlated to the trigger. If you are trying to see past noise uncorrelated to the trigger then averaging can cut right through that where eres or high resolution would be of no use.

Sure, but eres can be implemented without going back through storage memory to do averaging of multiple waveforms, so it's much less likely to decrease performance of the acquisition system and can be done in the memory controller instead of some post processor with access to the sample memory.

Not the same, but you can get similar value from it in some situations.  If you're really after small signal performance, you probably want to be looking for a higher resolution ADC anyways, since that will come along with a lower noise frontend amplifier and you'll get some of the dynamic range you get from averaging without any waveform update per second performance penalty.  1000 waveform updates a second at 12 bits is going to yield a better signal than 10000 waveform updates a second with averaging at 8 bits in terms of detail and low noise filtering - which is what I assume the point of the averaging is for.

You keep making statements which are clearly wrong, quite possibly because you still don't understand.
A) more bits is irrelevant if the quantisation noise of the ADC is not what you are trying to see past
B) averaging removes noise that is uncorrelated to the trigger, 10 times more averaging of additive gaussian noise gets a 10^0.5 improvement
More bits, higher decimation, stronger filtering, or lower measurement noise might be what you want for a single shot capture, but thats the exact opposite of averaging. Why keep walking in the opposite direction when the OP specifically asked about averaging?

Eres (or other low pass filtering) works on a capture/acquisition/trace, its doing nothing to remove overlaid noise within its bandwidth, just rejecting noise above it.

[DaJMasta]

But scopes made with 8 bit ADCs do not have the same frontend noise requirements as 10 or 12 bit scopes - you can get rid of the noise uncorrelated to the trigger in averaging, but if your frontend is capable of giving you a similar LSB of noise, you get less of it in a single capture with a higher resolution converter.  The 10 and 12 bit scopes that I'm familiar with on the market have lower noise frontends than their 8 bit counterparts, so you do get better uncorrelated noise performance in practice using a higher resolution scope than even an 8 bit scope with enough eres oversampling to match the number of bits of the higher resolution converters.

Averaging can still be useful on signals who's noise is not dominated by an 8 bit scope's frontend, yes, ok, but how many applications are seeing that?  And moreover, how many of them rely on very fast averaging to try to reduce noise on the input signal in a particularly snappy manner?  It's far more likely that the frontend noise or the quantization noise of the scope dominates the noise in the signal.


As I said before, the alternatives are not a catch-all for every application, but I didn't read the OP as explicitly needing a fast averaging mode without specifying a use case that needed it over other forms of noise reduction or increased resolution, so I suggested options that could yield similar or better results in most use cases that you could use averaging mode for as a stopgap or alternative.  I stand by my recommendations because for the vast majority of situations, they will get you results in the same direction averaging mode can offer without having to worry about the waveform updates per second when averaging, which is typically (always?) unspecified.  If the use case still requires averaging to see your tiny signal in the larger noise floor (why are you using a scope for this?), the things I mentioned can still be useful, but then maybe the (largely unmeasured) performance figure matters.  And if you really are looking for that much averaging to see your signal of interest.... your effective integration time to see it starts increasing until it's actually over the processing time for a single screen update, so then you're limited by the integration time of the sampling instead of the update speed of the scope.

[Someone]

But scopes made with 8 bit ADCs do not have the same frontend noise requirements as 10 or 12 bit scopes - you can get rid of the noise uncorrelated to the trigger in averaging, but if your frontend is capable of giving you a similar LSB of noise, you get less of it in a single capture with a higher resolution converter.  The 10 and 12 bit scopes that I'm familiar with on the market have lower noise frontends than their 8 bit counterparts, so you do get better uncorrelated noise performance in practice using a higher resolution scope than even an 8 bit scope with enough eres oversampling to match the number of bits of the higher resolution converters.

More averaging = more suppression of noise uncorrelated to the trigger which is the opposite of what you said, do we need to quote it again? If you want to start with different amounts of noise in the signals its not really a comparison, or talk about measurement noise dominating, again something entirely different to in band signal noise.

Averaging can still be useful on signals who's noise is not dominated by an 8 bit scope's frontend, yes, ok, but how many applications are seeing that?  And moreover, how many of them rely on very fast averaging to try to reduce noise on the input signal in a particularly snappy manner?  It's far more likely that the frontend noise or the quantization noise of the scope dominates the noise in the signal.

Removing inband noise in a signal is the "magic" function of averaging. Its a well accepted technique that has been used in various forms but only came to oscilloscopes after the digital transition.

You keep talking about out of band noise, which is something entirely different. You aren't wrong about those capabilities but you keep saying they are replacements and doing the same thing as averaging which is very very very.....    very incorrect. They are radically different and applied in different applications.

As I said before, the alternatives are not a catch-all for every application, but I didn't read the OP as explicitly needing a fast averaging mode without specifying a use case that needed it over other forms of noise reduction or increased resolution,

The OP mentions averaging performance and nothing else.

so I suggested options that could yield similar or better results in most use cases that you could use averaging mode for as a stopgap or alternative.  I stand by my recommendations because for the vast majority of situations, they will get you results in the same direction averaging mode can offer without having to worry about the waveform updates per second when averaging, which is typically (always?) unspecified.  If the use case still requires averaging to see your tiny signal in the larger noise floor (why are you using a scope for this?), the things I mentioned can still be useful, but then maybe the (largely unmeasured) performance figure matters.  And if you really are looking for that much averaging to see your signal of interest.... your effective integration time to see it starts increasing until it's actually over the processing time for a single screen update, so then you're limited by the integration time of the sampling instead of the update speed of the scope.

You talk about your narrow experiences of using these tools, and haven't a clue about their wider use in more specialised applications. The OP put forward a very succinct question and you've walked off in the other direction shouting about how clever you are and know what they actually need to hear....

while being wrong on the actual technical points.

Still going to keep going? Shall we start referencing?

[nctnico]

But scopes made with 8 bit ADCs do not have the same frontend noise requirements as 10 or 12 bit scopes - you can get rid of the noise uncorrelated to the trigger in averaging, but if your frontend is capable of giving you a similar LSB of noise, you get less of it in a single capture with a higher resolution converter.  The 10 and 12 bit scopes that I'm familiar with on the market have lower noise frontends than their 8 bit counterparts, so you do get better uncorrelated noise performance in practice using a higher resolution scope than even an 8 bit scope with enough eres oversampling to match the number of bits of the higher resolution converters.

Averaging can still be useful on signals who's noise is not dominated by an 8 bit scope's frontend, yes, ok, but how many applications are seeing that?  And moreover, how many of them rely on very fast averaging to try to reduce noise on the input signal in a particularly snappy manner?  It's far more likely that the frontend noise or the quantization noise of the scope dominates the noise in the signal.


As I said before, the alternatives are not a catch-all for every application, but I didn't read the OP as explicitly needing a fast averaging mode without specifying a use case that needed it over other forms of noise reduction or increased resolution, so I suggested options that could yield similar or better results in most use cases that you could use averaging mode for as a stopgap or alternative.  I stand by my recommendations because for the vast majority of situations, they will get you results in the same direction averaging mode can offer without having to worry about the waveform updates per second when averaging

Sorry but you really are wrong here. High-res/Eres is something completely different compared to averaging. High-res/Eres work in the frequency domain where averaging works in the time domain. Some situations call for averaging (to get rid of random noise on repetitive signals) and other situations call for High-res (to get rid of HF noise). In the end High-res/Eres are just sloppy sample rate dependent low-pass signal filters.

To get back to the OPs question: the number of averages per second an oscilloscope reaches depends highly on how the averaging is implemented and I don't recall seeing it being specified. Averaging might be implemented in hardware or done in software. And there can also be a difference in whether the averaging is done on acquired data or decimated data.

[mmm22]

Thank you guys for all your suggestions.
It might help if I clarify my application. I need to make a quantitative measurement on the fast signal (a few ns) which is quite noisy but repetitive (~10kHz). That is why I need averaging, preferably all 10kwfms per second.
I tried to use TDS3032B which has specs for update rate 3600wfms/s. But the max averaging speed I could get was only about 1kwfms/s.
I am looking now at the InfiniiVision 1000 X-Series Oscilloscopes, which has waveform update rate 100+kwfms/s, but the averaging speed is not specified. Any idea what to expect?
It also has Gb Ethernet, which might make it possible to transfer every wfm to computer; but again no specs for the real data speed.

[mmm22]

"Mask testing is an adjacent specification that is more common, but averaging mode is an unusual application so few specifications are produced for it."
So should the mask testing speed be approximately same as the averaging speed?

[nctnico]

Thank you guys for all your suggestions.
It might help if I clarify my application. I need to make a quantitative measurement on the fast signal (a few ns) which is quite noisy but repetitive (~10kHz). That is why I need averaging, preferably all 10kwfms per second.
I tried to use TDS3032B which has specs for update rate 3600wfms/s. But the max averaging speed I could get was only about 1kwfms/s.
I am looking now at the InfiniiVision 1000 X-Series Oscilloscopes, which has waveform update rate 100+kwfms/s, but the averaging speed is not specified. Any idea what to expect?

Keysight likely does averaging on decimated data. It probably can keep up though. To know for sure I'd get an oscilloscope on loan. Maybe look at Lecroy too as Lecroy's oscilloscope are geared towards signal analysis.

[Someone]

Mask testing is an adjacent specification that is more common, but averaging mode is an unusual application so few specifications are produced for it. More confusing is that "averaging" mode might not be average but some sort of IIR filter, and the implementation methods vary wildly from scope to scope.

So should the mask testing speed be approximately same as the averaging speed?

That was an example of a more common application, while it is more likely to have specifications but even they are vague/hard to compare.

Thank you guys for all your suggestions.
It might help if I clarify my application. I need to make a quantitative measurement on the fast signal (a few ns) which is quite noisy but repetitive (~10kHz). That is why I need averaging, preferably all 10kwfms per second.
I tried to use TDS3032B which has specs for update rate 3600wfms/s. But the max averaging speed I could get was only about 1kwfms/s.
I am looking now at the InfiniiVision 1000 X-Series Oscilloscopes, which has waveform update rate 100+kwfms/s, but the averaging speed is not specified. Any idea what to expect?

Keysight likely does averaging on decimated data. It probably can keep up though. To know for sure I'd get an oscilloscope on loan. Maybe look at Lecroy too as Lecroy's oscilloscope are geared towards signal analysis.

Likely? With it labelled as an acquisition mode its very unlikely to be a post processing step. Its almost certainly running in the hardware at full sample rate as it is operating on the entire memory depth (for that bit depth, which is the same depth as min/max mode) and that isn't visible to the downstream processing.

Yes, averaging can be offered as a post processing step and thats the way Lecroy do it (as is traditional with all their processing), it has advantages and disadvantages.

I am looking now at the InfiniiVision 1000 X-Series Oscilloscopes, which has waveform update rate 100+kwfms/s, but the averaging speed is not specified. Any idea what to expect?

The 1000X doesn't have a trigger out so its harder to estimate the update rate, but the larger scopes using the same ASIC may not be any faster than your existing choice. It depends on the specific horizontal timebase settings, memory depth, etc. The fastest I have ever seen any of those series run averaging is just under 30k/s and that is only with a short memory depth.

As above, the only real way to find out is to test a range of devices you think might be suitable, or ask your distributor to make some tests/inquiries, or ask the manufacturers for the performance figures.

[2N3055]

I made a test with my 3000T.

3 ns pulse with 10 kHz repetition rate.  at 20 ns/div, normal ACQ mode, on trig out full 10 kHz.
BUT, if I set average ACQ mode, it is STILL 10 kHz....
It seems to be doing running average. Meaning, there is no slowdown in acq rate, but latency in result after change.
Latency will be proportional to number of averages and timebase, of course.

At 200 ns/div normal ACQ, trigger rate is still 10kHz, but average ACQ drops to 1.7 kHz (at 1024 averages)
So there is a slowdown here.
It is highly dependent on settings. If OP would give exact settings, I have no problem running scenario to verify exactly how fast 3000T would be.

[mmm22]

I made a test with my 3000T.

3 ns pulse with 10 kHz repetition rate.  at 20 ns/div, normal ACQ mode, on trig out full 10 kHz.
BUT, if I set average ACQ mode, it is STILL 10 kHz....
It seems to be doing running average. Meaning, there is no slowdown in acq rate, but latency in result after change.
Latency will be proportional to number of averages and timebase, of course.

At 200 ns/div normal ACQ, trigger rate is still 10kHz, but average ACQ drops to 1.7 kHz (at 1024 averages)
So there is a slowdown here.
It is highly dependent on settings. If OP would give exact settings, I have no problem running scenario to verify exactly how fast 3000T would be.

Thank you for the offer but 3000T is too expensive for this application; I need something like 1000 X-series.
BTW, what is the sample rate at 200ns/div? The 3ns pulse might be missed with this setting. Otherwise I don't see why the averaging speed should depend on the time resolution setting, as well as on the number of averages. It will depend though on the sample depth.

[2N3055]

I made a test with my 3000T.

3 ns pulse with 10 kHz repetition rate.  at 20 ns/div, normal ACQ mode, on trig out full 10 kHz.
BUT, if I set average ACQ mode, it is STILL 10 kHz....
It seems to be doing running average. Meaning, there is no slowdown in acq rate, but latency in result after change.
Latency will be proportional to number of averages and timebase, of course.

At 200 ns/div normal ACQ, trigger rate is still 10kHz, but average ACQ drops to 1.7 kHz (at 1024 averages)
So there is a slowdown here.
It is highly dependent on settings. If OP would give exact settings, I have no problem running scenario to verify exactly how fast 3000T would be.

Thank you for the offer but 3000T is too expensive for this application; I need something like 1000 X-series.
BTW, what is the sample rate at 200ns/div? The 3ns pulse might be missed with this setting. Otherwise I don't see why the averaging speed should depend on the time resolution setting, as well as on the number of averages. It will depend though on the sample depth.

Not a problem. 1000-X uses same ASIC, so it might point to an architecture of scope.
Sampling rate is 5GS/s up until 20us/div (2MS mem in run mode, single ch) or so.  Funny thing is that although in normal mode scope always gets full memory (when you stop sampling while at 200ns/div, you can "zoom out " a will see that scope actually acquired 400 us worth of data. But in average mode that is not available, and if you zoom out you see only the length that was on screen in time of acquisition.

I don't have insider info, but it seems it averages full acquired data, but only length of screen, which will result in more data to crunch as you go slower timebase. Also it is not clear if hardware based (in ASIC) but slow, or it is software based function. Anyways not spectacular performance.


Let me ask you: do you need this to be continuous process (interactive), or could you grab dataset, process data, decide on result.
If you could do it offline, using deep mem scope and segments, and then average segments with each other, would pretty much guarantee 100% pulse intercept (no blind time at all), and you could massage data at your will..

[mmm22]

Let me ask you: do you need this to be continuous process (interactive), or could you grab dataset, process data, decide on result.
If you could do it offline, using deep mem scope and segments, and then average segments with each other, would pretty much guarantee 100% pulse intercept (no blind time at all), and you could massage data at your will..

The X-series of scopes have Gb Ethernet. Do you have any experience of the real speed of data transfer to computer?

[gf]

I need to make a quantitative measurement on the fast signal (a few ns) which is quite noisy but repetitive (~10kHz). That is why I need averaging, preferably all 10kwfms per second.

This alone does not explain the need for a high averaging rate, though. If the signal is really repetitive, then it does not mater if you miss some of the repetitions, but is is sufficient if the capture buffers from N triggered/non-missed repetitions are averaged eventually.

Btw, you also said that the signal is very noisy. Is the SNR good enough then to obtain a stable trigger, with sufficiently low trigger-jitter? Prerequisite for averaging is that you can trigger the signal.

[mmm22]

I need to make a quantitative measurement on the fast signal (a few ns) which is quite noisy but repetitive (~10kHz). That is why I need averaging, preferably all 10kwfms per second.

This alone does not explain the need for a high averaging rate, though. If the signal is really repetitive, then it does not mater if you miss some of the repetitions, but is is sufficient if the capture buffers from N triggered/non-missed repetitions are averaged eventually.

Btw, you also said that the signal is very noisy. Is the SNR good enough then to obtain a stable trigger, with sufficiently low trigger-jitter? Prerequisite for averaging is that you can trigger the signal.

I have an external trigger which is stable.
Since the signal is noisy, it is not 'really' repetitive. So I do need averaging.

[gf]

I have an external trigger which is stable.

Since the signal is noisy, it is not 'really' repetitive. So I do need averaging.

What do you mean with "not really repetitive"?
Averaging basically requires that the waveform is always the same whenever the trigger fires
(or at least the waveform's "region of interest" should be the same).
Is this granted?
If yes, then it does not matter if some of the triggers are missed during averaging
(unless the total number of repetitions were limited).

[JDubU]

I just did a test with a Siglent SDG2042X signal generator driving a Keysight 1000x scope.
The signal generator is set to pulse waveform, 16.3nS pulse width (narrowest available). 10KHz rep rate, 1Vpp.
White noise was optionally added via channel combining.  The added noise signal is  1V (std deviation), band limited to max 120MHz by the anti-alias filter of the signal generator.

Screenshots are attached.

The scope does a rolling average so, even at 65536 averages, the update rate is visibly dynamic (the 1000x does not have trigger output so I can't quantify the visible waveforms per second).
I did the same test on my Rigol DS2000 with nearly identical results.  The only noticeable difference between the Rigol and the Keysight was when changing the time base which forces the scope to do a new averaging sequence instead of a rolling one.  On the Keysight, the re-average is visibly almost instantaneous  (probably hardware).  On the Rigol, the re-average time is dependent on the number of averages (clearly software averaging).  Even then, it takes only a few seconds at the maximum 8192 averages.