Products > Test Equipment
Functional comparison of R&S RTB2000, Siglent SDS2000X and Keysight DSOX1000
<< < (33/39) > >>
RBBVNL9:

--- Quote ---Yes, there might not be too many use cases, but it shouldn't be too much of a surprise: we can have two math channels at the same time and FFT is a math function - so this is to be expected.
--- End quote ---

I see your point. But I recalled an earlier thread somewhere on this board where someone said that Siglent had argued that the SDS2k+ only had two math channels because of limited processing resources. So I thought that for FFT, which is resource hungry (even if it's done in different places in the instrument), we'd only be able to run one instance at the time.

But it's great to have two instances, and, in my mind, there could be quite some use cases that could benefit from it! 
RBBVNL9:
Thanks, PeDre!

Triggered by your first email, I was actually checking all the SCPI commands related to FFT for different RBW settings. Something unexpected happens: when playing with different settings, the scope screen always says "Record Length 131 kSa" (equals 128k in binary language) in the acquisition menu, while the SPECtrum:WAVeform:SPECtrum:DATA:POINts? command returns different values, like 65536 (=64k) or 32768 (=32k), dependent on the chosen RBW settings.

Mmm. Seems the 'Record Length' is not showing us actual FFT points used, as I expected. Are the actual FFT points a subset of it ?!?
Performa01:
Since the RTB tries to emulate an SA, thus hiding the underlying math from the user, they might as well refer to frequency-bins instead of FFT-points.

Remember these relationships:

FFT-samplerate [Sa/s] / FFT-points [-] = bin-width [Hz];

and

FFT-bandwidth [Hz] / FFT-bins [-] = bin-width [Hz];

where

FFT-bandwidth [Hz] = FFT-samplerate [Sa/s] / 2;

and

FFT-bins [-] = FFT-points [-] / 2;
RBBVNL9:
Dear Performa01,


--- Quote ---Since the RTB tries to emulate an SA, thus hiding the underlying math from the user, they might as well refer to frequency-bins instead of FFT-points.
--- End quote ---

Thanks, I see your point. But I don't think it is going to be as simple as that.

In some cases, I see "Record length 131kSa" on the screen and 65536 (=64k) in response to SPECtrum:WAVeform:SPECtrum:DATA:POINts?

In other cases, I see "Record length 131kSa" on the screen and 32768 (=32k) in response to SPECtrum:WAVeform:SPECtrum:DATA:POINts?

So, in some cases there is a 1:2 relationship, but in others a 1:4 (and we can probably find 1:8 etc. as well).

PS. the SCPIcommand SPECtrum:WAVeform:SPECtrum:DATA:POINts? is described in the manual as "Returns the number of data samples that are returned with SPECtrum:WAVeform:xxx:DATA for the indicated waveform."

I think we are getting close and may actually find it all out, but not sure, of course (and my time to spend on this is a bit limited these days)





Performa01:
Meanwhile I had a totally different question: where does the claim of 128 kpts FFT-length for the RTB come from? I could not find the slightest hint in the datasheet or user manual.

But what can be found is that the time gate is changed according to the selected RBW. So, it is now officially confirmed that the FFT might only use a small subset of the acquired samples. What’s displayed in the UI is the original record length, but not the number of samples collected through the time gate.

For the actually used FFT-length there are at least two possible strategies:

1.   Optimize the sample rate for the narrowest possible RBW. That means, the sample rate will never be much higher than twice the upper bandwidth limit.
2.   Optimize the sample rate for the actually requested RBW. Make it just high enough to enable the required bin-width.

The latter approach would cause changes in the sample rate every time the user requests a different RBW. This would also change any aliasing artifacts, hence the overall appearance of the spectrum and might thus not be desirable.

The first strategy is the much more likely one; wider resolution bandwidths might be accomplished through decimation by narrowing the time gate.


--- Quote from: PeDre on July 22, 2022, 02:06:08 pm ---Changing the RBW from 60 Hz to 350 Hz has no effect, except for the first two values for Value and Ratio.


--- Code: ---Res Value; Res Ratio; Data Points; Data Header (4 Values); Acq Srate; Acq Points; Acq Points Arate
RBW 60 Hz:
6.003E+01;  3.13E+02; 65536; 0.000000E+00,1.024575E+06,65536,1; 2.05E+06; 131072; 2.0492E+06
RBW 350 Hz:
3.5019E+02; 5.36E+01; 65536; 0.000000E+00,1.024575E+06,65536,1; 2.05E+06; 131072; 2.0492E+06
--- End code ---

--- End quote ---

So, in both cases there are 131072 “Acquired Points” and 65536 “Data Points”. According to RBBVNL9 that ratio needs not be 2:1, so it should be always points and not bins. It would be only logical that the data points refer to the gate width, but from the numbers above this appears not to be the case. So it remains a bit of a mystery what the “data points” actually are.

Then the “Resolution Ratio”, described as “Span / RBW” is 313 in case of 60 Hz RBW and 53.6 for 350 Hz RBW. Let’s have a look:

RBW = 60 Hz; Bin-Width = ~16 Hz; 60 x 313 = 18780 Hz;
RBW = 350 Hz; Bin-Width = ~94 Hz; 350 x 53.6 = 18760 Hz;

The two different RBW both have a span of ~18.8 kHz in common, whatever this information is worth. This span quite obviously is just a viewing parameter and has nothing to do with the FFT-bandwidth.

Since PeDre has already delivered the numbers, let’s have a look at the maximum bandwidth:

Full span = 600 MHz and max. RBW = 23.8 MHz (Bin-Width = 6.4 MHz).
Full span = 600 MHz and min. RBW = 36.6 kHz (Bin-Width = 9.84 kHz).

In these cases, we know that the sample rate has to be at least 1200 MSa/s. That’s a sensible choice once the decision has been made that the maximum FFT-bandwidth shall be limited to 600 MHz.

1200 MSa/s / 6.4 MHz = 187.5 Points.
1200 MSa/s / 9.84 kHz = 122000 Points.

Aha. The minimum RBW conforms pretty well mit the maximum FFT-length of 131072 points. It would be spot-on if a factor of 4.00 for the FlatTop window is used (but the same factor does not work as well in other places, so we should stick to the more precise 3.72 for future calculations).

We also got the numbers for Rudi’s use case, where I have to assume 1 MHz FFT-bandwidth from the reported sample rate of 2.05 MSa/s.

Full span = 1 MHz and RBW = 60 Hz (Bin-Width = 16.1 Hz).
Full span = 1 MHz and RBW = 350 Hz (Bin-Width = 94 Hz).

From the known sample-rate we can calculate the FFT-lengths again:

2.05 MSa/s / 16.1 Hz = 127329 Points.
2.05 MSa/s / 94 Hz = 21809 Points.

The FFT-length is varied through the time gate, as expected.

How does this help us to understand what the RTB is doing? In actual fact, there are just a couple of parameters that really matter for any practical use case:

•   Effective samplerate
•   bin-width

We can know that the sample rate has to be at least twice the upper limit of the FFT bandwidth. The displayed sample rate is probably always correct anyway. If we choose the frequency range from 0 to 1 MHz, then we can expect an effective sample rate of 2 MSa/s.

What if we want to take a closer look in a low range like this if we have a signal with a much wider spectrum? In order to prevent aliasing, we need to determine that spectrum at full bandwidth first, then set the spectrum analysis for that bandwidth and zoom into the interesting region of the spectrum without altering the FFT parameters. Everyone can check how easy it is to follow such a strategy with the specific FFT-implementation in their instrument.

Real spectrum analyzers don’t have this particular problem – they have others 😉

By the way, there should be a possibility to determine the real FFT-length. The RTB displays the position and width of the time gate, so we should be able to calculate the percentage of the total record length that is used for the FFT. We could also calculate the bin width from the RBW, which in turn allows us to determine the actual FFT-length. But the FFT-length is just a means for the purpose and not so terribly interesting otherwise.

My conclusion for now is that the RTB most likely reports the correct sample-rate (and doesn’t change it secretly for the FFT), so this important information is indeed there.

Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod