Trying to display bandwith via Math on Siglent SDS2k+/2kHD/800X HD

[gf]

Btw, I don't know where this comes from, but the 0.5 dB drop in the DC bin doesn't look right either.

I´ve "zoomed in" using a span of 500Mhz, when the Delta f is a bin (?), than it "happens" in exact the first one, 0Hz..24.41Mhz.
From 24.41(24.5 marked)Mhz down to 0 it´s -3dB.

-3dB? Then I think it displays the power spectrum and not the FFT spectrum "as is".
This means that negative frequencies are discarded and instead the power of positive frequencies (f > 0) is doubled.
Consequently, the power spectrum of an impulse response does not reflect the corresponding frequency response at/near DC, but only at higher frequencies.

EDIT: The problematic nature of DC in conjunction with power spectrum calculation (with rectangular and other window functions) is nicely discussed here (chapters 11 and 9).

[Performa01]

I´ve "zoomed in" using a span of 500Mhz, when the Delta f is a bin (?), than it "happens" in exact the first one, 0Hz..24.41Mhz.
From 24.41(24.5 marked)Mhz down to 0 it´s -3dB.

Delta-f, frequency step, frequency bin ... it's all the same.

(possibility to change the axis-labeling left/right would be very, very useful for a better viewing.)

Why not just get the cursor info out of the way? Like I did it on all my screenshots?
In some rare cases I even had to move the FFT info in order to tidy up the screen.

[Martin72]

Hi....



With the axis-labeling on right side you could see it better what "happens" on the left side of the FFT window, has nothing to do with the cursors or the cursor info.
Btw, lecroy put the cursor-infos into the channelboxes.

[Martin72]

-3dB? Then I think it displays the power spectrum and not the FFT spectrum "as is".

And it is independent of which window you use, I had just tried it out.

[Martin72]

I'm digging up this thread so as not to clutter up the other 800X thread.
It didn't work with the 2000Xplus back then, with the 2000X HD it was OK, now with the 800X HD...
Using the "known" formula in the editor, the following is output, which has nothing to do with the frequency response I previously recorded using Sweep and FFT-Max hold.

[Martin72]

By request, img10 shows F2 with 20xinterp, img11 all together.
I am currently trying to find out for myself what is still missing in contrast to the result of the 2504X HD, at the moment these are the same inputs.

[Martin72]

I haven't done it yet, it would make things "nicer", but in principle it should look like this without averaging:

https://www.eevblog.com/forum/testgear/math-problems-on-sds2k-(trying-to-display-bandwith)/msg4971457/#msg4971457

[2N3055]

Hmm... I can't try and replicate, unfortunately, since I don't have a fast pulse generator (yet...).

One loosely related question if I may: How do I use two nested functions in the formula editor, if both functions have additional parameters? E.g. if I want to calculate Interpolate(Average(C1)), both functions have an additional parameter. But I only seem to see the Averaging parameter in the Math dialog. Am I overlooking something, or does this situation require the use of two separate Math functions?

Use the scroll Luke...
It is below..

[Performa01]

Unfortunately, this isn’t unproblematic. The frequency of affordable pulsers is usually fixed at 10 MHz. The resulting pulse train generated in software would be even twice this frequency – but we don’t want that. We rather want a low frequency, like 1 MHz or even lower, so that we can get better frequency resolution and enable frequency response measurements down to the single-digit megahertz.

A while back I’ve done it with the SDS2504X HD, it didn’t work well, but enabling Average acquisition mode helped. Today I’m inclined to consider the results back then more as a coincidence than anything else.

I have now taken the time to investigate this a little bit more, step by step.

I’m starting with the obvious: the spectrum of a 1 MHz pulse train should reveal the frequency response of the SDS824X HD. Since I don’t have an ultra-fast pulse generator, I had to make do with 1 ns wide pulses from the SDG7102A:


SDS824X HD_FFT_FR_Pulse_W1ns_M1us

That doesn’t look too far off. The deviations are as follows:
100 MHz: -0.376 dB
200 MHz: -0.961 dB
244 MHz: -1.093 dB

I would attribute this to the non-ideal pulse shape – with this signal, the generator is already working outside its specifications.

I’ve once measured the pulse spectrum with a 2 GHz DSO and found the bandwidth to be ~378 MHz, so it is perfectly plausible to have about 1.1 dB amplitude drop at 244 MHz (unfortunately, I didn’t measure any other frequencies between 100 and300 MHz):

https://www.eevblog.com/forum/testgear/siglent-sdg7000a-350-500-mhz-and-1-ghz-awgs-coming/msg5101176/#msg5101176

So while the “real pulse” method might not be accurate (at least not as long as there are no perfect pulses available), it is certainly good enough for a quick overview.

The next step would be to make our own pulses, at least mathematically, by numerical differentiation of a 500 kHz square wave. It’s only 500 kHz because now we get two pulses per signal period, and I wanted to stay as close as possible to the previous conditions.

Since the polarity of the resulting pulses depends on the direction of the signal edges, I’ve added the abs() function to get only positive pulses like with the real pulse generator – once again, this is for best conformity with the previous test.


SDS824X HD_Math_Square_2ns_abs_diff_dx4

For this screenshot, I’ve changed the square wave with a duty cycle of 50% to a 10 ns wide pulse, just to show both edges at high time resolution in one screenshot. They are absolutely identical and the measurements hint on pulse width of ~1.65 ns and ~1 ns rise and fall times.

Here is the FFT with the pulses – this time from a 50% duty cycle square wave again:


SDS824X HD_FFT_FR_Square_1us_abs_diff

That’s significantly worse than before. The deviations are as follows:
100 MHz: -1.557 dB
200 MHz: -3.727 dB
244 MHz: -5.035 dB

We have already looked at the generated pulse from the differentiation, now let’s compare with the generator pulse from the first test:


SDS824X HD_PR_W1ns_RT500ps

It’s funny; the original pulse as it was seen by the SDS824X HD was almost 1.8 ns wide and had 1.2 ns rise-time. The software generated pulse was clearly faster, yet the FFT-results are so much worse?

Now for the (20 times) interpolation – which shouldn’t be strictly necessary, as the initial test with the pulse train has proven.


SDS824X HD_FFT_FR_Square_1us_abs_diff_int20

As expected, that’s only marginal better than without interpolation. The deviations are as follows:
100 MHz: -1.527 dB
200 MHz: -3.675 dB
244 MHz: -5.016 dB

Also as expected, the pulse shape and measurements are almost exactly the same as without interpolation.

We can select a faster time-base in order to get a smoother graph, yet at least at high sample rates this is not recommended as it significantly increases the frequency step of the FFT, thus reducing the frequency resolution, shifting up the lowest measurable frequency and finally compromising the measurement accuracy (if there was any in the first place, that is). For the original 2 GSa/s, it works reasonably well, even though the measurement accuracy has yet suffered even further:


SDS824X HD_FFT_FR_Square_200ns_abs_diff

[Martin72]

And why can't it be reproduced with the previous formula, as with the 2000X HD?
What I have just seen when looking at the old screenshots of the 2000X HD:
While the 800X HD shows a sample rate of 40GSa/s with 20xint, the 2000X HD shows 400GSa/s.

[gf]

I’ve once measured the pulse spectrum with a 2 GHz DSO and found the bandwidth to be ~378 MHz, so it is perfectly plausible to have about 1.1 dB amplitude drop at 244 MHz (unfortunately, I didn’t measure any other frequencies between 100 and300 MHz):

In order not to suffer from any frontend frequency response, you could of course also measure it with a spectrum analyzer.

Since the polarity of the resulting pulses depends on the direction of the signal edges, I’ve added the abs() function to get only positive pulses like with the real pulse generator – once again, this is for best conformity with the previous test.

The alternatig polarity of the pulses does not matter for this use case. It works, too.
I really would avoid abs(). It is a nonlinear function and introduces harmonic distortion.
It does not only invert every 2nd pulse, but it also corrupts the post ringing of each pulse.

It’s funny; the original pulse as it was seen by the SDS824X HD was almost 1.8 ns wide and had 1.2 ns rise-time. The software generated pulse was clearly faster, yet the FFT-results are so much worse?

