Author Topic: Functional comparison of R&S RTB2000, Siglent SDS2000X and Keysight DSOX1000  (Read 33142 times)

0 Members and 1 Guest are viewing this topic.

Offline Martin72

  • Super Contributor
  • ***
  • Posts: 6413
  • Country: de
  • Testfield Technician
"Remember, only when everyone is starting at the same time, a comparison of the times makes sense."

(J.Malmsheimer)
"Comparison is the end of happiness and the beginning of dissatisfaction."
(Kierkegaard)
Siglent SDS800X HD Deep Review
 
The following users thanked this post: 2N3055

Offline bayjelly

  • Regular Contributor
  • *
  • Posts: 64
  • Country: us
This may be relevant to the discussion of the RTB2000's FFT functionality:

https://www.eevblog.com/forum/testgear/new-killer-scope-a-true-game-changer-from-rs-rtb2002-rtb2004/msg2375268/#msg2375268

Note that since I wrote this, there have been at least one or two new firmwares released. But I don't remember if there was a relevant change to how the FFT works specifically in that aspect. If anyone knows whether there have been any changes, please tell.
 
The following users thanked this post: egonotto, 2N3055

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
I finally got around to watch the FFT-video. Nice work, this was quite informative!

A couple of remarks nevertheless…

An average spectrum analyzer, especially an entry level model, can be a rather doubtful reference for certain parameters, like spurious free dynamic range and distortion. You really need to know how to setup the instrument for its maximum performance and a good DSO might easily outperform an entry level SA at frequencies of just a few MHz, especially when it can provide more resolution than just 8 bits. And your tests revealed this quite clearly.

The attached screenshot shows the actual distortion of a Siglent SDG6052X at 1 MHz. The strongest harmonics are -76 dBc down. I have no doubt that any SDG2000X will be at least as good as this, and it is quite evident that both the RTB and SDS got quite a bit closer to the truth than the “reference” SA. It is quite possible that the SA could have been able to deliver more accurate results with a careful setup.

Speaking of the SA, at the end of the video you said the SA was so much easier to setup compared to the scopes. Yes, it might be the instrument that is quickest to get some result, but as much as we value quick results, we usually value any results even more if we can trust them to be reasonably accurate.


One minor additional flaw is the comparison of different window functions. The SA inevitably uses FlatTop, whereas Hanning has been used on the DSOs, which can cause a bit of additional error if a measured frequency doesn’t happen to fall at the exact center of a bin. With a binary FFT, like 128 kpts (131072) and straight decimal frequencies like 1 MHz (1000000) it is extremely unlikely to be lucky and additional errors are inevitable.


The spurs are not that straight forward. Of course, if you disconnect the signal source, then everything that remains visible has to come from the analyzer or DSO itself. Any spurs emerging when the signal is applied need not come from the signal source though. Look at the attached screenshot again: the strongest spurs are below -110 dBc, so they could never be visible on a FFT that has a noise floor around -100 dBc.

So we learn that there is a third type of spurious signals, that are generated within the analyzer only when the external signal is present. These are known as intermodulation products, coming from interactions with internal signals that might be far outside the view of just 0-3 MHz but resulting in low frequency signals that happen to show up within our analysis span.

Of course, the probability to see such intermodulation products gets higher with more bandwidth and the situation gets better with higher resolution acquisition systems. A dense carpet of spurious signals might originate in the granular noise of the ADC. A genuine 10-bit instrument is more likely to cause less distortion and in any case, it should produce less granular noise. This is where the SA shines, because the digital signal processing is at least 14 bits, and usually more than that.


I’m not convinced that we need to get the proper FFT-settings by “trial & error”. It is all very predictable.

Reply #23 in the following thread has a complete checklist for setting up the FFT for a Siglent SDS2000. Many of the hints there will apply to any FFT implementation.

https://www.eevblog.com/forum/testgear/rohde-schwarz-rtb2002-vs-siglent-sds2104x-plus/msg3239832/#msg3239832


At the first part, you were unhappy because of the slow update rate on the SDS. It should be very clear that a 2 Mpts FFT at a slow timebase like 10 ms/div cannot update as fast as 128 kpts or even 64 kpts on faster timebases. Later, when you used 128 kpts on the SDS, it appeared to be the fastest in that group.


No need for speculations about the benefits of long FFT. Since the RBW is the sample rate divided by the FFT length, it is obvious that a long 2 Mpts FFT is just as desirable like narrow resolution bandwidths on a SA. While most classical SA can provide constant RBW throughout their bandwidth, the FFT bin width (hence also the RBW) in a DSO depends on the FFT-bandwidth, which in turn depends on the effective FFT-sample rate.  The RBW can only be narrowed by either reducing the effective sample rate or increasing the FFT length. At 2 GSa/s and 2 Mpts FFT we get a bin width of 1 kHz, which will result in a RBW of ~3.5 kHz in case of the FlatTop window. This is not very narrow, but then again this also results in a FFT-bandwidth of 1 GHz, which the DSO cannot provide anyway. For a 500 MHz FFT-bandwidth, we can just limit the sample rate to 1 GSa/s – by selecting a slow enough timebase to get more than 2 Mpts record length.

Why is a narrower RBW desirable? Because it provides better frequency resolution and lowers the noise floor.
With 2 Mpts, you can have a bin width of 50 Hz below 50 MHz (at 100 MSa/s) and this would enable you to check the modulation of even narrowband radio signals. Try the same with just 64 kpts and ~1500 Hz bin width – just hopeless.


I’m not sure if I missed something, but I seem to remember that you left the SDS at the default value of 4 when averaging. For comparable results, all contenders should use the same number of averages of course.


Axis annotation will have a sensible resolution in the next firmware. Among other things, this means just one place after the comma for the y-axis (dB).


It has been brought up by 2N3055 already, but since you repeated it over and over again throughout the video I want to make it clear again that the sorting of the markers is done in the table and it works as it should. In fact, the markers make absolutely no sense without the table, because without table we know absolutely nothing about them. The only reason why we can switch the table off is to get it out of the way if needed, without disabling the marker function altogether.


The icons in the file manager get an additional annotation in future firmware. So no more guesswork.


LISN: The SDS has a formula editor, which, among other things, allows FFT on the sum/difference of two input channels with only one math channel. That’s probably the trick that Keysight does implicitly to get that functionality out of a single math channel.

Since FFT is a math channel, the SDS can also show two FFTs at the same time. As a consequence, SDS could show one FFT on the common mode signal and another one on the differential mode signal simultaneously.

« Last Edit: July 17, 2022, 03:50:43 pm by Performa01 »
 
The following users thanked this post: 2N3055, Markus2801A

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
Dear Performa01,

Quote
I finally got around to watch the FFT-video. Nice work, this was quite informative!

Thanks, and thanks for providing feedback & new knowledge.

I think I can agree with about all you wrote. (Making these videos is also a learning experience for me, came across many things that seemed never documented or discussed).

I quickly checked the ability of the SDS to perform two FFT analyses at the same time, and it looks great! I have the impression that the FFT menu settings are individual for each of these, but settings such as the time base are, of course, common. It never came to my mind to check such simultaneous use, and I don’t think the manual or any other material I have seen refers to it. I think many people are happy to learn about it ;-)

Quote
Reply #23 in the following thread has a complete checklist for setting up the FFT for a Siglent SDS2000. Many of the hints there will apply to any FFT implementation.

Yes, I came across that checklist after I made my own video (the information on the EEVBlog Forum is so playful (but also scattered) that it is hard to overlook something, even if you think you searched carefully… Anyway, I can recommend this checklist to anyone.

Quote
Axis annotation will have a sensible resolution in the next firmware. Among other things, this means just one place after the comma for the y-axis (dB).
Quote
The icons in the file manager get an additional annotation in future firmware. So no more guesswork.

Good to know that there are plans to improve this type of thing! The last two firmware updates seemed to address few things only, and I was unsure about the pipeline. In my comparison document, I provide quite a list of wishes for the SDS2000X+ firmware. Not everyone would find all of them equally important (or disagree with some) but I think there is plenty of room to make this instrument more attractive to current and future users.

Hopefully, both the X and Y value axis will get to see some changes in the next firmware, and not only for FFT but for regular modes too.)
 
