Oscilloscopes' averaging speed

[mmm22]

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).

Why the waveform needs to be always the same? In this case, averaged waveform will be just the same as every single wfm.
The total number of repetitions is surely limited, because the time you can spend on averaging is limited.

[mmm22]

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  1Vpp, 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.

Thanks for the measurements.
I didn't understand why on Keysight the re-averaging is almost instantaneous. 65536 averages at 10kHz repetition should take 6.5s.

[gf]

Why the waveform needs to be always the same? In this case, averaged waveform will be just the same as every single wfm.

I mean the useful component of the signal is supposed to be the same, while the random noise is of course different in each captured frame. Then the averaged waveform will be the useful component of the signal, with a lower amount of random noise.

[JDubU]

Thanks for the measurements.
I didn't understand why on Keysight the re-averaging is almost instantaneous. 65536 averages at 10kHz repetition should take 6.5s.

It may be that it is displaying the intermediate averages as it goes. It actually doesn't take many averages to get close to the same appearance as the maximum averages.
Screenshot of 128 averages is attached.

[mmm22]

Thanks for the measurements.
I didn't understand why on Keysight the re-averaging is almost instantaneous. 65536 averages at 10kHz repetition should take 6.5s.

It may be that it is displaying the intermediate averages as it goes. It actually doesn't take many averages to get close to the same appearance as the maximum averages.
Screenshot of 128 averages is attached.

Does Keysight has the Single Sequence mode like Tektronix (that is the acquisition will stop after collecting 65536 wfms)? In this case you can see the time it takes to acquire all the samples.

[JDubU]

Does Keysight has the Single Sequence mode like Tektronix (that is the acquisition will stop after collecting 65536 wfms)? In this case you can see the time it takes to acquire all the samples.

I have not seen that option on the Keysight 1000x.

Correction:  Most Keysight DSOX scopes do have segmented memory mode, but I think that even the highest end ones don't do more than 1000 segments.

[MarkL]

...
Does Keysight has the Single Sequence mode like Tektronix (that is the acquisition will stop after collecting 65536 wfms)? In this case you can see the time it takes to acquire all the samples.

I don't think it can be done from the front panel, but if the 1000X behaves like the 3000X series, the ":DIGitize" command will return after the set number of averages are taken.

You could set a pulse generator to send exactly 65536 pulses @10kHz and see if ":DIGitize" completes.  I needed to use 20ns/div to avoid loss on a 3000X.  Anything longer and there's too much dead time.  My ancient pulse generator only does bursts up to 1999, so I only tested averaging up to 1024.

I was expecting the ":WAVeform:PREamble?" to conveniently return the number of waveforms actually processed (averaged), but it does not work that way, at least on a 3000X.


EDIT:  A simplification of the test is to submit the ":DIGitize" command to the scope (via USB-TMC for the 1000X; I used Ethernet on the 3000X).  You can just watch the front panel for completion status.  ":DIGitize" will start the acquisition and the scope will go to Run (green).  Send the 65536 pulses.  The scope should then return to Stop (red).  If it doesn't, it missed one or more pulses.

While it's not a direct measurement of averaging speed, if it is missed some pulses you can play with the various settings to find the actual maximum.

PS - There appears to be a bug in the 3000X that if it's powered up in Averaging mode it won't display any waveforms at all.  It seems to require at least one acquisition in Normal mode before Averaging works properly.  Dunno if this quirk exists in the 1000X.  FYI.

[Someone]

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  1Vpp, 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.

Thanks for the measurements.
I didn't understand why on Keysight the re-averaging is almost instantaneous. 65536 averages at 10kHz repetition should take 6.5s.

Because its not an average, the "averaging" mode is an IIR filter that weights the most recent captures more heavily. After clearing the first capture is taken at 100% weight to start building the "average" and the rest are applied at some fraction (controlled by the average length/count).

If every capture and weighing them equally is important than you'll need to look at other scopes or methods. Its a trade off between fast processing with a less perfect result and slow processing, where your application sits with an optimum noise reduction is entirely based on its specifics (3nS pulses are a new piece of information you added).

[MarkL]

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  1Vpp, 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.

Thanks for the measurements.
I didn't understand why on Keysight the re-averaging is almost instantaneous. 65536 averages at 10kHz repetition should take 6.5s.

Because its not an average, the "averaging" mode is an IIR filter that weights the most recent captures more heavily. After clearing the first capture is taken at 100% weight to start building the "average" and the rest are applied at some fraction (controlled by the average length/count).

If every capture and weighing them equally is important than you'll need to look at other scopes or methods. Its a trade off between fast processing with a less perfect result and slow processing, where your application sits with an optimum noise reduction is entirely based on its specifics (3nS pulses are a new piece of information you added).

As a quick test, I did a 1024 average of a DC level on a Keysight 3000X.  The first 512 captures were at 0.000V and the second 512 were at 1.000V.  The resulting average waveform was 0.49995V.

Clearly the Keysight must be doing an IIR since it's updating the waveform in real-time and you can watch the noise being averaged out, but the above results indicate it is NOT weighted and the resulting waveform is a true average over the given number of captures.

Again, this is on a 3000X, but I would expect the 1000X to have the same behavior since it is also based on the Megazoom ASIC.

I recall reading that some LeCroy models have a programmable weighted average.


EDIT: I'll go a step further and say that as long as the capture count has not been reached, the Keysight does not necessarily have to apply an IIR filter.  The ASIC can simply compute the true average from a running sum and send it off to the display.  Once the final capture count is reached, if the sweeps are to continue, it can start to apply an IIR to decay the older values.

[Someone]

As a quick test, I did a 1024 average of a DC level on a Keysight 3000X.  The first 512 captures were at 0.000V and the second 512 were at 1.000V.  The resulting average waveform was 0.49995V.

Clearly the Keysight must be doing an IIR since it's updating the waveform in real-time and you can watch the noise being averaged out, but the above results indicate it is NOT weighted and the resulting waveform is a true average over the given number of captures.

Again, this is on a 3000X, but I would expect the 1000X to have the same behavior since it is also based on the Megazoom ASIC.

I recall reading that some LeCroy models have a programmable weighted average.

EDIT: I'll go a step further and say that as long as the capture count has not been reached, the Keysight does not necessarily have to apply an IIR filter.  The ASIC can simply compute the true average from a running sum and send it off to the display.  Once the final capture count is reached, if the sweeps are to continue, it can start to apply an IIR to decay the older values.

A bit of experimentation later confirms your idea, the averaging builds linearly for the first n captures (displaying progress as it goes which requires normalising) and once it overflows the average count it then runs in IIR mode. Clearing the display readies it to count the next n acquisitions into the average. The UI has no way to automatically stop like it can with segmented captures, it would be interesting to know if the digitise command accurately/reliably stops at the final accumulation acquisitions, rather than having to implement a burst limit to the DUTs triggers.

.. also noticed there is some added dead time on the triggers in averaging mode at the LCD frame rate, and the first two captures are directly back to back without a significant overhead.

Code: [Select]

..............Trigger...Trigger.....(processing averaging) ........ Trigger .....(processing averaging) ........ Trigger .....(processing averaging) ........ Trigger .....(much much much loooooonger delay during offloading to screen ) ........ Trigger .....(processing averaging) ........ Trigger ...... etc

[MarkL]

...
A bit of experimentation later confirms your idea, the averaging builds linearly for the first n captures (displaying progress as it goes which requires normalising) and once it overflows the average count it then runs in IIR mode. Clearing the display readies it to count the next n acquisitions into the average. The UI has no way to automatically stop like it can with segmented captures, it would be interesting to know if the digitise command accurately/reliably stops at the final accumulation acquisitions, rather than having to implement a burst limit to the DUTs triggers.

That was a good idea to check if the digitize command stops at the exact count.  The answer is that it doesn't.  Looking at the trigger out, the 3000X overshoots anywhere from about 50 to 200 waveforms, no matter what the number of averages is set to.

This was further confirmed by doing one capture of DC 1.000V, changing to 0.000V, and then letting the pulse generator free-run.  With Averaging set to 128, the result should have been 1/128 = 7.8mV, but it was always less.  An exact burst of 128 did produce the correct result of 7.8mV.

So, the 3000X can keep up with the mmm22's averaging requirements, with the caveat that the result will contain *at least* 65536 samples.  I could not find a command that would return the exact count, if that quantity is important to whatever is being measured.

Obviously this still needs to be confirmed on actual 1000X hardware.  If the overshoot is not acceptable, some external electronics could be constructed to gate 65536 triggers into the scope, or simply find a different scope that can stop at the exact count.


On a side note, while I had this set up, I did look at the algorithm they're using a bit more and it confirms what we're both saying.  Just using the regular Run mode and Avergaing set to 4, I captured one DC waveform at 1.000V, changed to 0.000V, and then triggered the pulse generator manually while measuring the average trace.  Here are the readings:
   N     Avg
  ---  ------
   1    1.000
   2    0.500
   3    0.333
   4    0.250
   5    0.188
   6    0.141
   7    0.105
   8    0.079
   9    0.059
  10    0.044
  11    0.033
  12    0.025
  13    0.019
  14    0.014
  15    0.011

The first 4 captures are clearly a straight average.  But once the Averaging count is exceeded at N==5, the algorithm starts decaying the value at a rate of 3/4.  I didn't play with it further, but it's no doubt:

  NewAvg = NewPoint/4 + (3/4 * OldAvg)

Or more generally, where N is the Averaging setting:

  NewAvg = NewPoint/N + ( (N-1)/N * OldAvg )

Which is a simple and common IIR.  Any overshoot captures will drop into this mode.  As long as mmm22's waveform is truly repetitive, it will have no effect on the result.

.. also noticed there is some added dead time on the triggers in averaging mode at the LCD frame rate, and the first two captures are directly back to back without a significant overhead.

Code: [Select]

..............Trigger...Trigger.....(processing averaging) ........ Trigger .....(processing averaging) ........ Trigger .....(processing averaging) ........ Trigger .....(much much much loooooonger delay during offloading to screen ) ........ Trigger .....(processing averaging) ........ Trigger ...... etc

Thanks - I thought something funny was going on there.  It was skipping triggers long before I expected when going above 20ns/div.

[Someone]

...
A bit of experimentation later confirms your idea, the averaging builds linearly for the first n captures (displaying progress as it goes which requires normalising) and once it overflows the average count it then runs in IIR mode. Clearing the display readies it to count the next n acquisitions into the average. The UI has no way to automatically stop like it can with segmented captures, it would be interesting to know if the digitise command accurately/reliably stops at the final accumulation acquisitions, rather than having to implement a burst limit to the DUTs triggers.

That was a good idea to check if the digitize command stops at the exact count.  The answer is that it doesn't.  Looking at the trigger out, the 3000X overshoots anywhere from about 50 to 200 waveforms, no matter what the number of averages is set to.

Shame there isn't a "linear or circular" acquisition option like there is for the segmented mode, I'd only ever run averaging on free running triggers and never noticed that it could do this numerically correct accumulation mode.

Obviously this still needs to be confirmed on actual 1000X hardware.  If the overshoot is not acceptable, some external electronics could be constructed to gate 65536 triggers into the scope, or simply find a different scope that can stop at the exact count.

The 1000x is identical, checked it with similar tests. But the problem with the non-constant dead time makes it hard to ensure the triggers are counted correctly (no trigger out on the 1000x to close the loop) unless they are way below the peak rate (which defeats the purpose).

[mmm22]

via USB-TMC for the 1000X; I used Ethernet on the 3000X

I thought 1000X also have Gb Ethernet, don't they?
BTW, what is the real data speed of the Gb Ethernet? I.e., what is the max wfms/s that can be transferred to computer without loss?

[2N3055]

Why do you insist on Keysight 1000 series? It is not very good choice for this.

Get Siglent SDS2352X-E, and capture 10000 trigger events in segments with no dead time (meaning every single one), and download the lot in one go.
Then average it all in one pass.

[mmm22]

Why do you insist on Keysight 1000 series? It is not very good choice for this.

Get Siglent SDS2352X-E, and capture 10000 trigger events in segments with no dead time (meaning every single one), and download the lot in one go.
Then average it all in one pass.

It is twice as expensive, although still not prohibitively so.
Do you have an idea how long it would take to download 10k waveforms (of the shortest depth available)?

[2N3055]

Why do you insist on Keysight 1000 series? It is not very good choice for this.

Get Siglent SDS2352X-E, and capture 10000 trigger events in segments with no dead time (meaning every single one), and download the lot in one go.
Then average it all in one pass.

It is twice as expensive, although still not prohibitively so.
Do you have an idea how it would take to download 10k waveforms (of the shortest depth available)?

70MHz DSOX 1202 is allmost 690€+tax,  350 Mhz SDS2352X-E is 720€+tax. Siglent comes with up to 14x more memory, 350 MHz, all decode protocols etc..and up to 80000 segents compared to 500 max...
Unfortunately no, I don't have information how fast is Ethernet transfer
But, that would be good question for Siglent support. Present them with use case and ask for help..

[mmm22]

Why do you insist on Keysight 1000 series? It is not very good choice for this.

Get Siglent SDS2352X-E, and capture 10000 trigger events in segments with no dead time (meaning every single one), and download the lot in one go.
Then average it all in one pass.

It is twice as expensive, although still not prohibitively so.
Do you have an idea how it would take to download 10k waveforms (of the shortest depth available)?

70MHz DSOX 1202 is allmost 690€+tax,  350 Mhz SDS2352X-E is 720€+tax. Siglent comes with up to 14x more memory, 350 MHz, all decode protocols etc..and up to 80000 segents compared to 500 max...
Unfortunately no, I don't have information how fast is Ethernet transfer
But, that would be good question for Siglent support. Present them with use case and ask for help..

I meant to compare with EDUX1052A which is $480 and has Gb Ethernet so theoretically it is possible to transfer every wfm.

[MarkL]

via USB-TMC for the 1000X; I used Ethernet on the 3000X

I thought 1000X also have Gb Ethernet, don't they?

It seems that some of the earlier models of 1000X don't have a LAN port, and the later 1200X and 1000X-EDU models do.  I did look for "LAN" and "Ethernet" in the 1000 X-Series User Manual before posting that.  I see now the other models have a different User Manual.  Sorry for the misleading info.

BTW, what is the real data speed of the Gb Ethernet? I.e., what is the max wfms/s that can be transferred to computer without loss?

Someone with a 1000X (or should we say 1200X/EDU) would need to measure that.

Is wfms/s download important in your scenario?  If you allow the scope to do the average for you, in your example you're only downloading one waveform once every 6.5 seconds.  You can also select how many points (horizontal) you want in the downloaded waveform.

If you're only interested in a few ns of pulse, how much of the rest of the waveform do you need to download?  For example, if you want a 200ns waveform from end to end, and the EDUX1052 acquires 1GSa/s, that's only 200 points, or 400 bytes to download (not counting headers).

If you really want continuous download of every waveform every 1/10k of a second, that's a completely different problem.

[mmm22]

Is wfms/s download important in your scenario?  If you allow the scope to do the average for you, in your example you're only downloading one waveform once every 6.5 seconds.  You can also select how many points (horizontal) you want in the downloaded waveform.

If you're only interested in a few ns of pulse, how much of the rest of the waveform do you need to download?  For example, if you want a 200ns waveform from end to end, and the EDUX1052 acquires 1GSa/s, that's only 200 points, or 400 bytes to download (not counting headers).

If you really want continuous download of every waveform every 1/10k of a second, that's a completely different problem.

Downloading every wfm would be great of course since it would allow me to calculate some statistics, as well as to avoid the unclear averaging algorithms inside the scope (IIR etc.).
Gb Ethernet theoretically should allow for that. I would be happy with 200points/wfm.

[tautech]

Pushing the scopes info out over LAN at any sort of speed is not trivial as a DSO's architecture is typically not designed for this. You should find some interesting reading here:
https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/

[nctnico]

I meant to compare with EDUX1052A which is $480 and has Gb Ethernet so theoretically it is possible to transfer every wfm.

Unfortunately not. The transfer rate depends highly on the internal processor power of the oscilloscope. Gb ethernet in itself says nothing.

[mmm22]

I meant to compare with EDUX1052A which is $480 and has Gb Ethernet so theoretically it is possible to transfer every wfm.

Unfortunately not. The transfer rate depends highly on the internal processor power of the oscilloscope. Gb ethernet in itself says nothing.

Do you say that from experience with this particular series of scopes, or the internal processor model?

[mmm22]

Pushing the scopes info out over LAN at any sort of speed is not trivial as a DSO's architecture is typically not designed for this. You should find some interesting reading here:
https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/

Thank you for the link. I found a speed test for SDS1204X-E there (https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/msg1394796/?topicseen#msg1394796) which results in "With the benchmark feature I'm getting ~1100 requests/s via TCP/VXI11". Does it mean it is possible to transfer 1100wfms/s?
Also, maybe you have some extra information about the Siglent scopes performance in terms of averaging speed.

[tautech]

It can only be done with detailed analysis unfortunately. Not only are there maximum LAN requests to consider but also wfps that alone can vary dramatically with timebase and display settings and even mem depth can have a effect on how fast a DSO can process the data.
It is an interesting subject to then drop averaging into the equation.

Some enlightenment might come for an old table from rf-loop with now quite old FW in a SDS1202X-E from which the 4 channel SDS1*04X-E evolved. (Unable to find his later SDS1204X-E table)

[mmm22]

It can only be done with detailed analysis unfortunately. Not only are there maximum LAN requests to consider but also wfps that alone can vary dramatically with timebase and display settings and even mem depth can have a effect on how fast a DSO can process the data.
It is an interesting subject to then drop averaging into the equation.

Some enlightenment might come for an old table from rf-loop with now quite old FW in a SDS1202X-E from which the 4 channel SDS1*04X-E evolved. (Unable to find his later SDS1204X-E table)

I wonder how the 'Sequence mode guaranteed segments/s speed' was measured. Is it just from the trigger out rate, or the data can be really downloaded/averaged at this speed?
It is also quite counter-intuitive to see the segm/s speed rising with rising pts/segment size when below 700points/segm.