Products > Test Equipment

Functional comparison of R&S RTB2000, Siglent SDS2000X and Keysight DSOX1000

<< < (30/39) > >>

RBBVNL9:

--- Quote ---It is possible the FFT size varies on the RTB. In recent firmware R&S improved the performance when using low frequencies but I don't know whether 8kHz counts as 'low'. If you use a higher frequency (8MHz for example) I guess (!!!) variable FFT size won't be used. It is worth a try.
--- End quote ---

While my regular test was on an 800kHz signal, I also did try an 8Mhz signal, but it did not change anything. Maybe I should go even higher, to find out whether indeed FFT point size varies depending on settings... 


--- Quote ---Never forget that there can be two different dample rates:
--- End quote ---

Yes, I was aware of this. But as I think you already noted, this does not seem to be the explanation here, because the Flat Top window scenario was 'correct' and the Hanning scenario was 'not correct' (at least, not what I expected). If it was a wrong sample rate used for the calculations, it would have been wrong everywhere.


--- Quote ---So it's essential to look at the FFT samplerate, like it's reported by the SDS in the FFT info block and not the sample rate in the timebase tab.
--- End quote ---

Well, interesting enough, on my  SDS2000X+ these values are (typically?) the same... When it reads "Sa=40.00MSa/s" in the FFT info block at the top of the screen, I also see "40.0MSa/s" in the grey "timebase" at the bottom. But the calculations I did of  “Frequency interval (△f)” (a.k.a. FFT frequency spacing a.k.a. the "bin-width") were always spot on when I used this sample rate value.

Performa01:

--- Quote from: RBBVNL9 on July 15, 2022, 05:42:46 pm ---

--- Quote ---So it's essential to look at the FFT samplerate, like it's reported by the SDS in the FFT info block and not the sample rate in the timebase tab.
--- End quote ---

Well, interesting enough, on my  SDS2000X+ these values are (typically?) the same... When it reads "Sa=40.00MSa/s" in the FFT info block at the top of the screen, I also see "40.0MSa/s" in the grey "timebase" at the bottom. But the calculations I did of  “Frequency interval (△f)” (a.k.a. FFT frequency spacing a.k.a. the "bin-width") were always spot on when I used this sample rate value.

--- End quote ---

Yes, it's easy enough to predict. When you set the FFT length to its maximum of 2 Mpts, there will be no difference as long as the record length does not exceed 4 Mpts (because 2 Mpts FFT means 2097152 data points, whereas a record length of 2 Mpts would only be 2 million samples, so you need more than that to process a 2 Mpts FFT).

As soon as the record length exceeds the FFT length - either by limiting the FFT size to something small like 64k or selecting slow timebases where the scope needs a lot of memory, the FFT sample rate cannot keep up with the maximum 1/2 GSa/s anymore and decimation will occur.

RBBVNL9:
Peter,


--- Quote ---The number of FFT samples is displayed in the Acquire/Acquisition Menu under Record Length.
--- End quote ---

For all the experiments I did, this number was equal to "131kSa", which equals 128k * 1,024 (wherein the first number, the 'k' is used as in the SI sense, and in the second in the binary sense). So it indeed makes sense that is the number of FFT points.

But since it does not seem to vary in my experiments, it suggests that the number of FFT points is always 128k (at least for the experiments I did), and the speculation that the number of FFT points drops in certain circumstances (at least across my experiments) would be false.

So, I think we l still have not found the explanation for what I seem to see... Fascinating.

RBBVNL9:

--- Quote ---... Maybe I should go even higher, to find out whether indeed FFT point size varies depending on settings... 
--- End quote ---

Now also tried for a 80MHz sine wave. Still the same thing, the minimal selectable RBW for Hanning window is larger (so less resolution) than for Flat Top windows. Mmm.

And also at 80MHz centre, the record length always remains at 131kSa (=128k FFT points), regardless the chosen window type.

2N3055:
And I hope now you understand my comment about RTB2000 implementation actually being one that is confusing..
When FFT is rigorously implemented as FFT, you can compare (and repeat calculations on data) between different scopes or even feed raw time domain data to Matlab or some FFT library and verify results. Also, if you have data from some calculations or simulations, you can compare like for like.
It is well known what windows are, how they behave... It takes a bit of learning, but it is good knowledge that is very useful anyways (Fourier transform is one of the really important things to know in what we do, hobby or pro). It very much deepens your understanding of things...

As I said, RTB2000 implementation is a implementation that is made to be simpler to have something displayed on the screen faster and for quick checking it is useful and it is quicker. Nico mentioned GW-Instek, on their MDO series their realtime SA implementation is much superior to what RTB2000 has. Up to 1 Mpoints and very fast and proper implementation of real time SA. It is only 8 bit converter so it cannot get results of the proper SA but very good nevertheless.. But still, like Nico said, the also implemented proper FFT mode, for when you need real FFT....

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