Siglent SDS800X HD Review & Demonstration Thread

[mawyatt]

The Fourier series for a rectangular wave is like 2 * A / π * (h1 + h3 / 3 + h5 / 5 + h7 / 7 …);

In the example above, the amplitude is 0.6 V, so the term in front of the parenthesis is 2 * 0.6 / π = 0.38197 Vp;

We should now be able to calculate the individual harmonics:
h1 = 0.38197 Vp = -11.37 dBV;
h3 = 0.38197 Vp / 3 = 0.127 Vp = -20.91 dBV;
h5 = 0.38197 Vp / 5 = 0.0764 Vp = -25.35 dBV;
h7 = 0.38197 Vp / 7 = 0.0546 Vp = -28.27 dBV;
h9 = 0.38197 Vp / 9 = 0.0424 Vp = -30.45 dBV;

If we compare this to the Peak Table in the above screenshot, we get the following list:

Freq.   Calculated   Measured   Deviation
[MHz]   [dBV]    [dBV]      [dB]
80   -11.37   -11.535   -0.165
240   -20.91   -21.786   -0.876
400   -25.35   -28.153   -2.803
560   -28.27   -34.581   -6.311
720   -30.45   -42.963   -12.513

The fundamental at 80 MHz is pretty close to the theory, also the third harmonic at 240 MHz is not too far off. Yet all the higher harmonics are increasingly attenuated. Well, no wonder – the textbook calculates the Fourier coefficients for ideal square waves with zero rise time!

What we want to do now, is not comparing an imperfect square wave, captured with the SDS824X HD to some textbook theory, but rather with the reference. The outcome is only all too predictable: at 80 MHz the measurement result will be similar, at 240 MHz almost 3 dB too low and drop off pretty quickly at even higher frequencies.


SDS824X HD_Square_3.5ns_80MHz

Yes, the prediction comes true.

Freq.   Calculated   Measured   Deviation
[MHz]   [dBV]    [dBV]      [dB]
80   -11.37   -11.827   -0.457
240   -20.91   -24.514   -3.6
400   -25.35   -40.954   -15.6

Unexpectedly, the level for the even order harmonics is a little bit higher too, with -44 dBc for the 2nd harmonic.

Verdict: this is a nominal 200 MHz instrument. The true 3 dB bandwidth is somewhere at 245 MHz, as long as we don’t activate more than two channels at the same time. The specified rise time is 1.8 ns, actually it is better than 1.5 ns. It has been shown that the SDS824X HD can handle pulses with 1 ns rise time, even though it cannot fully characterize them. The comparison of the Fourier series from the textbook with the real measurements was nothing more than a little fun, because in the real world a perfect square wave doesn’t exist.

And the most important part: the frequency of a square wave is only important because it also dictates the maximum rise time of the signal. For instance, we cannot have a 200 MHz square wave with just 3.5 ns rise time. Other than that, especially for digital communications, we don’t need excessive bandwidth – just enough to capture the relevant part of the modulation spectrum, which has to be bandwidth limited at the transmitter side anyway. Sections “SPI Speed Test” and “The 200 Mbps SPI challenge” deal with fast digital signals, and as the title already reveals, it is possible to handle 200 Mbps communication with the SDS824X HD – just 245 MHz bandwidth are enough for that.

Not sure about your results above??

A unity +-1 volt square wave has 4/pi as the 1st component and each odd harmonic drops as 1/n.

So if the squarewave is 0.3V peak (0.6VPP) then the 1st component h1 is 0.38197V (as stated) and 20Log(0.38197) is -8.359dBV, not -11.37dBV as stated??

Edit:
And,
h3 should be -17.90dBV
h5 should be -22.34dBV
h7 should be -25.26dBv
and so on.

Also, think your "n" above should be pi.

Am I missing something?

Best,

[gf]

A unity +-1 volt square wave has 4/pi as the 1st component
...
So if the squarewave is 0.3V peak (0.6VPP) then the 1st component h1 is 0.38197V (as stated) and 20Log(0.38197) is -8.359dBV, not -11.37dBV as stated??

4/pi is the peak amplitude. FFT shows RMS amplitude, which is 2*sqrt(2)/pi. I.e. 3dB lower.

[mawyatt]

Thanks gf, my bad 

Best,

[Performa01]

Thank you for providing so many detailed measurements. I am wondering if you can test the averaging and ERES math features, which are not described in detail in the manual. Basic questions are what is the maximum number of averages, does it allow finite and running average, how much does averaging or ERES slow down update rate?

Other than the higher end devices (starting with SDS2000X HD), the SDS800X HD does not provide hardware-accelerated acquisition modes for ERES and Average. Math functions are processed way slower in software. The RAW acquisition rate is not affected by this though.

Both ERES and Average preserve the sample rate. While not really surprising in case of Average, it means that ERES is implemented in a sliding, non-decimating form.

The maximum number of 1024 Averages can be performed in 54 seconds, which is close to 19 averages per second.

I don’t know for sure, but assume that it has to be finite time average, because it works with long records as well (I have tried 10 Mpts, where it slows down considerably) and the SDS800X HD doesn’t have 10 Gpts of memory.

[gf]

I don’t know for sure, but assume that it has to be finite time average, because it works with long records as well (I have tried 10 Mpts, where it slows down considerably) and the SDS800X HD doesn’t have 10 Gpts of memory.

I guess you rather mean infinte? Like e.g. an exponential moving average?

It is still unclear to me how it averages traces with different trigger point positions (i.e. at different fractional sample time)?
Quantizing the trigger points to the nearest sample would introduce jitter in the amount of +-1/2 sample.
And time shifting the samples of the traces to align them horizontally would imply the need for interpolation.

[ If a large number of traces are averaged, then it may be an option to quantize, since statisitcally, the trigger point quantization + averaging effectively results in a convolution with the probability distribution of the fractional trigger positions, which is a lowpass filter. ]

Both ERES and Average preserve the sample rate. While not really surprising in case of Average, it means that ERES is implemented in a sliding, non-decimating form.

ERES is just a lowpass filter then. If it happens to be simple boxcar averaging (i.e. sinc frequency response), then it is certainly not a proper anti-aliasing filter for decimation anyway. So it can even make sense to keep the sample rate and not decimate. Can you check the frequency response with ERES? Does it have typical sinc (or sinc^N) side lobes? Or is it a proprietary filter? If the latter, then ENBW would be interesting too to predict the expected noise reduction.

[RoGeorge]

select "All" at the top of the page to open all of the existing pages and then print as a hard copy or save as a pdf for reference

