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.
Changing the RBW from 60 Hz to 350 Hz has no effect, except for the first two values for Value and Ratio.
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
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.