Maybe try w/o abs().

Now for the (20 times) interpolation – which shouldn’t be strictly necessary, as the initial test with the pulse train has proven.

The question is: Is the the d/dt algorithm is still the same as on SDS2000? Is it still implemented as a simple finite difference between samples[j+N] and samples[j], where N is configurable, but >= 4? This finite difference approximation is equivalent to applying a boxcar average over N samples, in addition to the differentiation. I.e. it acts as an (undesired) lowpass filter. Then up-sampling is indeed supposed to reduce the unwanted lowpass effect, since N samples at the higher sample rate correspond to a shorter time interval. Also, allowing N=1 (w/o up-sampling) would help to reduce the unwanted lowpass effect (but not so much as with up-sampling).

Alternatively, it would be possible to design a FIR filter for the differentiation, which is pretty flat up to (say) 0.9*Nyquist (less than 0.1dB ripple, with ~75 taps). With such a differentiator, up-sampling would definitively become useless, and it would also eliminate the need to configure a finite difference interval. Since a FIR engine seems to be available anyway, it could also be used for differentiation.


Btw, may I ask you to post .bin files of your pulse train signal and your square wave signal from the SDG, captured on the SDS800X at full BW and 2GSa/s, and if possible also a captured Bodnar square wave? [ Please not too few samples. If you don't mind, then even 100M points. In case of aliasing, there is a chance that a huge FFT can still separate folded aliases from the spectral lines coming from the 1st Nyquist zone, if the signal frequency does not correlate exactly with the sampling clock. The smaller the frequency deviation, the more FTT points are required for this separation. ]

[Performa01]

I’ve once measured the pulse spectrum with a 2 GHz DSO and found the bandwidth to be ~378 MHz, so it is perfectly plausible to have about 1.1 dB amplitude drop at 244 MHz (unfortunately, I didn’t measure any other frequencies between 100 and300 MHz):

In order not to suffer from any frontend frequency response, you could of course also measure it with a spectrum analyzer.

I’ve used the DSO, just because it was convenient. As you’re well aware, a FFT means real-time, and this is in contrast to a traditional swept spectrum analyzer. And then the SDS6204 is more accurate than the average SA, at least if only a fraction of its bandwidth is actually utilized, just as in this case. Because of all this, I rarely use a SA in the range up to 2 GHz anymore.

And then, the problem was not lack of accuracy due to frontend frequency response, but simply the fact that I didn’t take the required measurements back then. So all that’s needed were some more measurements, and since you seem to prefer spectrum analyzers, I’ve used one:


SA44_Pulsetrain_1MHz_W1ns_RT500ps

As can be seen the spectrum is about -1.5 dB at 245 MHz, whereas the FFT on the SDS800X HD with original pulse-train was only ~1.1 dB low compared to a serious measurement with levelled signal source.

So there is still some mysterious 0.4 dB discrepancy – but then again, maybe we shouldn’t worry too much about ~5.4% deviation at 245 MHz on a 200 MHz DSO…

The alternatig polarity of the pulses does not matter for this use case. It works, too.
I really would avoid abs(). It is a nonlinear function and introduces harmonic distortion.
It does not only invert every 2nd pulse, but it also corrupts the post ringing of each pulse.

Good objection! I didn’t expect the post-ringing to play a major role here. Of course I’ve tried it without abs() first. Only when I looked at the pulses in the Y-t view, which I have presented in a screenshot, I noticed that the negative pulses were clipped and wanted to show unipolar pulses anyway. And, as mentioned in my posting, I wanted to make it as equal as possible to the real pulses.

Now I’m thinking about the clipping – if this happened to an input channel, it would of course spoil the whole experiment. But for the math channels, these are just viewing parameters, so the clipping was just visual and no real data would have been lost.

It’s funny; the original pulse as it was seen by the SDS824X HD was almost 1.8 ns wide and had 1.2 ns rise-time. The software generated pulse was clearly faster, yet the FFT-results are so much worse?

Maybe try w/o abs().

I do not know what’s been different today, but the result most definitely is different:


SDS824X HD_FFT_FR_Square_100ns_diff_int20

At a first glance it looks a little better, even though still not nearly what we got with the real pulses.
100 MHz: -0.549 dB
200 MHz: -2.261 dB
244 MHz: -3.624 dB

Furthermore, there is now a zero at 500 MHz, which shouldn’t be there and is in none of my previous screenshots.

The question is: Is the the d/dt algorithm is still the same as on SDS2000? Is it still implemented as a simple finite difference between samples[j+N] and samples[j], where N is configurable, but >= 4? This finite difference approximation is equivalent to applying a boxcar average over N samples, in addition to the differentiation. I.e. it acts as an (undesired) lowpass filter. Then up-sampling is indeed supposed to reduce the unwanted lowpass effect, since N samples at the higher sample rate correspond to a shorter time interval. Also, allowing N=1 (w/o up-sampling) would help to reduce the unwanted lowpass effect (but not so much as with up-sampling).

Yes, it works still the same. As I’ve already stated back then for the SDS2000X HD, the resulting pulse shape and parameters do not depend on the dx parameter – well, at least not for a square wave and up to dx = 20. It seems obvious that it would be different on a sine.

I guess that we don’t get n < 4, simply because the operation gets really noisy then. On the 8-bit machines (where the math results were 8 bits as well), differentiation with low dx parameters was next to useless.

Btw, may I ask you to post .bin files of your pulse train signal and your square wave signal from the SDG, captured on the SDS800X at full BW and 2GSa/s, and if possible also a captured Bodnar square wave? [ Please not too few samples. If you don't mind, then even 100M points. In case of aliasing, there is a chance that a huge FFT can still separate folded aliases from the spectral lines coming from the 1st Nyquist zone, if the signal frequency does not correlate exactly with the sampling clock. The smaller the frequency deviation, the more FTT points are required for this separation. ]

As mentioned several times already, I don’t have a fast pulser like the one from Leo Bodnar. I would order one, but they are sold out at the moment. I would be able to create square waves with faster edges, but only at higher frequencies. But then again, I don’t think that it makes much of a difference for a 200 MHz device.

In fact, the amplitude of the pulse train is already significantly reduced to about 50% by the SDS824X HD frontend.

Well, here you go:

SDS824X_HD_Bin_Pulse_W1n_TR500p_C4

SDS824X_HD_Bin_Square_10M_TR500p_C4

[Martin72]

So it really doesn't seem to work like the 2000X HD...
I tried to recreate this, using the bodnar pulser as a signal.
It may be too "steep" with its 40 hp rise time, but I can't get your result - well, I could have overlooked something, but I don't want to rule it out.

[gf]

Furthermore, there is now a zero at 500 MHz, which shouldn’t be there and is in none of my previous screenshots.

Hmmm. A d/dt finite difference approximation with 4 samples interval (w/o up-sampling) is basically expected to have zeros at 500 and 1000 MHz. That's what I meant with "unwanted lowpass". However, with prior 20x up-sampling, I would expect the zeros to shift to 10GHz and 20 GHz. And obviously, you did up-sample. Was the d/dt possibly nevertheless calculated with a 2ns interval instead of 4 samples of the higher (40Gs/s) sample rate?

and since you seem to prefer spectrum analyzers...

I just thought it might be an option, too. Looks a bit rippled, though. Not so nice. Reflections?
You convinced me - it's obviously not the better option.

Thanks for the .bin files. I did take a first look. The differentiated square wave edges (doing my own differentiation) definitively contain more high frequency contents than the impuse train - which was to be expected. The difference is roughly what to be expected from a 1ns impulse width if I assume that the signals have been generated by applying the same ~500ps edge shaper to a) an ideal 1ns pulse train, and b) to an ideal square wave.