The following users thanked this post: Performa01

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
Quote
Axis annotation will have a sensible resolution in the next firmware. Among other things, this means just one place after the comma for the y-axis (dB).
Quote
The icons in the file manager get an additional annotation in future firmware. So no more guesswork.

Good to know that there are plans to improve this type of thing! The last two firmware updates seemed to address few things only, and I was unsure about the pipeline. In my comparison document, I provide quite a list of wishes for the SDS2000X+ firmware. Not everyone would find all of them equally important (or disagree with some) but I think there is plenty of room to make this instrument more attractive to current and future users.

Hopefully, both the X and Y value axis will get to see some changes in the next firmware, and not only for FFT but for regular modes too.)

Not just plans ;)
 
The following users thanked this post: 2N3055, blurpy

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
There were a lot of interesting comments on the last video regarding RBW, Frequency Interval △f, FFT Resolution, and Bin Width on an FFT oscilloscope, and I learned quite a bit myself from that.

I now made a shorter video (which benefited from direct input from 2N3055 and Perform01, thanks) that explores these terms in greater detail, in terms of theory but also how we can apply that theory to three oscilloscopes. In the end, the RTB poses a mystery...



 
The following users thanked this post: Performa01, egonotto, 2N3055, Markus2801A, adam4521, artik, Detlev, arvidb


Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
Thank you for this very revealing video!

I think you have covered all the important topics quite concisely.

I still want to emphasize the importance of knowing the Nyquist-bandwidth of the FFT, which absolutely requires the knowledge of the effective sample rate.

I've attached a screenshot to illustrate the problem:

SDS2354X Plus_FFT_Aliasing_RT1ns

We can see a pulse train with 1 ns rise time, which generates a spectrum of about 950 MHz if we include all the harmonics down to -80 dBm. This is not enough to cause any aliasing at the 2 GSa/s original sample rate as is shown in the Timebase tab. This means that the time domain representation of the signal is free from aliasing atifacts. Actually, even with only 1 GSa/s we wouldn't have much troubles in the time domain; the error caused by aliasing could hardly exceed 1%.

Now look at the frequency domain. There the decimated sample rate is just 1 GSa/s and we get an aliased spectrum folding back from 500 MHz down to 50 MHz (actually 950 MHz). This is visible because I chose 12 MHz as the repetition rate of the pulse. If I had chosen 10 MHz, the original and aliased signals would overlap and the aliasing might go unnoticed.

In this particular example, the aliasing is easy to detect. But there can be others where it is not so obvious and the aliased signals might accidentally be taken for real. Therefore it is essential to know the usable FFT-bandwidth. In this example it is 500 MHz and we can know in advance that a 950 MHz spectrum will cause false signals.

It should be obvious that the risk of a reduced FFT-samplerate gets lower with increased FFT-lengths. Considering this, it is baffling that the instruments with the short FFT lengths of all things don't provide that vital information.

 
The following users thanked this post: 2N3055, Martin72, RBBVNL9

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
Quote
I've attached a screenshot to illustrate the problem:

Excellent demonstration of how aliasing shows up in an FFT analysis! I do not have such a clean pulse source at hand, but if I did, it could be a neat way to investigate the RTB2004 mystery and determine what sample rate it is actually using...
 

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
I quickly checked the ability of the SDS to perform two FFT analyses at the same time, and it looks great! I have the impression that the FFT menu settings are individual for each of these, but settings such as the time base are, of course, common. It never came to my mind to check such simultaneous use, and I don’t think the manual or any other material I have seen refers to it. I think many people are happy to learn about it ;-)
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. The SDS6000A can even display four FFTs at the same time... ;)

Settings are individual except for the acquisition parameters and the timebase, as is true for all the other math functions likewise. The axis annotations as well as markers are only shown for the FFT in the foreground, that's largely consistent with the behaviour in the time domain view.

Now I've demonstrated the simultanous display of the spectra for the sum and difference signals in reply #3546 to the following thread:

https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4312450/#msg4312450

 
The following users thanked this post: RBBVNL9

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
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.

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! 
 

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
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 ?!?
 

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
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;
« Last Edit: July 22, 2022, 08:24:44 am by Performa01 »
 
The following users thanked this post: rf-loop, 2N3055, RBBVNL9

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
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.

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)





 
The following users thanked this post: 2N3055

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
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.

Code: [Select]
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.

 
The following users thanked this post: PeDre, 2N3055, Martin72

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
Dear Performa01,

Many thanks, that is a very extensive analysis, and it is in line with my intuition as well. I think we nailed it! Now on a road trip, but I will check in more detail once I'm back in the lab.

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

It's in the R&S RTB2004 brochure (here or here).



Like with all information I use, I tried to provide the source in my comparison document. For the FFT points, I noted there (B, p.3), which means Brochure, page 3. PS like with all three scopes I look at, not all information is systematically in the data sheet / spec sheet, sometimes it's in the manual, sometimes in the brochure, or somewhere in other documentation...




 
The following users thanked this post: Performa01, 2N3055

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
Here are the read-in FFT data as a comparison to the screenshots from the RTB2000.

So what we can see is that in contrast to the “Acquired Points”, the "Data Points" are actually bins. The provided text files contain 64k data entries - and that is equivalent to 128k FFT-points.

We can also see the effect of the time gate. But the screenshots also seem to reveal a major limitation of the RTB approach:

It looks like the FFT analysis bandwidth is solely defined by the start/stop or center/span frequencies. In this particular example, the upper bandwidth limit is about 809 kHz. Now what the RTB obviously does is multiplying that by two and then rounding up to the next feasible sample rate, which happens to be 2.05 MSa/s for an FFT-bandwidth of 1.025 MHz. I get the impression that it’s not possible to select the spectrum view independently of the FFT-bandwidth. Is there a way to set the spectrum analysis application up for e.g. 100 MHz analysis bandwidth and then zoom into any narrow span like 1MHz for closer inspection?

For 131072 samples and 2.05 MSa/s we should get an acquisition length of 63.93756 ms.

It is not quite clear why the RTB reports a time gate width of 63.96 ms in case of the minimum RBW of 60 Hz, but maybe the reported sample rate is not entirely correct due to some rounding errors. In any case we can assume that all the acquired data is used for the FFT.

For a RBW of 350 Hz, the time gate is narrowed down to 10.97 ms, hence we get about 131072 * 10.97 / 63.96 = 22480 points = 11240 bins. This reflects the exact ratio of the resolution bandwidths, as was to be expected. The originally acquired bin data gets decimated to 60 / 350 * 64k by simply cropping them. This way, there will be no reduction in sample rate and no unexpected aliasing.

 
The following users thanked this post: Markus2801A

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
>> This way, there will be no reduction in sample rate and no unexpected aliasing

For me, the ultimate test is to create a signal that results in a known aliasing tone. Then we can change (RBW) settings and confirm that FFT sample frequency remains constant. Will try when I’m back.
 

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
>> This way, there will be no reduction in sample rate and no unexpected aliasing

For me, the ultimate test is to create a signal that results in a known aliasing tone. Then we can change (RBW) settings and confirm that FFT sample frequency remains constant. Will try when I’m back.

You're absolutely right - I already wanted to suggest that. You don't need a pulse generator - any generator that can provide sine waves up to a few megahertz should be fine.

If for example you use that 2.05 MSa/s setup again, then you can feed a 900 kHz and 1.15 MHz into the RTB in sequence. In both case, you should see a spectral line at 900 kHz. Then try different RBWs and see if it always behaves the same. I'm pretty positive that it will...

 

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1698
  • Country: at
If for example you use that 2.05 MSa/s setup again, then you can feed a 900 kHz and 1.15 MHz into the RTB in sequence. In both case, you should see a spectral line at 900 kHz. Then try different RBWs and see if it always behaves the same. I'm pretty positive that it will...

This does not work like this. There are more FFT points than are displayed on the screen. You can zoom out in stop mode, and then the 900 kHz or 1.15 MHz signals appear.

Of course you have to perform this test without altering any parameters.

There are not more FFT points right from the start, but a good chance that the FFT will be recalculated with a different effective sample rate after altering the span even in stop mode, because the original raw acquisition was unlikely to be actually limited to 2.05 MSa/s.
 

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 333
  • Country: nl
Perhaps the best option is to simply export all 64k points (how whatever number there are) and search for the aliasing tones. This way, you’re not limited the screen resolution or screen re seeing algorithms…
 

Offline maxwell3e10

  • Frequent Contributor
  • **
  • Posts: 870
  • Country: us
This is a great review! I am just looking at these medium-range scopes for a specific feature: ability to do fast waveform averaging.

To test the speed of averaging I use a 1 Hz sine wave as an input, a short time base and minimum number of waveform points. One can use auto trigger or a 100 kHz or higher trigger source. Then switch acquisition to averaging mode and keep increasing the number of averages until the amplitude of the 1 Hz waveform oscillating on the screen reduces by 1/2 (the waveform appears as just a straight line going up and down).

Among the low-cost scopes I tested the winner appears to be Keysight EDUX1002 scope, which can do 128 averages before the amplitude of 1 Hz sinewave reduces to 1/2.

It would be great to test these scopes for this metric or any other than could be contender for fast real-time averaging.

 

Offline Markus2801A

  • Regular Contributor
  • *
  • Posts: 114
  • Country: at
  • Pobody’s Nerfect ;-)
    • KEM InfoPage
Thanks to the OP! This is an amazing thread and also shows us how much the solutions depend on settings and the used equipment, also the implementation of the FFT which seems to be very different or "interpreted" different by the engineers of those scopes.

IMHO it would be nice if the FFT follows the same mathematically way on all scopes to easer get readable, comparable und understandable solutions.

BTW: Has anyone tried to reconstruct the signal with the FFT solutions?
Teacher for electrical Engineering @ HTL and Werkmeisterschule :-)
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4131
  • Country: fi
  • Born in Finland with DLL21 in hand
I am just looking at these medium-range scopes for a specific feature: ability to do fast waveform averaging.

To test the speed of averaging I use a 1 Hz sine wave as an input, a short time base and minimum number of waveform points. One can use auto trigger or a 100 kHz or higher trigger source. Then switch acquisition to averaging mode and keep increasing the number of averages until the amplitude of the 1 Hz waveform oscillating on the screen reduces by 1/2 (the waveform appears as just a straight line going up and down).

Among the low-cost scopes I tested the winner appears to be Keysight EDUX1002 scope, which can do 128 averages before the amplitude of 1 Hz sinewave reduces to 1/2.

It would be great to test these scopes for this metric or any other than could be contender for fast real-time averaging.

Here Siglent SDS2000X HD

In this test I have used 1Hz sine, 600mVpp to channel 1
First three images oscilloscope run full speed without trig (Autotrig) 50ns/div (1kpts in one acquisition)
Persistence ON.
Measurement on. Only look statistics Pk-Pk value.
Maximum average  in this scope is 1024
First image without average, just normal acquisition.
Next image average 256  (just small drop)
Next image average 1024 (now roughly 2.5% drop. )

Because max average is 1024...
Next I force oscilloscope more slow using external trigger. When trig signal is 2.105kHz  with 1024 average finally 1Hz trace oscillation amplitue drop to roughly 50%
BEV of course. Cars with smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the (strong)wises gone?
 
The following users thanked this post: maxwell3e10

Offline maxwell3e10

  • Frequent Contributor
  • **
  • Posts: 870
  • Country: us
Thanks, so this scope can average quite fast! But the maximum number of averages is a little limited.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf