The “Dx” parameter in the SDS2000X Plus math refers to sample points and we actually need to take the sample rate into account whenever we want to convert it to an absolute time.
At 20ns/div and 10ns/div, FFT(Cx) shows a sample rate of 50GSa/s, and at 5ns/div it shows a sample rate of 200GSa/s.
Well, that’s the problem. An SDS2504X HD for instance doesn’t show this weird behavior. FFT sample rate remains 2 GSa/s all the way down to 500 ps/div – and so does the SDS2000X Plus, as long as there is no d/dt expression as argument for the FFT.
This is obviously the interpolated sample rate, and it seems that interpolation joins in automatically at <= 20ns/div.
I’ve checked the d/dt operation for the SDS2000X Plus – width and delay of the numerically generated pulse remain constant for any given Dx setting, regardless of the time base, hinting on a constant sample rate.
You are certainly right in that there is an interpolation kicking in at time bases where the number of samples is too low to fill the screen buffer. For the screen display this is selectable linear (x) or Sinc (sin(x)/x) or off (dots mode), but for automatic measurements it is always there in the background. This enables time measurements with much better resolution than what could normally be expected from 2 GSa/s. I don’t have the details, yet I think the math usually doesn’t use the interpolated data.
It just so happens that we’ve already identified a bug regarding the interpolation. It operates quite differently than on other Siglent scopes and it is obviously wrong, if only because the interpolation method x or sin(x)/x still affects dot mode. All in all, I strongly suspect that this current bug with the FFT(d(X)/dt) math is just another symptom of this very bug. Anyway, my report about incorrect FFT sample rate has already been confirmed by Siglent by now, so we can expect a fix for the next FW update.
What is dx=4 now supposed to mean at (say) 10ns/div? Still 2ns (4 / 2 GSa/s), or 80ps (4 / 50 GSa/s)?
According to my investigations, it strongly looks like it’s always operating at the original (true) sample rate. Consequently, a Dx parameter of 4 means dt = 2 ns in half channel mode.
EDIT: Looking at the image in your previous message it must be (significantly) less than 2ns, otherwise the spectrum would look different.
This is certainly true but has a different cause. The math for this test is FFT(Intrp(d(C4)/dt)); applying an upsampling coefficient of 20, we get an FFT bandwidth of 40 GSa/s and the result isn’t very convincing yet.
See attached screenshot. The upper window shows the original pulse edge at 10 ns/div and math channel F1 that processes just d(C4)/dt, hence showing the pulse from the differentiated transition.
SDS2504X HD_Math_FR_10ns_Normal
Only the averaging in the acquisition menu makes things work, see the second screenshot:
SDS2504X HD_Math_FR_10ns_Avg16
The FFT-bandwidth has increased by a factor of ten and you can also compare the properties of the pulse that results from math function F1. The additional data gained from averaging are true samples and not interpolated redundant data as with Intrp(), therefore the d/dt operation with Dx = 4 now actually works with a 200 ps step. Since this is similar to RIS (Random Interleaved Sampling), some resampling/interpolation is still required to translate the additional data into an evenly spaced sample stream. This could also be the reason why the increase in sample rate does not conform with the number of averages (16 in this example).