EDIT:

I guess that we don’t get n < 4, simply because the operation gets really noisy then. On the 8-bit machines (where the math results were 8 bits as well), differentiation with low dx parameters was next to useless.

n=1 works nicely with your data. Welch's method estimates a confidence interval of less than 0.1dB up to 500 MHz. So it is not very noisy for this particular use case. Also tried to truncate the data to 8 bits. Still worked nicely.

EDIT:

Added images (calculated from your data):
- figure1.png: comparison pulse train vs. differentiated square wave
- figure{3,4,5}.png: comparison pulse train vs. differentiated square wave, zoon-im to 100, 200, 244 MHz
- figure2.png: comparison of different d/dt methods w/o upsampling

About -3.1dB @244MHz with the square wave seems to be almost spot on

[gf]

So it really doesn't seem to work like the 2000X HD...
I tried to recreate this, using the bodnar pulser as a signal.
It may be too "steep" with its 40 hp rise time, but I can't get your result - well, I could have overlooked something, but I don't want to rule it out.

Yes, does not look right But no idea what might be wrong.
Does it work better with a slower timebase? (just a random guess)

[Martin72]

No....

F1 is the (20x) interpolation of Ch1, F2 is the diff of F1(4), F3 is the FFT of F2.
At least that's how I interpreted Performa01's settings.
Of course, this may not be entirely correct and I may have overlooked something.
Edit:
The formula that was "correct" for the 2000X HD was FFT(int(d(C1)/dt)), plus average 32 in the acquisition.
The result (without Avg32) of the 800X HD, see second picture.

