Siglent SDS800X HD Review & Demonstration Thread

[Performa01]

Identity

Since the SDS800X HD is an extremely affordable package, some corners had to be cut, one of them being the signal samples rendered as clusters of two vertical pixels (because of the limited amount of block RAM in the Xilinx Zynq FPGA).

While this hardly poses constraints to our everyday tasks, there might still be situations where we want to get the maximum visual resolution for certain measurements. This is where the math channels come into play.

The Identity function returns the original acquisition data, whereas the Average function is the preferred choice for repetitive signals, because it reduces (also) the 1/f-noise and increases the resolution, hence enables us to produce clean traces even from very noisy signals.


SDS824X HD_Math_Zoom_Identity_Avg16

The screenshot shows a 12 MHz square wave with 1 ns rise time. Zoom mode has been engaged to take a closer look at the rising edge overshot details.

The channel 4 trace is always 2 pixels high, so it appears thicker than the math traces.

Math trace F2 plots the Identity function, which is basically the same as channel 4, but uses the full screen resolution, hence looks nicer.

Math trace F3 plots the a 16x Average of the signal in channel 4. It reduces the noise and increases the vertical resolution to 16 bits.

If we want to show the math trace(s) exclusively, e.g. for documentation purposes, we can hide the original signal trace in the corresponding channel menu.

EDIT: added the reason for this restriction to the 1st paragraph.

[tautech]

 
Played with something similar today while testing some current probes of which one when set to highest sensitivity was very noisy.
Averaging ( Math) had to be engaged to get readings close to actual.

[ebastler]

Thank you for demonstrating the full-resolution display via Math function, Performa01!

I think Siglent could make the Math traces look even smoother if they rendered a change in value not via a "stair step", but via a proper diagonal step. See the lazy ASCII "illustration" below -- stair step on the left, diagonal on the right.

The hardware channels are actually rendered (by the FPGA?) with diagonal steps. The Math traces are rendered (by the CPU?) with full vertical resolution, but with the stair steps -- which emphasizes the discrete steps, makes them appear a bit brighter, and makes the curves look more jagged than necessary in my opinion. Assuming the rendering is done on the CPU side, this should be easily changed -- maybe worth a try to make the screen look its best?

Code: [Select]

       XXXXXX        XXXXXX
    XXXX          XXX
 XXXX          XXX

Edit: Hmm, that ASCII art looks less than convincing. Here's a more realistic example: In Performa01's screenshot, I removed the "stair steps" from the red Math trace. It does look smoother than the blue one, and certainly better than the original red trace a few posts above -- not a huge effect, but worthwhile in my opinion.

[capslock]

Is there any idea why they implemented it this way? It is hard to imagine this is dictated my hardware, and hence necessary from a cost saving point of view. It sound more like an oversight in programming to me.

[ebastler]

Is there any idea why they implemented it this way? It is hard to imagine this is dictated my hardware, and hence necessary from a cost saving point of view. It sound more like an oversight in programming to me.

The double-pixels in the traces for physical channels are due to a hardware limitation, as mentioned by Performa01 above and explained in a bit more detail here: https://www.eevblog.com/forum/testgear/siglent-sds3000x-hd-and-upgraded-sds1000x-hd/msg5341286/#msg5341286

For the stair-step rendering of the math traces, I can't imagine a hard constraint which would force Siglent to do it that way. It might just have been the "first draft" implementation of the curve rendering, and then never got questioned?

[Performa01]

Noise Density

In my previous test

https://www.eevblog.com/forum/testgear/sds800x-hd-review-demonstration-thread/msg5293744/#msg5293744

I used a constant sample rate of 100 MSa/s, which allowed a 2 Mpts FFT with an effective FFT-sample rate of 50 MSa/s and Δf = 23.84 Hz. This was required, since the FFT in the SDS800X HD is limited to 2 Mpts max. and I wanted to measure the 1/f noise down to at least 100 Hz. As a consequence, I had to set up the FFT in a way that I get a frequency step (Δf) well below that.

Of course, if we want any accuracy in the spectrum plot, the Flattop window has to be used, and the RBW is Δf * 3.73 in case of Siglent’s version of the Flattop Window.

Because of the low sample rate of just 100 MSa/s for the acquisition, there will inevitably be aliasing, folding back all the noise above 50 MHz to the first Nyquist zone. Then there will be even more aliasing because the FFT introduces one more decimation step, from 100 to 50 MSa/s. The latter could be countered by a digital filter, but it doesn't make that much of a difference anymore.

All this does not matter much as long as we are mainly interested in the 1/f noise below about 300 kHz, because it is much stronger than the high frequency noise anyway.

Now we want to see the real noise density up to 10 MHz without any aliasing spoiling our measurements. For this we can activate all channels, thus reducing the input bandwidth to a well defined 200 MHz and engage the 20 MHz bandwidth limiter on top of that, so that we can be absolutely sure that there will be no aliasing products of any significance affecting the measurement at 10 MHz.


SDS824X HD_ND_1mV_20MHz_500MSa

Calculation for 10 MHz: -144.58 dBV = 59 nVrms.
The noise density at this point is 59 nV / √889.3 Hz = 59 nV / 29.8 = 1.98 nV/√Hz;

Here is the complete table:
 10 MHz:   -144.58 dBV    2.0 nV/√Hz
  3 MHz:   -142.48 dBV    2.5 nV/√Hz
  1 MHz:   -141.88 dBV    2.7 nV/√Hz
300 kHz:   -141.55 dBV    2.8 nV/√Hz
100 kHz:   -131.63 dBV    8.8 nV/√Hz
 30 kHz:   -125.49 dBV   17.8 nV/√Hz
 10 kHz:   -113.34 dBV   72.2 nV/√Hz
  1 kHz:   -101.97 dBV  267.2 nV/√Hz

With a noise density below 2 nV/√Hz, the Siglent SDS824 X HD beats most of the competition at higher frequencies, whereas the 1/f noise is nothing to write home about, but that has to do with the special split path input buffer design with its enormous offset compensation capability (±8 V starting at only 10.2 mV/div!).


Attached is the binary data file for this measurement.

SDS824X_HD_Binary_C4_2.7z
Channel 4, 1 mV/div, 50 ohms terminated;
500 µs/div, 2.5 Mpts, 500 MSa/s;
Bandwidth limit = ~20 MHz to get rid of any remaining aliasing from >250 MHz;


EDIT: Of course, the above measurement was flawed, because the 20 MHz bandwidth limiter affects the 10 MHz measurement. The actual noise density, measured without bandwidth limit at 10 MHz is 2.4 nV/√Hz, just as it was stated in the first test.


SDS824X HD_ND_1mV_200MHz_500MSa

Here is the updated noise density table:
 10 MHz:   -144.58 dBV    2.4 nV/√Hz
  3 MHz:   -142.48 dBV    2.5 nV/√Hz
  1 MHz:   -141.88 dBV    2.6 nV/√Hz
300 kHz:   -141.55 dBV    2.9 nV/√Hz
100 kHz:   -131.63 dBV    6.0 nV/√Hz
 30 kHz:   -125.49 dBV   16.0 nV/√Hz
 10 kHz:   -113.34 dBV   68.8 nV/√Hz
  1 kHz:   -101.97 dBV  247.0 nV/√Hz

A noise density of <2.4 nV/√Hz is still one of the best in the industry.

Attached is the binary data file for this measurement.

SDS824X_HD_Binary_C4_3.7z
Channel 4, 1 mV/div, 50 ohms terminated;
500 µs/div, 2.5 Mpts, 500 MSa/s;
Full Bandwidth;

[gf]

Of course, if we want any accuracy in the spectrum plot, the Flattop window has to be used, and the RBW is Δf * 3.73 in case of Siglent’s version of the Flattop Window.
...
Calculation for 10 MHz: -144.58 dBV = 59 nVrms.
The noise density at this point is 59 nV / √889.3 Hz = 59 nV / 29.8 = 1.98 nV/√Hz;

Actually it is not the RBW (-3dB bandwidth), but the ENBW, which matters for noise denity. For Octave's flattop window, RBW=3.73*Δf, and ENBW=3.77*Δf. The Matlab variant it is almost the same. Don't know the factors for the Siglent variant of the window. The Siglent window must be different, though, since the SDS800X handbook specifies a main lobe width of 23*PI/N (-> 11.5*Δf), while it is 10*Δf for the Matlab/Octave variant. The exact coeffients are unfortunately not documented.

[ Fortunately, for a flattop window, the difference between RBW and ENBW happens to be small, so it does not make a big difference if the wrong one is used. ]

Now we want to see the real noise density up to 10 MHz without any aliasing spoiling our measurements. For this we can activate all channels, thus reducing the input bandwidth to a well defined 200 MHz and engage the 20 MHz bandwidth limiter on top of that, so that we can be absolutely sure that there will be no aliasing products of any significance affecting the measurement at 10 MHz.

Is the 200 MHz limiter an analog or a digital filter?

[ If it is digital, then it cannot remove noise that has already been folded by the sampling process from 490-500 Mhz, 500-510 MHz and from 990-1000 MHz down to 0-10 MHz (at 500MSa/s). Then it might be better to use 2GSa/s in order to avoid this folding. ]

[pdenisowski]

First, thank you for doing all this - really excellent analysis. 

One small question:  is it possible to configure the FFT parameters independently of the time domain settings?  Or does changing the parameters in one domain change the settings in the other domain?

[Performa01]

One small question:  is it possible to configure the FFT parameters independently of the time domain settings?  Or does changing the parameters in one domain change the settings in the other domain?

No - there is no dedicated SA-application. The FFT is just a math operation.

We can select the FFT length (as long as it does not exceed the total record length).

We have vertical and horizontal settigs, but these define the view parameters and do not affect the signal acquisition. Consequently, they are primarily used for zooming and navigating within the total FFT result.

We always need to set the correct acquisition mode (normal in most cases, ERES only in special situations, no Average and certainly no Peak Detect at all), input coupling, vertical gain & offset and time base to ensure sufficient record length.

[Performa01]

Fortunately, for a flattop window, the difference between RBW and ENBW happens to be small, so it does not make a big difference if the wrong one is used.

That’s what I am relying on. The “RBW-filter” defined by the flattop window has steep transitions into the stop band, hence the noise bandwidth is assumed to be approximately the same as the resolution bandwidth.

Furthermore, if the actual noise bandwidth is a little wider than the RBW, what would the result be? The resulting noise density would be even ~0.5% lower, so it’s totally safe to specify the noise density by using the RBW of the Flattop window.

Is the 200 MHz limiter an analog or a digital filter?

It is a combination of both. Yes, at 500 MSa/s we cannot guarantee there will be no high frequency noise components folded back to the first Nyquist zone, this is why I used the 20 MHz (analog) bandwidth limiter at first. Unfortunately, this already affects the noise floor at 10 MHz a little. But you can see that there is no significant difference between 20 MHz and 200 MHz at 3 MHz (2.5 nV/√Hz), which I take as prove that the aliasing components can be neglected in the 200 MHz test scenario.

[Performa01]

Noise Density 2

This time I’ve decided to put not so much weight on the 1/f noise at really low frequencies, but do a flawless measurement where we can rule out any aliasing artefacts affecting the numbers.

I used only a single channel (Ch. 4), hence a sample rate of 2 GSa/s, which permits a 2 Mpts FFT with an effective FFT-sample rate of 2 GSa/s and Δf = 953.67 Hz, resulting in 3.56 kHz RBW with the Flattop window. This allows us to measure the 1/f noise down to at least 10 kHz and guarantees full accuracy up to 1 GHz.

Now we want to measure the real noise density up to 100 MHz without any aliasing spoiling our results.


SDS824X_HD_ND_2GSa_1mV

Calculation for 10 MHz (I’ve used 9.9 MHz to escape a micro-spur): -137.35 dBV = 135.68 nVrms.

The noise density at this point is 135.68 nV / √3560 Hz = 135.68 nV / 59.66 = 2.27 nV/√Hz;

Here is the complete table:
100 MHz:   -137.73 dBV    2.18 nV/√Hz
 10 MHz:   -137.35 dBV    2.27 nV/√Hz
  3 MHz:   -136.64 dBV    2.47 nV/√Hz
  1 MHz:   -136.54 dBV    2.50 nV/√Hz
300 kHz:   -135.01 dBV    2.98 nV/√Hz
100 kHz:   -128.72 dBV    6.14 nV/√Hz
 30 kHz:   -120.57 dBV   15.70 nV/√Hz
 10 kHz:   -104.51 dBV   99.67 nV/√Hz

We are getting pretty close to 2 nV/√Hz at frequencies of 10 MHz and higher.

[hpw]

@Noise Density 2: Any chance to save 100x AVG by 2M as one 200M BIN file size to save?

[Performa01]

@Noise Density 2: Any chance to save 100x AVG by 2M as one 200M BIN file size to save?

That’s not easy:

The record length is 4 Mpts with these settings, which means there are 400 Mpts in total used with 100x averaging – and the settings are as they are for a reason. At slower time bases, it would not be possible to retain the 2 GSa/s FFT-sample rate. A faster time base setting (e.g. one that leads to 2 Mpts) would not be sufficient for a 2097152-point FFT.

Of course, I could just capture a long record so that you can play with it – but that I’ve done already and since the total sample memory in the SDS824X HD is just 100 Mpts, I can’t provide anything longer than that.

A different approach would be to save the complete history, but this feature is not implemented yet and then the entire history is limited by the max. 100 Mpts sample memory just as well.

Only way would be to save 100 individual records, each 4 Mpts = 8 MB long. But that’s a bit too much asked 😉

[gf]

EDIT: Moved my answer to hpw's "A call for Bin-Files as for new Siglent HD-Models" thread - I think it fits better there.
https://www.eevblog.com/forum/testgear/a-call-for-bin-files-as-for-new-siglent-hd-models/msg5379377/#msg5379377

[hpw]

@Noise Density 2: Any chance to save 100x AVG by 2M as one 200M BIN file size to save?

That’s not easy:

The record length is 4 Mpts with these settings, which means there are 400 Mpts in total used with 100x averaging – and the settings are as they are for a reason. At slower time bases, it would not be possible to retain the 2 GSa/s FFT-sample rate. A faster time base setting (e.g. one that leads to 2 Mpts) would not be sufficient for a 2097152-point FFT.

Of course, I could just capture a long record so that you can play with it – but that I’ve done already and since the total sample memory in the SDS824X HD is just 100 Mpts, I can’t provide anything longer than that.

A different approach would be to save the complete history, but this feature is not implemented yet and then the entire history is limited by the max. 100 Mpts sample memory just as well.

Only way would be to save 100 individual records, each 4 Mpts = 8 MB long. But that’s a bit too much asked 😉

Look, I like(d) simple getting the equal results as you using equal samples. 

The given BIN files shows on the first 5..10 FFT's anyway a higher noise as the flowing once. Even on SDS3000 HD.

This is may a thermal or stability issue, as the gear to heat up (1h or more) before any 1/f & noise to measure.

The calculations of the dBrtHz could be easier done, as the ENBW value in dB to subtract of the dBV. But works only with equal used FFT Window for dBV to dBVrtHz graphs.

[gf]

Look, I like(d) simple getting the equal results as you using equal samples. 

If you lower your expectations and are also satisfied with a very similar result, you can obtain it from the .bin file posted by Performa01.

[maxwell3e10]

Thanks for these measurements, 2 nV/sqrt(Hz) at 1mV/div is indeed quite impressive, among the very best noise for front end amplifier. https://www.eevblog.com/forum/testgear/oscilloscope-input-noise-comparison/
The 1/f noise is not as good, a bit worse than Rigol HDO.

Did you make measurements at 1V/div scale? That would be a test of the ADC and a direct measure of HD performance.

[Performa01]

Granular Noise

This time we shall have a look at the granular noise of the 12-bit SDS800X HD. At high sensitivities like 1 mV/div, we cannot expect much of an advantage from the 12 bits, but at low sensitivities like 50 mV/div and higher, the 12 bits should clearly give us a benefit.

I used only a single channel (Ch. 4), hence a sample rate of 2 GSa/s, which permits a 2 Mpts FFT with an effective FFT-sample rate of 2 GSa/s and Δf = 953.67 Hz, resulting in 3.56 kHz RBW with the Flattop window. This allows us to measure the noise down to at least 10 kHz and guarantees full accuracy up to 1 GHz.


SDS824X_HD_ND_2GSa_1V

There’s little point in calculating a noise density (which would have to be specified in hundreds of nanovolts or even single digit microvolts per square-root Hertz), but we should consider the full-scale value of +9 dBV in this test scenario.

We get a SNR of >110 dB at 100 MHz with a RBW of 3.56 kHz.

You can download a 100 Mpts binary file for this test scenario:

SDS824X HD
Channel 4, 1V/div, 50 ohms terminated;
5 ms/div, 100 Mpts, 2 GSa/s;
Full bandwidth = 254 MHz;

https://mega.nz/file/XD5UVL7a#KQhhly2Zo7U2D5wumdrSVm2psvrTVdZtO8pwSQV34wA

[Bad_Driver]

Performa01, a dumb question.

Is there a special reason for always using channel 4 for your tests? 

[RAPo]

Maybe the green color trace, it looks more like an analog scope and the rigol (sadly) doesn't have it? 🤔

[Martin72]

Performa01, a dumb question.

Is there a special reason for always using channel 4 for your tests?

I usually use the first channel - because the short cables don't get any further and my measuring equipment is to the left of the scope.

Edit:

You can download a 100 Mpts binary file for this test scenario:

Is canceled for me with the reference to a (possible) virus (Win10,Edge)

[Performa01]

Is there a special reason for always using channel 4 for your tests? 

It's actually the green color trace that I prefer, also because of fond memories of analog CROs, so I decided to use Ch.4 as the default choice back when I got my first Siglent MSO (SDS2304) about 10 years ago.

Back then I've even found a bug that was specific to not using channel 1 - so one more reason to stick to Ch.4 ever since

[gf]

There’s little point in calculating a noise density (which would have to be specified in hundreds of nanovolts or even single digit microvolts per square-root Hertz), but we should consider the full-scale value of +9 dBV in this test scenario.

We get a SNR of >110 dB at 100 MHz with a RBW of 3.56 kHz.

If you relate it to a specific bandwidth, then it is still a density.
Maybe dB_FS/Hz would be an appropriate (bandwidth-independent) metric?
Then it would be about -145 dB_FS/Hz at 100MHz.

However, the full bandwidth noise floor is ~4.3 mV_RMS, which corresponds to a total SNR (or better say SINAD?) of ~56 dB_FS, or ~9.1 ENOB (not yet including harmonic spurs and mixing products of the measured signal, since no signal is present).

What I also noticed, by the way, is that roughly 1/3 of the noise floor's total power is contributed by the two (interleaving?) spurs at 500MHz and 1GHz! I wonder if it would not be possible to calibrate them out? Or is it already the best possible calibration?

[rf-loop]

Here some example where are bottom and top of voltage band I and II
Now here is also other individual SDS824X HD
And as can see very close with @Performa01

Below images, all inputs terminated with 50 ohm  terminator (HP11593A).


Voltage band II
F1 1V/div
F2 102mV/div

Voltage band I
F3 100mV/div
F4 1mV/div



FFT window FlatTop



btw, I do not know this Siglent used FlatTop window real ENBW (Equivalent Noise Band Width) so here below is same using Rectangle aka "Boxcar" window.




FFT window Rectangle, Input 1mV/div, Full BW
Calculation for 9,85 MHz  -142.8 dBV = 72.1nVrms
Noise density in this point 72.1nVrms / √953.7 Hz = 2.33 nV/√Hz;

[Performa01]

There’s little point in calculating a noise density (which would have to be specified in hundreds of nanovolts or even single digit microvolts per square-root Hertz), but we should consider the full-scale value of +9 dBV in this test scenario.

We get a SNR of >110 dB at 100 MHz with a RBW of 3.56 kHz.

If you relate it to a specific bandwidth, then it is still a density.
Maybe dB_FS/Hz would be an appropriate (bandwidth-independent) metric?
Then it would be about -145 dB_FS/Hz at 100MHz.

Right. I should have said: “there’s not much point in calculating the classic noise density expressed in nV/√Hz.

Since the vertical axis is dBV (and not dBm) in this example, I guess dB_FS/√Hz would be more appropriate.

Since the SDS800X HD lacks 50 ohm inputs, it feels more natural to work with voltages instead of power levels.

However, the full bandwidth noise floor is ~4.3 mV_RMS, which corresponds to a total SNR (or better say SINAD?) of ~56 dB_FS, or ~9.1 ENOB (not yet including harmonic spurs and mixing products of the measured signal, since no signal is present).

Since there is no distortion component, SNR would be the better term in my book. Static spurs can be looked at as some sort of noise, and dynamic ones (that depend on input signal) could rather be classified as some complex form of non-harmonic distortion.

Since distortion products can easily be lower than -54 dBc, actually up to -70 dBc as also demonstrated in this thread, the 9.1 ENOB should be actually achievable in many practical scenarios.

What I also noticed, by the way, is that roughly 1/3 of the noise floor's total power is contributed by the two (interleaving?) spurs at 500MHz and 1GHz! I wonder if it would not be possible to calibrate them out? Or is it already the best possible calibration?

The self-calibration takes quite a long time, so it’s actually been a while since I’ve last performed one.

Now I’ve tried again, even though I didn’t expect much from it – in my experience the calibration in this instrument seems pretty stable anyway. Yet there is a little difference indeed:


SDS824X_HD_ND_2GSa_1V_cal