There is a plugin/extension for browsers (for Firefox-like browsers the addon is called 'SingleFile' https://addons.mozilla.org/en-US/firefox/addon/single-file/ ).

'SingleFile' can save the entire webpage as a single html offline file, with pics, and it also retains the original links, to click later for the live content of the page.  The saved filename can distinguish between forum pages, so it can save distinct pages (the "All" might be too much to continuously scroll, distinct pages are easier to navigate than jumping back and forth in a very long single scroll).  Can make highlights or annotations on top of saved pages, cutouts, etc.

[Performa01]

I don’t know for sure, but assume that it has to be finite time average, because it works with long records as well (I have tried 10 Mpts, where it slows down considerably) and the SDS800X HD doesn’t have 10 Gpts of memory.

I guess you rather mean infinte? Like e.g. an exponential moving average?

No, how should I? I’m following a simple logic here by asking myself: how can we compute a moving average if we don’t have a buffer big enough to store all the past records (plus the current one), which would have to be 1024 records in case of 1024x averaging, hence 10.24 Gpts = 20.48 GB of sample memory in case of 10 Mpts records?

If on the other hand it is done piecewise, one block of 1024 records after the other, we just need a single counter and accumulators for each sample within a record – 22 bit would be sufficient for 1024x averages of 12 bit samples. Since math channels are limited to 10 Mpts, this requires the equivalent of 20 Mpts (=40 MB) memory, even if 32-bit accumulators are used. That’s just manageable. Consider all four math channels performing averaging at the same time – then 80 Mpts of the 100 Mpts total memory would already be used up.

It is still unclear to me how it averages traces with different trigger point positions (i.e. at different fractional sample time)?
Quantizing the trigger points to the nearest sample would introduce jitter in the amount of +-1/2 sample.
And time shifting the samples of the traces to align them horizontally would imply the need for interpolation.

Of course the records have to be fine-adjusted to get their trigger points perfectly aligned. I think in current software generation the user setting of linear or sin(x)/x for the display rendering is used for trigger alignment as well (prior to that it has always been sin(x)/x).

That happens all the time anyway, and any acquired record is processed that way, whether it is used to calculate an average or not.

It’s also worth noticing that we cannot have a History when the Average acquisition mode is selected in one of the higher end DSOs that support this. The same restriction does not apply for ERES. Yes, of course, we can’t have the History as we know it, when we need almost all the memory for accumulators and counters…

[ If a large number of traces are averaged, then it may be an option to quantize, since statisitcally, the trigger point quantization + averaging effectively results in a convolution with the probability distribution of the fractional trigger positions, which is a lowpass filter. ]

Sorry, I’m not sure if I can follow you here – I’m neither a mathematician nor a DSP-expert.

What do you want to quantize? And the probability distribution of the trigger position correction values can be seen whenever we use Dots display mode. I would expect the probability distribution to be just a straight horizontal line.

Both ERES and Average preserve the sample rate. While not really surprising in case of Average, it means that ERES is implemented in a sliding, non-decimating form.

ERES is just a lowpass filter then. If it happens to be simple boxcar averaging (i.e. sinc frequency response), then it is certainly not a proper anti-aliasing filter for decimation anyway. So it can even make sense to keep the sample rate and not decimate. Can you check the frequency response with ERES? Does it have typical sinc (or sinc^N) side lobes? Or is it a proprietary filter? If the latter, then ENBW would be interesting too to predict the expected noise reduction.

Of course, ERES is (just?) a LP-Filter, no one has ever claimed otherwise. And yes, it might be just a boxcar filter, see screenshot below with ERES 2.0:


SDS824X HD_FR_ERES2.0_2GSa

[RoGeorge]

how can we compute a moving average if we don’t have a buffer big enough to store all the past records

My conclusion (based on how Rigol DS1054Z was behaving, so don't know if this applies to Siglent, too) was that the moving average in Rigol was calculated by averaging the pixels of the screen only, not the raw data, so the buffer size was dictated by the number of pixels on the width of the display.

[Performa01]

My conclusion (based on how Rigol DS1054Z was behaving, so don't know if this applies to Siglent, too) was that the moving average in Rigol was calculated by averaging the pixels of the screen only, not the raw data, so the buffer size was dictated by the number of pixels on the width of the display.

Well, that's a whole different world. As alread stated in my previous post, math is limited to 10 Mpts per channel - that's about 10000 screen widths

[2N3055]

how can we compute a moving average if we don’t have a buffer big enough to store all the past records

My conclusion (based on how Rigol DS1054Z was behaving, so don't know if this applies to Siglent, too) was that the moving average in Rigol was calculated by averaging the pixels of the screen only, not the raw data, so the buffer size was dictated by the number of pixels on the width of the display.

Don't confuse how DS1000Z was doing things.

Has nothing to do with that.

This is about averaging of data as acquisition mode.
It works on full buffer size, from repetitive triggers.
If it says 10MPts, it is 10MPts.

I presume it is something similar to Continuous averaging as defined by LeCroy..

Continuous Averaging

Continuous Averaging, the default setting, is the repeated addition, with unequal weight, of successive
source waveforms. It is particularly useful for reducing noise on signals that drift very slowly in time or
amplitude. The most recently acquired waveform has more weight than all the previously acquired ones:
the continuous average is dominated by the statistical fluctuations of the most recently acquired
waveform. The weight of ‘old' waveforms in the continuous average tends to zero (following an
exponential rule) at a rate that decreases as the weight increases.
You determine the importance of new data vs. old data by assigning a weighting factor. The formula for
continuous averaging is:

new average = (new data + weight * old average)/(weight + 1)

By setting a Sweeps value, you establish a fixed weight that is assigned to the old average once the
number of sweeps is reached. For example, for a sweeps (weight) value of 4:

Sweep no.    ----                               New Average

1 (no old average yet) (new data +0 * old average)/(0 + 1) = new data only
2                               (new data + 1*old average)/(1 + 1) = 1/2 new data +1/2 old average
3                               (new data + 2 * old average)/(2 + 1) = 1/3 new data + 2/3 old average
4                               (new data + 3 * old average)/(3 + 1) = 1/4 new data + 3/4 old average
5                               (new data + 4 * old average)/(4 + 1) = 1/5 new data + 4/5 old average
6                               (new data + 4 * old average)/(4 + 1) = 1/5 new data + 4/5 old average
7                               (new data + 4 * old average)/(4 + 1) = 1/5 new data + 4/5 old average

etc...

That way you only need one buffer for averages accumulation and you grab new capture, recalculate in place and move on to next trigger.

[gf]

I presume it is something similar to Continuous averaging as defined by LeCroy..

Continuous Averaging
...

What you describe is an exponential moving average (EMA), which is an IIR filter (i.e. infinte).

Performa01's guess was that SDS800X averaging is still finite (FIR). But a true SMA is not possible w/o keeping the complete tail. All you can do with limited memory is to deliver a SMA at a (significantly) lower frame rate than the trigger rate, or to do some approximations which may again involve recursions that make them IIR at the end.

[Performa01]

I presume it is something similar to Continuous averaging as defined by LeCroy..

...

That way you only need one buffer for averages accumulation and you grab new capture, recalculate in place and move on to next trigger.

Thanks for pointing out LeCroy's method of processing a continuous Average.

Siglent don't have a weighting factor but a "number of averages" instead. Of course, this could be used to derive the weighting factor for continuous averaging.

The memory requirement is still high, it still means a maximum of 80 Mpts of memory for 4 channels, assuming that the current record has to be buffered somewhere, for the continuous calculation of the new average.

Btw, LeCroy don't offer this as acquisition mode, it's always been a math function.

Another pointer might be Siglent's reluctance to provide high numbers of Averages. We have to make do with 1024 (even though this really should be enough for all practical purposes, SDS6000 has 8k), whreas the competition offer up to 64k.

[maxwell3e10]

Some scopes offer simple finite average where the trigger stops after required number of averages, this does not require storing all the data in memory. Other scopes offer history average, which would be equivalent to a simple moving average and limited by total memory. If there are no additional options and the update does not stop after reaching the number of averages, then it must be exponential moving average.

The trigger rate must be reduced while it's doing the averaging (or any math operation) or it just skips frames to be included in the average.

[gf]

Of course, ERES is (just?) a LP-Filter, no one has ever claimed otherwise. And yes, it might be just a boxcar filter, see screenshot below with ERES 2.0:

SDS824X HD_FR_ERES2.0_2GSa

Thanks for the screenshot.
Yes, looks like a 16 tap boxcar filter. The spacing of the zeros is N*125 MHz, is it? (Hard to see exactly on the log scale.)
The sidelobes decay too fast for a boxcar filter, but that's certainly caused by the frontend frequency response.

So ERES 2.0 obviously means +2 ENOB, while the resolution enhancement is even +4 bits.
[ Not exactly +2 ENOB, of course, since the noise floor is not white. ]

[Performa01]

Zoom Challenge

Some folks have the need for a high dynamic range, i.e. the ability to inspect small details in a signal. To accomplish this, they usually increase the vertical gain of the DSO and use the position control to center the region of interest on the screen. This way, even 8-bit oscilloscopes can display some detail – as long as the signal distortions, caused by overdriving the oscilloscope frontend, don’t affect the displayed portion of the signal too much. The distortions are especially bad with general purpose oscilloscopes, as they use the well-known split path input buffer with its problematic overload recovery behavior.

Now let’s examine our options with the Siglent SDS800X HD.

First, we could try to use the traditional technique in overloading the scope. Without too much thinking, we can just connect a strong signal and then “zoom in” by increasing the vertical gain of the oscilloscope.

In the following example we have a 2 Mbps PRBS-signal with 3 V amplitude connected directly, hence a 1x probe factor applies.


SDS824X HD_PRBS-4_A3V_V1V_P1

Now we try to take a closer look at the pulse tops and increase the sensitivity. This works reasonably well down to 200 mV/div, but at 100 mV/div we hear a relay clicking and the signal gets distorted:


SDS824X HD_PRBS-4_A3V_V100mV_P1

With a distorted signal like this, it makes no sense to try to look at any details in the signal. So, this obviously is the wrong approach.

For most applications, it is not the overload recovery of the semiconductor devices, like clamping diodes and transistors, which cause the problem. The overload recovery time of these devices is usually in the low (or even sub-) nanoseconds and is only really of concern in multi-GHz instruments.

Our problem is the clamping in the split-path input buffer, which causes clean clipping in the LF-path, but a differentiation of the waveform in the HF-path. When the clipped LF-path is recombined again with the both offset- and phase-shifted HF-path, the result is heavily distorted and has little similarity with the original signal.

Knowing all this, we are able to find a solution: just don’t drive the input buffer so hard that the clamps get activated. Keep the input signal well below 1 Vpp by using 100x probes if necessary. This also has the advantage of a much lower capacitive load at the probe tip and the low noise of the SDS824X HD makes the use of x100 probes unproblematic.

The next screenshot demonstrates a 1 MHz square wave with 5V amplitude and a 10 mVpp 40 MHz sine riding on it, using a ten times probe.


SDS824X HD_OVD_5V_10mV_P10

Yes, the trace is noisy. It would be much better if we could use the 20 MHz bandwidth limiter – but unfortunately, this would also affect the 40 MHz signal we are interested in. Averaging would help a lot, but we want to be able to watch dynamic signals, hence it is not an option either.

We can still see the 40 MHz sine clear enough to know it is there – and that for a signal amplitude ratio of 1:500! That’s what a low noise high resolution DSO can do for you…


There might be situations, when we just cannot get that low – maybe because the signal levels are so high that the output of even x100 probes would still exceed ~500 mVpp. Then a combination of (moderately!) overdriving the scope and vertical zoom could be the best solution.

Consider a 1 MHz Square wave with 5 V amplitude – maybe as output of a x100 probe, so the original signal would be 500V - unbelievable, isn’t it? It could be some 625 watt transmitter – but these wouldn’t output a square wave and hopefully there wouldn’t be any subtle signal details to observe, which would not be better analyzed by using the FFT, but I digress…

Here is that familiar 40 MHz sine wave again, riding on the square wave:


SDS824X HD_Ref_5V_10mVpp

First step is to increase the vertical gain, i.e. dial in lower numbers, just before the relay would click. We could use the fine adjust to get 102 mV/div (because this is the highest gain we can get without changing the attenuator setting), but this shouldn’t be necessary for now. So we finally end up with 200 mV/div:


SDS824X HD_OVD_limit_5V_10mVpp

We can already see the little wiggles on the top of the square, it is much smaller than the overshoot and ringing at the rising edge. Yet now we engage the Zoom mode to take a closer look:


SDS824X HD_OVD_limit_5V_10mVpp_Z20mV_ERES2.0

The above screenshot demonstrates two things: first is the ERES2.0 math trace in the main window, that lets us look at the 40 MHz sine at 10 mV/div. It is ugly, because ERES cannot get rid of the 1/f noise, so there’s no use displaying it in more detail in the zoom window. But secondly, we have the regular trace in the zoom window at 20 mV/div, which is at least as clear as the overdrive zoom before.

One more time it should be remembered that we have a signal ratio of 500:1 here.

[gf]

The above screenshot demonstrates two things: first is the ERES2.0 math trace in the main window, that lets us look at the 40 MHz sine at 10 mV/div. It is ugly, because ERES cannot get rid of the 1/f noise, so there’s no use displaying it in more detail in the zoom window. But secondly, we have the regular trace in the zoom window at 20 mV/div, which is at least as clear as the overdrive zoom before.

It looks like the ERES trace was displayed without persistance.
Is that generally not supported for math traces? Or did you just turn it off?

[Performa01]

It looks like the ERES trace was displayed without persistance.
Is that generally not supported for math traces? Or did you just turn it off?

I never use persistence display mode (other than the inherent 1/framerate of the display), except when I explicitely mention it.

What you probably see is the vast difference in waveform update rate; the signal traces are updated 6590 times per second in this very scenario, whereas the math trace is much slower, even though it looks fast on the screen. I cannot think of a method to measure the waveform update rate of a math trace - it's probably just a few dozen updates per second at best.

I have re-created this test-scenario and enabled 5 seconds persistence this time:


SDS824X HD_OVD_limit_5V_10mVpp_Z20mV_ERES2.0_Pers5

[RAPo]

A bit off topic, but do you know the refresh rate in the x-y plot window (or even better a way to measure it on non-siglent oscilloscope)?

What you probably see is the vast difference in waveform update rate; the signal traces are updated 6590 times per second in this very scenario, whereas the math trace is much slower, even though it looks fast on the screen. I cannot think of a method to measure the waveform update rate of a math trace - it's probably just a few dozen updates per second at best.

[Performa01]

A bit off topic, but do you know the refresh rate in the x-y plot window (or even better a way to measure it on non-siglent oscilloscope)?

As you quoted me, I don't know a way to measure it if it is done in software. If it is integrated into the HW, like in the SDS800X HD, we can measure it just like the waveform update rates in regular y-t mode, see the result table in Reply #90 here:

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

[maxwell3e10]

For measuring how fast the average is calculated one can use this method:
https://www.eevblog.com/forum/testgear/scope-with-fast-waveform-averaging/msg4340002/#msg4340002

For X-Y plot, I would use two sine waves with 90 degree phase shift at low frequency (say 1 Hz) and set the scope to a fast time scale (say 10 nsec/div). If the display is in dot mode, you would expect a series of dot blotches appearing around the circle. The number of blotches tells you the number of updates in 1 second. Depending on persistence, one could also set a finite number of triggers, so the blotches don't run around the circle and start to overlap.

Edit: should still be visible in line mode if the number of blotches around the circle is small, so frequency of sine wave can be increased.

[tautech]

For measuring how fast the average is calculated one can use this method:
https://www.eevblog.com/forum/testgear/scope-with-fast-waveform-averaging/msg4340002/#msg4340002

For X-Y plot, I would use two sine waves with 90 degree phase shift at low frequency (say 1 Hz) and set the scope to a fast time scale (say 10 nsec/div). If the display is in dot mode, you would expect a series of dot blotches appearing around the circle. The number of blotches tells you the number of updates in 1 second. Depending on persistence, one could also set a finite number of triggers, so the blotches don't run around the circle and start to overlap.

Not available in XY mode.

[BRZ.tech]

Fun with Square Waves

[…
And the analysis of Digital Signals in the time regime and frequency regime is very welcome for HAM users. And I'm sure the SDS800X HD will literally be able to supply the most important measurements.
In this topic, I looked in the index, in the first post, and I didn't find the Frequency Response for Square Wave Excitation.

The frequency as well as pulse response of the SDS800X HD have been presented in some detail in the opening posting (sections “Bandwidth” and “Pulse Response”). Why do you think you need a special frequency response for square waves?
...
[/quote]

Dear @Performa01,
1. You asked me, and you deserve an Answer:
In message #175 I asked if you accept “beginners” asking you questions about “obvious things”.
In your message #180 you replied: “don’t mind people asking questions here, even newbie questions 😉”
On YouTube, on the R&S channel and on the Teledyne LeCroy channel, there are “theoretical videos” on the subject of “square wave excitation frequency response”, in a different way from your presentation. They just don't have the practical part. In summary, they state that the BW of the DSO must be greater than 5x the frequency of the fundamental wave signal.

2. In my opinion as a “beginner”, for a non-SIGLENT user (not yet), the fact that it presents the “Bandwidth” of a sinusoidal signal, and “Pulse Response” does not allow us to conclude that the frequency is tolerable with deformations, for the square wave SDS800X, is f=80MHz (photo: SDS824X HD_Square_3.5ns_80MHz).
Based on the “Bandwidth” of sine signal, and “Pulse Response”, how did you reach the conclusion of BW for square wave?
 
3. As you demonstrated that for the SDS800X, BW = 245MHz for sinusoidal signal, I just divided it by 5, and asked you to start the test at f=50MHz, and increase the frequency, and you arrived at f=80MHz with a “square wave” (“photo: Ref-Spec_Square _1ns_80MHz”), which 80 x 3 = 240MHz…
The SDS824X HD managed to faithfully display the “1 fundamental”, the “3 harmonic” and the “5 harmonic”.
The richness and detail of your analysis is impressive... Maybe someday I will be able to repeat your essays, to learn many things. Unfortunately, not everything is as obvious to me, as it is to you and other colleagues working on the topic.
 
4. As for the video by “Professor Michel van Biezen”, for experts, the issue comes down to just the photo at the beginning of the video… the equation and the Fourier Series Coefficients.
In my “beginner” analysis, it doesn’t matter much if the theoretical equation doesn’t support a square wave signal of 1ns risetime…
Note that the objective is didactic, and may contain an error, for example of 20%, in practical measurements in relation to theoretical calculations… In HAM, we are not so orthodox in relation to the perfection of comparing measurements…
I think it's better to start with 20% error, and aim to reduce this number a lot. But I really appreciate your orthodoxy, and your method of analysis. Maybe someday I will be able to understand almost everything you taught, and teach some beginners in the HAM universe, and I will cite you as a source.

5. As for the Fourier Series, you learned another formula that I had never seen. This Fourier Series formula has many ways to learn it.
TKS.
Having observed your comments, it is still not possible to understand whether the “Fourier Series Coefficients” should be placed in Vp, Vpp, Vrm, or something else.
Request: Even if it contains errors greater than 20%, as there is no perfect square wave, if you can assemble and present an equation of the Fourier Series, with f=80MHz, of the square wave, I will be very grateful. As in the formula presented in the video by “Professor Michel van Biezen”.

6. In the photo: “Ref-Spec_Square _1ns_80MHz”, in the “Peak Search Table”, in “Marker 6” it has f=880.00000MHz. I said here that it has “8 digits”, but you repeatedly state that the SDS800X has “7 digits” in the Counter. Do you count from “0 to 7”, or from “1 to 8”?

7. After your “class”, I agree with you that the “Risetime” is the starting point for buying an AWG, and “the good one is the 1ns”, but it is the top of the line, and is far above of my hobby budget.
TKS.
73.

[gf]

2. In my opinion as a “beginner”, for a non-SIGLENT user (not yet), the fact that it presents the “Bandwidth” of a sinusoidal signal, and “Pulse Response” does not allow us to conclude that the frequency is tolerable with deformations, for the square wave SDS800X, is f=80MHz (photo: SDS824X HD_Square_3.5ns_80MHz).
Based on the “Bandwidth” of sine signal, and “Pulse Response”, how did you reach the conclusion of BW for square wave?

The bandwidth, wich is just a single number, is indeed insufficient (unless you make some additional assumtions), but the impulse response defines a LTI system completely¹⁾. Particularly for a square wave signal, the impulse response (or the step response²⁾) gives you a good idea what defomations of the square wave edges you have to expect. The top and the bottom of a low-frequency square wave are flat anyway, so the key is the deformation of the edges. Only at high frequencies, the deformation of the rising and falling edges begin to overlap and add up. Then it is no longer so obvious what the exaxt shape will be. Still you can calculate it from the impulse response. The old question what bandwidth is enough for displaying a square wave cannot be answered in general. It is up to you what YOU consider "good enough" (or good enough for a particular use case). You just need to be aware that what you see is never the reality. This applies whenever you measure anything.

EDIT:
¹⁾ If you know the impulse response of a linear system, then you can calculate the response to any input signal.
²⁾ Note that the step response is just the integral of the impulse response, so each one can be derived from the other.

it is still not possible to understand whether the “Fourier Series Coefficients” should be placed in Vp, Vpp, Vrm, or something else.

It is just a matter of scaling/normalization. You can re-write the Fourier series equation in terms of peak, peak-to-peak or RMS values for the coefficients.

FFT on the scope is usually normalized to display RMS values, and it does not display positive and negative frequencies of the raw DFT spectrum separately, but displays only the combined power of positive and negative frequencies.

Also note that FFT on the scope displays only the magnitude, but not the phase. However, the amplitude of the peaks in the displayed FFT output is not sufficient to derive the sin() and cos() coefficients of the Fourier series for an arbitrary periodic signal. In order to separate sin() and cos() coefficients for the same frequency you need phase information as well.

[gf]

@Performa01, please let me ask two more questions regarding averaging:

1) I wonder what happens if an averaged trace is displayed in dots mode? Are the averaged dots now evenly spaced with 1/sample_rate interval, or do they still retain fractional horizontal positions? [Particularly when a large number of traces are averaged.]

2) I think to rememer that you (or was it somebody else?) did demonstrate in a different thread that FFT(average(Cx)) resulted in a higher FFT sample rate than the original sample rate of Cx, on either the SDS2000 or SDS6000 (don't remember which one). Obviously the signal was implicitly up-sampled/interpolated to a higher rate. I wonder if the same applies to the SDS800X?

[Martin72]

Hi,
It was at the 2000xplus:
https://www.eevblog.com/forum/testgear/math-problems-on-sds2k-(trying-to-display-bandwith)/msg4174879/#msg4174879