Oscilloscopes' averaging speed - Page 1
Forum section: electronics / testgear

author: mmm22
author_rank: Regular Contributor
timestamp: April 15, 2020, 04:25:47 pm
content: 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?

author: tautech
author_rank: Super Contributor
timestamp: April 15, 2020, 08:40:48 pm
content: Quote from: mmm22 on April 15, 2020, 04:25:47 pmIt 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.QuoteWfps 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.

author: Someone
author_rank: Super Contributor
timestamp: April 15, 2020, 11:47:19 pm
content: Quote from: mmm22 on April 15, 2020, 04:25:47 pmMask 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.Quote from: tautech on April 15, 2020, 08:40:48 pmFar too general a concept, I'd say this instead:The things that matter for a DSO areentirely application specific

author: tautech
author_rank: Super Contributor
timestamp: April 16, 2020, 01:38:47 am
content: Quote from: Someone on April 15, 2020, 11:47:19 pmNot 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.

author: DaJMasta
author_rank: Super Contributor
timestamp: April 16, 2020, 01:39:22 am
content: 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.

author: SilverSolder
author_rank: Super Contributor
timestamp: April 16, 2020, 02:18:04 am
content: 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.

author: Someone
author_rank: Super Contributor
timestamp: April 16, 2020, 03:36:06 am
content: Quote from: SilverSolder on April 16, 2020, 02:18:04 amIts often a separate acquisition mode "High Resolution" or something similar.Quote from: tautech on April 16, 2020, 01:38:47 amThe 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

author: Someone
author_rank: Super Contributor
timestamp: April 16, 2020, 03:59:29 am
content: Quote from: DaJMasta on April 16, 2020, 01:39:22 amEres 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.

author: DaJMasta
author_rank: Super Contributor
timestamp: April 16, 2020, 05:28:23 am
content: Quote from: Someone on April 16, 2020, 03:59:29 amSure, 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.

author: Someone
author_rank: Super Contributor
timestamp: April 16, 2020, 07:10:56 am
content: Quote from: DaJMasta on April 16, 2020, 05:28:23 amYou 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 pastB) averaging removes noise that is uncorrelated to the trigger, 10 times more averaging of additive gaussian noise gets a 10^0.5 improvementMore 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.

author: DaJMasta
author_rank: Super Contributor
timestamp: April 16, 2020, 07:06:21 pm
content: 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.

author: Someone
author_rank: Super Contributor
timestamp: April 16, 2020, 10:56:35 pm
content: Quote from: DaJMasta on April 16, 2020, 07:06:21 pmMore 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.Quote from: DaJMasta on April 16, 2020, 07:06:21 pmRemoving 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.Quote from: DaJMasta on April 16, 2020, 07:06:21 pmThe OP mentions averaging performance andnothing else.Quote from: DaJMasta on April 16, 2020, 07:06:21 pmYou 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?

author: nctnico
author_rank: Super Contributor
timestamp: April 16, 2020, 11:00:09 pm
content: Quote from: DaJMasta on April 16, 2020, 07:06:21 pmSorry 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 18, 2020, 01:23:24 pm
content: 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 18, 2020, 02:33:07 pm
content: "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?

author: nctnico
author_rank: Super Contributor
timestamp: April 18, 2020, 02:45:56 pm
content: Quote from: mmm22 on April 18, 2020, 01:23:24 pmKeysight 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.

author: Someone
author_rank: Super Contributor
timestamp: April 18, 2020, 11:28:05 pm
content: Quote from: mmm22 on April 18, 2020, 02:33:07 pmThat was an example of a more common application, while it is more likely to have specifications but even they are vague/hard to compare.Quote from: nctnico on April 18, 2020, 02:45:56 pmLikely? With it labelled as an acquisition mode its veryunlikelyto 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.Quote from: mmm22 on April 18, 2020, 01:23:24 pmThe 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.

author: 2N3055
author_rank: Super Contributor
timestamp: April 19, 2020, 12:03:51 am
content: 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 19, 2020, 11:54:24 am
content: Quote from: 2N3055 on April 19, 2020, 12:03:51 amThank 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.

author: 2N3055
author_rank: Super Contributor
timestamp: April 19, 2020, 01:41:12 pm
content: Quote from: mmm22 on April 19, 2020, 11:54:24 amNot 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..

author: mmm22
author_rank: Regular Contributor
timestamp: April 19, 2020, 02:31:37 pm
content: Quote from: 2N3055 on April 19, 2020, 01:41:12 pm

author: gf
author_rank: Super Contributor
timestamp: April 19, 2020, 02:49:10 pm
content: Quote from: mmm22 on April 18, 2020, 01:23:24 pmThis 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 19, 2020, 03:13:16 pm
content: Quote from: gf on April 19, 2020, 02:49:10 pmI have an external trigger which is stable.Since the signal is noisy, it is not 'really' repetitive. So I do need averaging.

author: gf
author_rank: Super Contributor
timestamp: April 19, 2020, 03:35:48 pm
content: Quote from: mmm22 on April 19, 2020, 03:13:16 pmQuote from: mmm22 on April 19, 2020, 03:13:16 pmWhat 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).

author: JDubU
author_rank: Frequent Contributor
timestamp: April 19, 2020, 03:45:32 pm
content: 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 19, 2020, 04:12:32 pm
content: Quote from: gf on April 19, 2020, 03:35:48 pmWhy 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 19, 2020, 04:15:04 pm
content: Quote from: JDubU on April 19, 2020, 03:45:32 pmThanks 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.

author: gf
author_rank: Super Contributor
timestamp: April 19, 2020, 04:20:55 pm
content: Quote from: mmm22 on April 19, 2020, 04:12:32 pmI 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.

author: JDubU
author_rank: Frequent Contributor
timestamp: April 19, 2020, 04:27:34 pm
content: Quote from: mmm22 on April 19, 2020, 04:15:04 pmIt 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 19, 2020, 04:35:15 pm
content: Quote from: JDubU on April 19, 2020, 04:27:34 pmDoes 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.

author: JDubU
author_rank: Frequent Contributor
timestamp: April 19, 2020, 04:42:13 pm
content: Quote from: mmm22 on April 19, 2020, 04:35:15 pmI 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.

author: MarkL
author_rank: Unknown
timestamp: April 19, 2020, 05:52:11 pm
content: Quote from: mmm22 on April 19, 2020, 04:35:15 pmI 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.

author: Someone
author_rank: Super Contributor
timestamp: April 19, 2020, 11:26:37 pm
content: Quote from: mmm22 on April 19, 2020, 04:15:04 pmBecause 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).

author: MarkL
author_rank: Unknown
timestamp: April 20, 2020, 02:50:02 am
content: Quote from: Someone on April 19, 2020, 11:26:37 pmAs 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.

author: Someone
author_rank: Super Contributor
timestamp: April 20, 2020, 07:44:32 am
content: Quote from: MarkL on April 20, 2020, 02:50:02 amA 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:..............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

author: MarkL
author_rank: Unknown
timestamp: April 20, 2020, 04:37:36 pm
content: Quote from: Someone on April 20, 2020, 07:44:32 amThat 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.0002 0.5003 0.3334 0.2505 0.1886 0.1417 0.1058 0.0799 0.05910 0.04411 0.03312 0.02513 0.01914 0.01415 0.011The 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.QuoteThanks - I thought something funny was going on there. It was skipping triggers long before I expected when going above 20ns/div.

author: Someone
author_rank: Super Contributor
timestamp: April 20, 2020, 11:44:31 pm
content: Quote from: MarkL on April 20, 2020, 04:37:36 pmShame 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.Quote from: MarkL on April 20, 2020, 04:37:36 pmThe 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).

author: mmm22
author_rank: Regular Contributor
timestamp: April 21, 2020, 01:26:07 pm
content: Quote from: MarkL on April 19, 2020, 05:52:11 pmI 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?

author: 2N3055
author_rank: Super Contributor
timestamp: April 21, 2020, 03:06:02 pm
content: 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 21, 2020, 05:21:29 pm
content: Quote from: 2N3055 on April 21, 2020, 03:06:02 pmIt 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)?

author: 2N3055
author_rank: Super Contributor
timestamp: April 21, 2020, 05:36:55 pm
content: Quote from: mmm22 on April 21, 2020, 05:21:29 pm70MHz 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 transferBut, that would be good question for Siglent support. Present them with use case and ask for help..

author: mmm22
author_rank: Regular Contributor
timestamp: April 21, 2020, 06:22:41 pm
content: Quote from: 2N3055 on April 21, 2020, 05:36:55 pmI meant to compare with EDUX1052A which is $480 and has Gb Ethernet so theoretically it is possible to transfer every wfm.

author: MarkL
author_rank: Unknown
timestamp: April 21, 2020, 06:39:01 pm
content: Quote from: mmm22 on April 21, 2020, 01:26:07 pmIt 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.QuoteSomeone 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.

author: mmm22
author_rank: Regular Contributor
timestamp: April 21, 2020, 07:13:12 pm
content: Quote from: MarkL on April 21, 2020, 06:39:01 pmDownloading 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.

author: tautech
author_rank: Super Contributor
timestamp: April 21, 2020, 07:22:01 pm
content: 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/

author: nctnico
author_rank: Super Contributor
timestamp: April 21, 2020, 07:25:23 pm
content: Quote from: mmm22 on April 21, 2020, 06:22:41 pmUnfortunately not. The transfer rate depends highly on the internal processor power of the oscilloscope. Gb ethernet in itself says nothing.

author: mmm22
author_rank: Regular Contributor
timestamp: April 21, 2020, 09:14:05 pm
content: Quote from: nctnico on April 21, 2020, 07:25:23 pmDo you say that from experience with this particular series of scopes, or the internal processor model?

author: mmm22
author_rank: Regular Contributor
timestamp: April 22, 2020, 11:16:29 am
content: Quote from: tautech on April 21, 2020, 07:22:01 pmThank 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.

author: tautech
author_rank: Super Contributor
timestamp: April 22, 2020, 11:54:32 am
content: 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)

author: mmm22
author_rank: Regular Contributor
timestamp: April 22, 2020, 12:36:46 pm
content: Quote from: tautech on April 22, 2020, 11:54:32 amI 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.

author: MarkL
author_rank: Unknown
timestamp: April 22, 2020, 11:47:16 pm
content: mmm22: One thing that you haven't really mentioned is the bandwidth needed for your measurement. It will be a major factor in deciding on a scope.You mentioned early-on a pulse of few nanoseconds, and that you want a "quantitative" measurement. What value are trying to quantify? Amplitude? Edge speed? Decay? Timing in relation to another signal?For example, the TDS3032B that you mentioned is 300MHz. The Keysight EDUX1052A that you later mentioned is only 50MHz. On the latter, you'll see a pulse of only few ns as a lump. It will be greatly attenuated and with little detail. You'll at least get closer to an actual amplitude on the TDS3032B, but it will still not show you much detail.I think if you described what you were trying to do, or at least provided an example waveform and what you were trying to accurately measure on it and how often, you might get more congruent answers from this thread's participants.

author: mmm22
author_rank: Regular Contributor
timestamp: April 23, 2020, 07:31:08 am
content: Quote from: MarkL on April 22, 2020, 11:47:16 pmI am mostly interested to measure the integral of the pulse, so I guess 50MHz should be still fine for a few ns pulse.