the eternal question about rigol vs siglent

[rhb]

In general, unless  the noise is a zero mean Gaussian process, averaging will distort the waveform. I apologize for not being interested enough to go through all the many probability density functions to enumerate those which are not zero mean.

A Gaussian assumption is often, but not always valid.

A cheap DSO in good hands can do amazing things.  The Owon XDS1202A will give a skilled user over a 100 dB dynamic range.  However, you will need to understand discrete time signal processing to get that level of performance.  And be able to implement the required operations.

I am pleased to see that Siglent got scalar network analysis correct.  That increasingly inclines me to get an SDS1104X-E and do a comparison of Rigol, Instek, Owon and Siglent entry level DSOs against a Tek 485, LeCroy DDA-125/LC684DLX and Tek 11801.  Every one of those can do things which the others cannot.  And all (except for the 485) of them have FW features which are incorrectly written.

[rf-loop]

All you did was say that it has a 1 mV/div to 10V/div range, which is entirely meaningless for this discussion.

And you did not even note what they did not tell... and it was point (of course)

I think it is also important to observe what has not been said.

Is it meaningless that Rigol do not give any info that there is no true 1mV or 2mV/div but they are magnification from 5mV/div range.

But then you take example how Decent manufacturers like Keysight are good because they tell.

Perhaps you forget this your own or do you tell now that all this is also meaningless.

Decent manufacturers like Keysight put the following warning in their manuals: "1 mV/div and 2 mV/div is a magnification of 4 mV/div setting..."

[gf]

In general, unless  the noise is a zero mean Gaussian process, averaging will distort the waveform. I apologize for not being interested enough to go through all the many probability density functions to enumerate those which are not zero mean.

A Gaussian assumption is often, but not always valid.

The PDF does not really matter.

Averaging is a linear operation, i.e. we can treat averaging of the noise component and averaging of the wanted signal component separately, and then add the two results.

Averaging N copies of the (non-random) wanted signal component y(t) still results in y(t) - that's identity - there won't be any distortion per se.

Non-zero mean of the noise is not really an issue either - it's just a DC offset, but does not affect the waveform's shape otherwise. For averaging the AC noise component, the Central Limit Theoerm applies. If more and more independent randeom variables are added (ragardless of their PDF), the PDF of the sum tends toward a Gaussian distribution, i.e. the resdiual noise after averaging will be closer to Gaussion and will have a lower standard deviation than before averaging.

However, the wanted signal component gets indeed distorted, when the N averaged copies are not exactly time-aligned, due to triggering jitter, which is predominantly a consequence of the noise as well. Low-pass finltering of the trigger path may help. An even better alignment could be achieved by calculating cross correlation and finding the time offset which gives the best match of the waveforms - but that's computationally expensive.

[rhb]

In general, unless  the noise is a zero mean Gaussian process, averaging will distort the waveform. I apologize for not being interested enough to go through all the many probability density functions to enumerate those which are not zero mean.

A Gaussian assumption is often, but not always valid.

The PDF does not really matter.

Averaging is a linear operation, i.e. we can treat averaging of the noise component and averaging of the wanted signal component separately, and then add the two results.

Averaging N copies of the (non-random) wanted signal component y(t) still results in y(t) - that's identity - there won't be any distortion per se.

Non-zero mean of the noise is not really an issue either - it's just a DC offset, but does not affect the waveform's shape otherwise. For averaging the AC noise component, the Central Limit Theoerm applies. If more and more independent randeom variables are added (ragardless of their PDF), the PDF of the sum tends toward a Gaussian distribution, i.e. the resdiual noise after averaging will be closer to Gaussion and will have a lower standard deviation than before averaging.

However, the wanted signal component gets indeed distorted, when the N averaged copies are not exactly time-aligned, due to triggering jitter, which is predominantly a consequence of the noise as well. Low-pass finltering of the trigger path may help. An even better alignment could be achieved by calculating cross correlation and finding the time offset which gives the best match of the waveforms - but that's computationally expensive.

Your statements assume a noise process with a flat spectrum.  Many noise processes such as 1/f noise do not have flat spectra.  If your assertions were correct the seismic processing community would not have spent millions of dollars developing the huge suite of noise suppression algorithms that are in current use.

 I suggest buying a copy of:

Random Data
Bendat  & Piersol
4th ed Wiley 2010

That has been my primary reference for classical Wiener signal processing since I bought the 2nd edition in the late 80's.

Time aligning multiple sweeps is actually trivially simple.  I plan to write software to do the process below to increase the dynamic range of TDR traces collected with a DSO and pulse generator to perform vector network analysis up to the BW of the DSO.  With a 12 bit trace from an Owon XDS2102A a single 20 Mpt trace will provide over 100 dB of dynamic range.  With an 8 bit ADC one simply needs more samples.

Segment the record into individual sweeps

Zero pad to 2x or longer and Fourier transform

Perform a linear fit to the phase

Average the  phases

Apply phase shifts to each sweep to shift it to the average phase

Sum the transforms but do not divide by the number of sweeps.

Inverse transform

Every doubling of the number of sweeps yields an extra 6 dB of dynamic range

[Fungus]

A Gaussian assumption is often, but not always valid.

In this particular case it seems most of the noise is internal to the scope so the assumption is valid (or very very close to valid).

More important is that the ripple waveform is truly periodic with zero modulation. You should use the waveform record/playback functions to confirm this before enabling average mode.

Of course averaging doesn't make sense in most cases, but then again, neither does this measurement. The premise of using a plain scope without an amplifier for a low noise measurement is bonkers to begin with.

That doesn't stop it from being trotted out in every single "Rigol vs. Siglent" thread.

As we've seen today though, the Rigol doesn't have as much noise as the Siglent boys like to pretend. Their famous screenshot turned out to be just a pathological comination of the Rigol decimation combined with measurements based on screen date. Twist the timebase knob to a more "natural" value and it vanishes

(which most people will do, as soon as you see noise on screen the natural temptation is to zoom in a bit for a closer look).

[gf]

Your statements assume a noise process with a flat spectrum.

I'm assuming uncorrelated noise, where each sample is randomly drawn from a given PDF, indepedent of previously drawn samples. Seems to be a reasonable assumption/approximation for the kind of noise being decussed (i.e. the wide band noise floor of scopes).

Time aligning multiple sweeps is actually trivially simple.

I agree, but FFT costs quite some computing resources. My understanding is that usually the "averaging acquisition mode" simply aligns those points in time, where the trigger did happen to fire. That's computationally much cheaper (-> just average the buffers as acquired). But given a noisy signal, the trigger does not necessarily fire at the same point of the waveform for each acquisition.

[Rerouter]

In order to raise 500uV/div (which is about 5mV pp full-scale) to the ADC's 2V pp full-scale input voltage, a gain of 400V/V is required. If the VGA is limited to ~50V/V, then either an additional amp stage were required, or the ADC still needs to be operated with digital gain

Ok, I'll pay there, so 5mV input scale,  default VGAC is x17.8, so 89mV scale, the ADC also has a x50 internal amplifier, but we only need to use it with a gain of about x20 to get a scale of 1.78V, seems this may be how they have done it.

[gf]

In order to raise 500uV/div (which is about 5mV pp full-scale) to the ADC's 2V pp full-scale input voltage, a gain of 400V/V is required. If the VGA is limited to ~50V/V, then either an additional amp stage were required, or the ADC still needs to be operated with digital gain

Ok, I'll pay there, so 5mV input scale,  default VGAC is x17.8, so 89mV scale, the ADC also has a x50 internal amplifier, but we only need to use it with a gain of about x20 to get a scale of 1.78V, seems this may be how they have done it.

My understanding is that the HMCAD1511 does not have an internal (analog) amplifier, but it rather has a higher (more than 8 bits) internal ADC resolution, and a digital multiplier between ADC core and digital output. It never outputs more than 8 bits, though. Implementation details are not given in the datasheet.

This feature is based on the fact that the HMCAD1511, though it is an 8-bit converter, has  more resolution available in its core circuitry. This means that although the SNR available to the user is limited by the quantization noise floor of an 8-bit converter, the actual noise floor deep within the ADC’s core is significantly lower than that.
...
SNR in dBc starts to degrade rapidly  beyond  digital  gain of 10x, so the user is advised to keep the digital gain setting at 10x or less.

[rhb]

I will post some screen dumps later of the Instek SA app with the inputs terminated in 50 ohms.  The noise is not even remotely "flat".

I invite anyone with a Siglent to do the same, especially below 1 MHz.  The Rigol will require transferring the data to a PC.

The averaging I described  may not be practical on a DSO.  I'll know a lot more once I've developed the FOSS DSO FW stack I'm working on.

I'm fed up with crappy FW on DSOs even from the A list OEMs.  I think the best way to address that is to run the exact same tests on multiple low end DSOs and put them out for all to see.

[Rerouter]

rhb, if you can better explain what setup you want things measured under, I can likely do it, my crude understanding is your asking for an FFT of the noise?

[gf]

I will post some screen dumps later of the Instek SA app with the inputs terminated in 50 ohms.  The noise is not even remotely "flat".

I invite anyone with a Siglent to do the same, especially below 1 MHz.  The Rigol will require transferring the data to a PC.

I find the noise floor of my cheap Chinese scope white enough (see attachment).

EDIT: Id did try various sampling rates, down to 1kSPS, but the picture did not change significantly.

But I'm not sure what you're really after. Even if it were not white - so what. Averaging does not make pink noise white, but it still reduces its amplitude.

[ BTW: The two peaks at fs/2 and fs/4 are ADC interleaving spurs. ]

[rhb]

Yes.  Plot the FFT of the noise at various sampling rates. 

In particular look at the FFT of the noise with a 2 MSa/s sample rate.  That's where you will see all  the SMPS noise.  But you will find strong spurs at a wide range of frequencies.  Average as many noise traces as you can using auto triggering and and a 10k to 100k record length.  There is a tradeoff between longer records which give finer RBW and shorter records which give lower variance estimates.

[Rerouter]

Here you go, Have fun, At shorter Tdiv the samples start decreasing, but feel it covers what your asking for.

[nctnico]

Averaging makes only sense, IMO, if the signal is periodic and if you have a stable trigger. Then it decreases the random noise and retains the non-random components of the signal.

Leave the IMHO out. Averaging will only work well on a purely periodic signal.

Hi-res, on the other hand, is basically oversampling + decimation with a box filter. So it does neither require a periodic signal, nore a stable trigger.

Which is why the GDS1054B is such a good choice: it has input filtering so you can throw out any part of the frequency domain you are not interested in.

[rhb]

@rerouter Thank you!  That is precisely my point.  Those spectra are anything but white.  The issue with the spectrum @gf posted was the variance of the spectral estimate was too large to show the problem.

Your plots show that Siglent has done a much better at suppressing SMPS noise than Goodwill Instek. However, I should note that there is no way to know how many of the spurs are internal and how many are environmental EMI.  I've had huge problems with conducted mode EMI radiating from the power lines.

You just sold a Siglent SDS1104X-E!  That and the Bode plots of crystal resonance will make it easy to hold several Chinese OEM's feet in the fire.  I have no preference.  My goal is to force the OEMs to improve their products.  After 37 years  of DSP I know how to break almost everything.  And the rest just require more thought.  TANSTAFL.

@nctnico  Averaging is only guaranteed to work if the underlying noise process is zero mean Gaussian.  This is abused so much I refer to it as "sprinkling Gauss water on the problem".

[nctnico]

@RHB: I think you are mistaken averaging and oversampling. Averaging just serves as a low pass filter. For oversampling you'll need Gaussian noise and a linear ADC (which usually isn't the case).

[rhb]

c.f. Bendat & Piersol

[gf]

That is precisely my point. Those spectra are anything but white.

I think I understand your desire now - you were interested in the non-random noise components injected somehow into the front end.

Overall, I'd say that the white noise power still dominates in the posted figures. But that's the nice thing of FFT, given enough sampes, it can pick out small periodic signal components from a swamp of random noise

[gf]

Averaging just serves as a low pass filter.

"Perfect" averaging is per se not a low-pass filter operator. The blurring effect is IMO caused by imperfections, namely by small time mis-alignment of the acquisitions being averaged.

[gf]

Averaging is only guaranteed to work if the underlying noise process is zero mean Gaussian.

What exactly do you mean with "work"?
Which properties must the averaging fulfil in order that you call it "working"?

[ If the only aim is to make the central limit theorem apply, then i.i.d. (i.e. white noise) should be sufficient. ]

[nctnico]

Averaging just serves as a low pass filter.

"Perfect" averaging is per se not a low-pass filter operator. The blurring effect is IMO caused by imperfections, namely by small time mis-alignment of the acquisitions being averaged.

The question is whether these imperfections are actually visible given the resolution of the oscilloscope display and ADC resolution.

[Rerouter]

If you really wanted a filter, you can still use the Fourier transform to act as what ever filter coefficient you want, you just loose a lot on the update rate to do it as it means more processing.

Technically its not outside the capability of these devices to do an after the fact arbitrary type of filter, There is defiantly software room to run it, though no idea if the existing FFT function blocks in the FPGA could be re purposed to speed it up.

rhb if you really are looking into open source firmware development. well there is a request.

[rhb]

I simply wanted to point out some fine points of mathematics that are being blurred with a sprinkle of Gauss water.  I'll let anyone interested in a refresher course consult Bendat & Piersol.

There is nothing wrong with trace averaging.  I use it all the time.  But I am also acutely aware of its limitations. 

The FOSS DSO FW stack for Zynq and Cyclone V FPGAs I am working on will permit applying an arbitrary set of operations to the input traces a la LeCroy, low pass, high pass, band pass and band reject, trace integration, etc.  But don't hold your breathe.  I'm 1/2 way through "VLSI DSP Systems" by K.K. Parhi and will need to make a second pass.  There are a lot of transformations for speeding up DSP that do not appear in general purpose CPUs.  So despite having read the first 3 editions of Patterson and Hennessy over the years, there are a lot of considerations that are new and will require considerable study.

I have a lot of reading to do before I go back to reading the books on FPGA implementations of DSP on FPGAs and Zynq and Cyclone V documentation.  Faced with somewhere in excess of 10,000 pages of text to navigate, I'm getting very concerned about how I find things when I want to recheck my memory of what they said.  The various aspects of this project are much more tightly coupled than what I've done in the past.

[gf]

"Perfect" averaging is per se not a low-pass filter operator. The blurring effect is IMO caused by imperfections, namely by small time mis-alignment of the acquisitions being averaged.

The question is whether these imperfections are actually visible given the resolution of the oscilloscope display and ADC resolution.

When I trigger a noisy signal, and the trigger is basically stable, but the displayed waveform still jitters a little bit horizontally around the nominal trigger point, then I'm inclined to say that I can see this jittering.

This timing jitter leads to mis-aligned averaging of acquisitions (when averaging is turned on), which in turn makes averaging behave like a convolution. That's IMO the indirection how the low-pass filter effect develops which you did associate with averaging initially.

[tautech]

When I trigger a noisy signal, and the trigger is basically stable, but the displayed waveform still jitters a little bit horizontally around the nominal trigger point, then I'm inclined to say that I can see this jittering.

But it's not, it's the trigger re-triggering on a non-repetitive waveform.
Perfectly normal.

To address this we either change the Holdoff and/or engage other trigger conditions to get stable triggering.
A not perfectly stable waveform doesn't matter to much for general scope work but for accurate consistent measurements it does.

An example, related to triggering on a glitch but using some tricks to find it, trigger on it and find its repetitive frequency using Search:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg1370717/#msg1370717