Products > Test Equipment

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

<< < (14/19) > >>

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:

--- Quote from: gf on March 19, 2024, 08:48:39 pm ---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?

--- End quote ---
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…



--- Quote from: gf on March 19, 2024, 08:48:39 pm ---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.

--- End quote ---
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.



--- Quote from: gf on March 19, 2024, 08:48:39 pm ---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.

--- End quote ---
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.



--- Quote from: gf on March 19, 2024, 08:48:39 pm ---About -3.1dB @244MHz with the square wave seems to be almost spot on :)

--- End quote ---
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:

--- Quote from: Martin72 on March 20, 2024, 01:04:44 pm ---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.

--- End quote ---
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod