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

[Performa01]

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).

[Performa01]

Here’s a demonstration what the SDS2504X HD looks like with a moderate ~500ps risetime pulse coming from the SDG7102A. 32x averaging before up-sampling.

Perhaps marker 1 horizontal position is better in ≥ 1/2 Δf 
(also looks weird your marker 2 vertical position looks like below trace level)

Thanks for the hint – this is when we get a creature of habit…

Yes, the accuracy is severely affected and I already wondered, why the frequency response appears better than it actually is.

Regarding the position of marker 2, there is nothing I can do about it. Might look into this later and see if the accuracy is affected by this. If so, I’ll file a bug report.

I have attached a cursor measurement and now the result is as expected, i.e. the measured bandwidth is only 520 MHz whereas it’s actually 570 MHz.

[gf]

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).

How is this actually implemented? Does it change the ADC clock phase for each acquisition being "averaged"?
RIS - as documented by LeCroy - rather requires a TDC and an analog trigger.

Or is it just a fractional sample time shift, in order to align the (interpolated) trigger points of the traces, after up-sampling?

[2N3055]

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).

How is this actually implemented? Does it change the ADC clock phase for each acquisition being "averaged"?
RIS - as documented by LeCroy - rather requires a TDC and an analog trigger.

Or is it just a fractional sample time shift, in order to align the (interpolated) trigger points of the traces, after up-sampling?

It is interpolated trigger time alignment. But there is no upsampling. Scope has it's internal "mathematical" timebase that is needed to be able to interpolate and align the triggers that is much finer than sample rate. Samples are mapped into that space.

So it reconstructs many points of the curve from repeated acquisitions, and retriggering timing that is not fully monotonic  and fact that sampling clock and external signal are not synchronised, performs same function that sequential/random sampling does.

Apart from excellent contributions by Performa01, I would also add that after you  average and differentiate, such created dataset will have some size that will not be same as a number of FFT  bins. Number of FFT bins will be a power of 2 number that will fit into dataset size.
That makes for an interesting contribution to this behaviour.

Namely, FFT should be performed only on a dirac pulse part of differentiated data, in such a way that the pulse is time centered in a data set.
Ideally a time gate should be used to pick a part of differentiated data that we want to FFT.

Sometimes you have a lot of data on screen but FFT picks just first 512 points.
If you then take horizontal position for time domain signal knob, and move that signal edge is to the left (or right) of the center, FFT will change. Of course it would, because it is looking only on part of the time of the data we see on the screen. FFT algorithm picks data on the beginning  of the buffer from the left (from the start) and takes what it decided it needs. Rest of the data to the right of that point is not taken into calculation.
That can be taken to the extreme such that if you start moving the edge to the right of the centre of the screen, at some setting you can make FFT plot showing nothing, because it looks only on the flat part of the curve to the left of the edge.

Complex math can get complex...

[gf]

It is interpolated trigger time alignment.

OK, just that (i.e. no special hardware support).

So it reconstructs many points of the curve from repeated acquisitions, and retriggering timing that is not fully monotonic and fact that sampling clock and external signal are not synchronised, performs same function that sequential/random sampling does.

The major difference is how the trigger time is determined.
A trigger point interpolation still suffers potentially from aliasing when the trigger is implemented fully digital.
OTOH, RIS overcomes the Nyquist limit with an analog trigger and TDC circuit, in addition to the ADC.

But there is no upsampling.

Performa01 got a 10x higher "virtual sample rate", though, in the screenshots above, when averaging acquisition was enabled.
I actually don't see how points with different arbitrary time could be averaged, so a re-sampling to a common regular grid (at higher resolution, say 1/10 sample) makes sense to me.
Then each of the the 10 bins per sample can be averaged. Some bins may still remain empty if the trigger point of no trace happens fo fall into their time slot.
In order to be suitable as input to operations that need a regular, non-sparse time grid (e.g. FFT), additionaly the empty bins need to be estimated/interpolated and filled-in.

Sometimes you have a lot of data on screen but FFT picks just first 512 points.

If the FFT window starts at the left edge of the screen, and if its size is not visualized (graphically) on-screen, then it is indeed difficult to center the signal of interest in the FFT window w/o manually calculating its size first [in seconds, or div].
Picking the FFT points from the center of the screen were IMO a more natural choice - then it were sufficient to center the data of interest on the screen.
Even better were a user-adjustable FFT window position, with proper graphical visualization.

[tv84]

Even better were a user-adjustable FFT window position, with proper graphical visualization.

That would be the best solution! Shouldn't be any rocket science and it would be very educational (for all users).

As it's usually implemented (without any of that info/choices) only experts like you guys are able to talk about it and have a real critic opinion of what is being shown. And as we been reading, even for you guys it's not easy to understand the factors behind what you are seeing.

[2N3055]

But there is no upsampling.

Performa01 got a 10x higher "virtual sample rate", though, in the screenshots above, when averaging acquisition was enabled.
I actually don't see how points with different arbitrary time could be averaged, so a re-sampling to a common regular grid (at higher resolution, say 1/10 sample) makes sense to me.
Then each of the the 10 bins per sample can be averaged. Some bins may still remain empty if the trigger point of no trace happens fo fall into their time slot.
In order to be suitable as input to operations that need a regular, non-sparse time grid (e.g. FFT), additionaly the empty bins need to be estimated/interpolated and filled-in.

I would call upsampling a interpolation of additional points between real sampled data by virtue of some interpolating math functions from single set of original data.

Siglent Averaging acquisition mode will take samples from several (even thousands) of separate trigger events and overlap them on top of each other. It is repetitive interlaced sampling so higher sample rates are very real.  As I explained, trigger interpolation IS used to map sampled data to much higher resolution  time grid and that is what scope internally has.  So sampled data are simply realigned in time and placed in a time grid that is much more granular that ADC sample rate. Such aligned sets of data can be then overlapped on top of  each other and averaged.
If data is sparse in some places, local to that  point averaging will not be as good and there will be larger apparent noise there,  worse than for the parts of curve where data is more dense.... But still very useful and big improvement.


You are not resampling but simply reassembling the full buffer from separate triggers that are taken with certain offsets from trigger point.. that is why I said "upsampling" is not exactly correct..

Trigger time is not determined. Trigger time is time zero. Exact point of trigger is determined by interpolation and samples are then adjusted to fit in time domain where they belong. Trigger simply starts the process of acquisition, samples are stored in memory, and exact time of trigger event is calculated, and timing of sample points is adjusted. Meaning that timing info of some point in curve relative to trigger point is accurate on a single picosecond level, much less than the sampling period.

[2N3055]

Even better were a user-adjustable FFT window position, with proper graphical visualization.

That would be the best solution! Shouldn't be any rocket science and it would be very educational (for all users).

As it's usually implemented (without any of that info/choices) only experts like you guys are able to talk about it and have a real critic opinion of what is being shown. And as we been reading, even for you guys it's not easy to understand the factors behind what you are seeing.

Yes, that would be ideal. Unfortunately not even all high ends scopes have all the controls...
In ideal world, a markers should be shown what is being FFT-ed and those markers could be set left and right...
I'm not sure how realistic is to expect that on this scope...
But it can be optimized to have more predictable behaviour..
It is reported...

[Martin72]

In ideal world, a markers should be shown what is being FFT-ed and those markers could be set left and right...

Hmmm......
If I got the time tomorrow, I´ll have a look on the wr9054.
Afaik as I´ve played with the fft, I saw "suddenly" 2 dashed lines and wondered because I didn´t had the cursors activated.

[2N3055]

In ideal world, a markers should be shown what is being FFT-ed and those markers could be set left and right...

Hmmm......
If I got the time tomorrow, I´ll have a look on the wr9054.
Afaik as I´ve played with the fft, I saw "suddenly" 2 dashed lines and wondered because I didn´t had the cursors activated.

As I said, that is a Waverunner 9000.. It should support gated FFT...

[Martin72]

Hi,

Afaik as I´ve played with the fft, I saw "suddenly" 2 dashed lines and wondered because I didn´t had the cursors activated.

Today I got a phone call with someone from lecroy* and now it´s clear to me.
These are helplines to show you what will be "ffted" in the screen, it varies with the modes truncated, non-truncated and zero-filled.
You can´t set them manually as a gate.
Nevertheless it helps to understand.

Martin

*) This is the lecroy service...I´ve mailed them because of the lines and more or less immediately (from friday to monday) I´ll get a phone call.
Together with the hint, call us everytime you have a question, you bought a lecroy scope so you also bought our directly support.
This is what the A-brands separates them from the rest, today.

[tautech]

Has the new FW fixed this ?

New firmware for SDS2000X Plus
5/23/2022 1.3.9R12 1. Fixed several bugs of 1.3.9R10

[Martin72]

Hi Rob,

Didn´t try because it seems that this is an update for the models with "different" hardware, like the update 1.3.9R10 before was.

[tautech]

Hi Rob,

Didn´t try because it seems that this is an update for the models with "different" hardware, like the update 1.3.9R10 before was.

Please don't accept release notes word for word.
Let's make it easy for you to check to be 100% sure. 
https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS2000X%20Plus_V1.3.9R12_EN.zip

[Martin72]

Don´t you have a sds2k+ anymore ?

[Martin72]

Please don't accept release notes word for word.

Nothing has changed except the displaying version number of the firmware..
Did this upgrade at last in the hope, the stupid axis-labeling was corrected, but it wasn´t.

Martin
edit pic attached.

[hpw]

So run now the R12 FW and did get some nice plots... sometimes the Config/Full Span or Peak To Center has to be clicked again....

do not understand why the center is at 5GHz...


hp

[Martin72]

Edit: Threadtitle changed.

Here’s a demonstration what the SDS2504X HD looks like with a moderate ~500ps risetime pulse coming from the SDG7102A. 32x averaging before up-sampling.

Hi.....
In the meantime I also own a SDS2504XHD and remembered this thread.
So I wanted to recreate Performa01 measurement, this is what I get(see picture).
Am I doing something wrong ?
Looks not so linear for now, also my bandwidth is far from the 500Mhz.
I took the interpolation from rf-loop (20, Dx 4) and like Performa set the FFT to AVG 32.
Same time base.
Is it possibly the signal from the bodnarpulser ? Is it "too steep" ? Performa01 and rf-loop did not use it for their measurements.
Additionally a picture of the risetime of the pulse.
If you use the formula, this is also not 500Mhz.

[gf]

Is it "too steep"

It certainly is too steep for 2GSa/s. The key to benefit from fractional sample trigger points and to obtain "RIS-like" sampling seems to be Averaging acquisition mode:

Here’s a demonstration what the SDS2504X HD looks like with a moderate ~500ps risetime pulse coming from the SDG7102A. 32x averaging before up-sampling.

I think you did not turn it on, did you?

[Martin72]

Thankyou gf!
In fact, I overlooked it, or thought that it was the averaging of the fft.
Now the situation looks completely different...


edit forget the second marker...

[Performa01]

edit forget the second marker...

Forget the first marker too. You made the same mistake as I did back then (rf-loop pointed it out). You cannot place a marker at 1 MHz when the FFT frequency step is 24.41 MHz...

[gf]

edit forget the second marker...

Forget the first marker too. You made the same mistake as I did back then (rf-loop pointed it out). You cannot place a marker at 1 MHz when the FFT frequency step is 24.41 MHz...

Btw, I don't know where this comes from, but the 0.5 dB drop in the DC bin doesn't look right either. So I would not use this bin as reference level.

[Martin72]

I´ll repeat the measure...

[Martin72]

Am I just about to...
Quick question:
It was interpolated 20-fold according to the entered formula.
Before I set the acquisition mode to average, 40GSa/s came out, see the pictures before the last one.
Now that I have last set to average 32, it is 400GSa/s (see last picture) is that correct ?

[Martin72]

OK, finished for today...

This time I used the cursors for finding the -3dB frequency, that should be "allowed" for this.
1.5Ghz span and 5dB/div settings, 515Mhz....

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.
(possibility to change the axis-labeling left/right would be very, very useful for a better viewing.)