[Performa01]

Hmmm. A d/dt finite difference approximation with 4 samples interval (w/o up-sampling) is basically expected to have zeros at 500 and 1000 MHz. That's what I meant with "unwanted lowpass". However, with prior 20x up-sampling, I would expect the zeros to shift to 10GHz and 20 GHz. And obviously, you did up-sample. Was the d/dt possibly nevertheless calculated with a 2ns interval instead of 4 samples of the higher (40Gs/s) sample rate?

Yes, there is most definitely something wrong.

I’ve filed a bug report and talked to Siglent R&D this morning. Here’s in brief what’s going on:

The math works with the original sample data, except for the Averaging acquisition mode, where there is no Dots display available, hence the interpolated data at time bases <50 ns/div have to be used. This is where the advantage for the SDS2000X HD came from.

Since the various Acquisition modes should behave identical when used as a math source, this is a platform bug and is already fixed (math will always use the interpolated data at fast time bases), so we’ll get that sorted with the next FW releases.

The other issue is that the Intrp() math function changes the visual appearance of the data on the screen (a lot more points), but quite obviously doesn’t make any difference when used as an argument for d(x)/dt. This is under investigation right now – maybe it’s already fixed as well…

Thanks for the .bin files. I did take a first look. The differentiated square wave edges (doing my own differentiation) definitively contain more high frequency contents than the impuse train - which was to be expected. The difference is roughly what to be expected from a 1ns impulse width if I assume that the signals have been generated by applying the same ~500ps edge shaper to a) an ideal 1ns pulse train, and b) to an ideal square wave.

Many thanks for the effort!

Yes, as I said, the SDS800X HD frontend cut the pulse train amplitude to one half already. And even so, a 10-90% rise time of 500 ps doesn’t quite fit a pulse width of 1 ns. Apart from that, I can only repeat one more time that with rise times below 1 ns, I’m operating the generator outside its specifications, which might also result in increased overshoot.

n=1 works nicely with your data. Welch's method estimates a confidence interval of less than 0.1dB up to 500 MHz. So it is not very noisy for this particular use case. Also tried to truncate the data to 8 bits. Still worked nicely.

Well, yes. I’ve looked up my old notes and the test back then has been with slow edges, like from a triangle wave. No wonder I’ve required a rather high dx parameter value to get a reasonable result. It worked beautifully in case of generating pulses from a square wave though, even with the old 8-bit SDS1104X-E.

Maybe I will suggest a lower limit of 1 to Siglent – even if it’s noisy in some use cases, there is still no harm done as we still have the full range up to 20 available.

About -3.1dB @244MHz with the square wave seems to be almost spot on

It’s always nice when theory meets exercise, isn’t it? 😉

[Martin72]

Last attempt:
Can you please name the settings that produced the result on your 824 ?
If my result looks so clearly different, I must have set something wrong.

[Performa01]

Last attempt:
Can you please name the settings that produced the result on your 824 ?
If my result looks so clearly different, I must have set something wrong.

Sorry, I have thought it should be obvious by now.

As stated in my last posting, it cannot work as it should, because there is a platform problem: upsampling (interpolation) quite obviously doesn't have any effect on the d(x)/dt math function. It still did work somehow on the SDS2000X HD, but only for time bases faster than 50 ns/div and Average acquisition mode, because the latter forced the math to use interpolated data - this time not coming from the intrp() function but from the acquisition engine directly. With the already confirmed fixes, this would work on the SDS800X HD too, because we'd get interpolated data and increased sample rate even in normal acquisition mode.

The other problem is that intrp() has not the desired effect on math functions that use it as argument. We get a higher sample rate on the FFT, but the result is not any different from differentiating the input channel directly. If this can be solved, then the method discussed here will also work at slower time bases.

My test worked somehow, albeit with huge errors, but that is only the result from 2 GSa/s, even when he FFT states 40 GSa/s, but this isn't true, at least not for the differentiation. Consequently, the result is like it was with just 2 GSa/s and this is also why we get the null at 500 MHz. And all this ruins accuracy of course.

I never had any special settings, everything is in plain view. Most striking difference: the time base. What abut trying 100 ns/div or even slower, like I did with all my previous attempts?

[Martin72]

With your settings* I´ll get these results, depending on the timebase..
I could try it again with the fast pulse (approx. 400ps risetime, approx. 200khz) from the batronix demoboard, but I don't believe that this will change anything.

* = https://www.eevblog.com/forum/testgear/math-problems-on-sds2k-(trying-to-display-bandwith)/msg5401265/#msg5401265

[gf]

With your settings* I´ll get these results, depending on the timebase..

100ns and 50ns look basically OK, the others not.
[ In order to see more details, vertical scale adjustment would be nice, say 5dB/div and ~150db (?) reference level. ]

EDIT: When I look at the levels of the peaks, then they seem to suffer from the same problem as Performa01's plot.

I could try it again with the fast pulse (approx. 400ps risetime, approx. 200khz) from the batronix demoboard, but I don't believe that this will change anything.

The lower the frequency, the denser the spacing of the teeth of the comb spectrum. But that needs more FFT points, too.
Do you mean a square wave, or a train of narrow impulses? (if the latter, what's the pulse width?)

[Martin72]

Afaik its a square wave, will look at it tomorrow.

I wonder why I don't get the same result with the same settings.
However, there are 2 things that are different with my attempts than with Performa01.
First of all the signal, which comes from the 40ps/10Mhz bodnar pulser.
Secondly, and you can definitely think this through, the scope model.
Performa01 has a "real" 824X HD, I have an 804X HD, which was turned into an 824 by a "trick".
That shouldn't really matter.
Actually.

[gf]

Look at Performa01's square wave frequency -> 20x lower.

EDIT: When I look at the levels of your peaks, then they seem to suffer from the same problem as Performa01's plot.

[Martin72]

Today with a much lower frequency (197kHz, the demo board can send different frequencies to the fast schmitt-trigger), this looks quite different - apparently it does not seem to "work" with "high" frequencies/smaller time bases.



The following is interesting:
I wanted to make the other signals visible for the screenshot, which were hidden by the marker window and turned the timebase to the left outside zero, nothing else changed...

[Performa01]

TThe following is interesting:
I wanted to make the other signals visible for the screenshot, which were hidden by the marker window and turned the timebase to the left outside zero, nothing else changed...

What you see is probably the effect of windowing.

I hate it to say, but for this kind of special measuement, the Rectangle window is the right choice. Try it and the position-dependance should be gone.

In general you need to keep in mind that the FFT doesn't process the entire screen width. In your example it is 8192 out of 10000 points, hence ~82%. But there are many scenarios where it's just 51.2%.

Therefore, whenever you want to analyze a single event like e.g. a transition, be aware that the FFT might be completely blind for the right half of the screen. As a consequence, do the following:

1. place the event between 20-30% of the screen width.
2. to get identical resuts independent of the position, use the Rectangle window.

EDIT: to get a smooth line, try a faster time base, like 200 ns/div.