Siglent SDS2204X. Any good?

[kcbrown]

The Siglent's memory buffer is very large and looks to be quite nice in terms of one's ability to scan through frames with it.  I can't tell from reading the manual whether or not it's possible to run the remembered frames through the pass/fail system.    It looks like the Instek 1000B series doesn't implement segmented memory, but the 2000E series does.

Nice to see some reasoned discussion. 

I do try to be as objective as I can be.   

Why would you need to run stored frames against a Pass/Fail when the feature itself is much faster running live ?

Because if you can run stored frames against the pass/fail system, then it means you can change the pass/fail waveform after the fact, which would make it possible to look for waveforms with multiple simultaneous characteristics.   It would also allow you to capture a batch of waveforms on the basis of a trigger and then examine the waveforms that surround the failures, something that it's not clear to me you can do with a standard pass/fail setup.

This could be especially important if you're using the MSO capability.  Imagine, for instance, that you're looking for the digital conditions that immediately precede some other signal (say, an analog output) going bad.  With the ability to run your captured waveforms through the pass/fail system, you'd be able to quickly find the location of the failure and then scroll backwards to examine the digital state that immediately preceded the failure.   Can such a thing be done with the existing pass/fail system?

[tautech]

Because if you can run stored frames against the pass/fail system, then it means you can change the pass/fail waveform after the fact, which would make it possible to look for waveforms with multiple simultaneous characteristics.   It would also allow you to capture a batch of waveforms on the basis of a trigger and then examine the waveforms that surround the failures, something that it's not clear to me you can do with a standard pass/fail setup.

This could be especially important if you're using the MSO capability.  Imagine, for instance, that you're looking for the digital conditions that immediately precede some other signal (say, an analog output) going bad.  With the ability to run your captured waveforms through the pass/fail system, you'd be able to quickly find the location of the failure and then scroll backwards to examine the digital state that immediately preceded the failure.   Can such a thing be done with the existing pass/fail system?

Why would you just not use the already capable Trigger suite ? 

FYI the Pass/Fail can only be assigned to one waveform.

[rf-loop]

Yep, that's certainly a potential advantage for the Siglent, especially if those are also stored along with the analog waveforms in the segment system.  Are they?

Due to lack of time only this.

I have not SDS2000X at this time for test.

But functionally  SDS1000X+ (SDS1000X  with 16ch LA + AWG)
is very near SDS2000X (with much lower processing power and only two analog channels etc)

Fast Sequence mode can not use if LA is on. 

But, now need understand how it works because there is two kind of "segmented memory"

1. Normal run (always with history buffer) (with current wfm/s speed, (in SDS1000X/X+ series max 60kwfm/s for analog channels only on)

If LA on, maximum wfm/s is far more low than 60kwfm/s.  But MSO (analog + LA together) but wfm history buffer store LA and Analog together.  In practice this is just as segmented memory acquisition but it run always backround. Only difference is that this run with current wfm speed with normal live screen.


2. Sequence mode, in SDS1000X/X+ specified over 400kwfm/s (ksegment/s) (in my tests, explained in some thread here) measured quaranteed max 485ksegm/s)  This mode available only for analog channels.
In this fast sequence mode during sequence capture it do not update display or do any other post processing during one sequence acquisition (if run in continuous mode. Afteer sequence is ready it process all segments for display so that  all wfms (segments) overlayed on the screen at once and then continue next sequence). This give all possible resources for acquistion with minimized trigger rearm.

Mask test can not run for history buffer, independent of history buffer acquisition method (fast sequence segments acquisition or normal speed wfm/s (segments) acquisition) (this buffer maximum length is 54M in SDS1000X but length is not simply fixed, so all 54M is not always in use) SDS2000X memory is very different. Measurements and math can run also for history/sequence segment buffer.

(SDS1000X but principle is same in SDS2000X)


I think it is same in SDS2000X exept that it have much more memory and much more processing power.

[kcbrown]

Because if you can run stored frames against the pass/fail system, then it means you can change the pass/fail waveform after the fact, which would make it possible to look for waveforms with multiple simultaneous characteristics.   It would also allow you to capture a batch of waveforms on the basis of a trigger and then examine the waveforms that surround the failures, something that it's not clear to me you can do with a standard pass/fail setup.

This could be especially important if you're using the MSO capability.  Imagine, for instance, that you're looking for the digital conditions that immediately precede some other signal (say, an analog output) going bad.  With the ability to run your captured waveforms through the pass/fail system, you'd be able to quickly find the location of the failure and then scroll backwards to examine the digital state that immediately preceded the failure.   Can such a thing be done with the existing pass/fail system?

Why would you just not use the already capable Trigger suite ? 

If the trigger suite is capable of combining trigger conditions (such that it triggers when all such conditions are present or when at least one such condition is present -- you'd obviously want to be able to tell the scope which of those combinatorial operators to use), then obviously that's what you should use.  Is the Siglent's triggering mechanism capable of that?

FYI the Pass/Fail can only be assigned to one waveform.

Yes, I understand that.  What I was getting at is that if you can run recorded frames past the pass/fail system, then you could have an initial capture based on one waveform, and then perform a second run of the captured data against a different waveform.   That might not be terribly useful if you could simply combine the two waveforms, but I'm skeptical that all combinations of waveforms can be combined in that way (they can if you can define and upload arbitrary masks, and since the Siglent can load masks from external media, that at least suggests the possibility of creating arbitrary ones).

For instance, suppose your actual pass condition is a sine wave with either 0 degrees phase shift relative to your trigger or a 90 degree phase shift.  You'd want it to fail on anything that isn't one of those.  It's not clear to me that you'd be able to construct a single pass/fail waveform that captures that requirement (at least, not that wouldn't be overinclusive in terms of what would pass it).  But if you can perform a single capture of the failures against the 0 degree phase shift waveform, and then filter the result against a 90 degree phase shift waveform, you'd have some ability to detect instances of failure to match both conditions.

I'm not arguing that one would necessarily find a lot of use for such a capability.  But I imagine that such a capability wouldn't go entirely unused, either.

[tautech]

If the trigger suite is capable of combining trigger conditions (such that it triggers when all such conditions are present or when at least one such condition is present -- you'd obviously want to be able to tell the scope which of those combinatorial operators to use), then obviously that's what you should use.  Is the Siglent's triggering mechanism capable of that?

There's an extensive suite and within each Trigger type there's a # of definable parameters.
From the manual:
http://www.siglentamerica.com/USA_website_2014/Documents/UserManual/SDS2000X_UserManual_UM0102X-E01A.pdf
P58
Suite:
Edge trigger
Slope trigger
Pulse trigger
Video trigger
Window trigger
Interval trigger
DropOut trigger
Runt trigger
Pattern trigger
And the Decode Trigger suite that is standard.

If you want to check them out in detail the manual has a good description for each.

Pass/Fail
I admit my lack of experience in using this and there are use cases where functionality that presently doesn't exist could indeed be useful. Instead I seek out the examples that rf-loop has posted and his comparisons against other brands.

Then I wonder if using some advanced Trigger and then sampling the Trigger out might not serve the same function ?

[kcbrown]

If the trigger suite is capable of combining trigger conditions (such that it triggers when all such conditions are present or when at least one such condition is present -- you'd obviously want to be able to tell the scope which of those combinatorial operators to use), then obviously that's what you should use.  Is the Siglent's triggering mechanism capable of that?

There's an extensive suite and within each Trigger type there's a # of definable parameters.
From the manual:
http://www.siglentamerica.com/USA_website_2014/Documents/UserManual/SDS2000X_UserManual_UM0102X-E01A.pdf
P58
Suite:
Edge trigger
Slope trigger
Pulse trigger
Video trigger
Window trigger
Interval trigger
DropOut trigger
Runt trigger
Pattern trigger
And the Decode Trigger suite that is standard.

If you want to check them out in detail the manual has a good description for each.

All that looks pretty standard.  I'm primarily a software guy, so seemingly arbitrary limitations are something of an anathema to me.  But in this case, I expect that the triggering system limitations are not arbitrary at all!  Rather, they're determined by what you can reasonably detect in hardware (I suspect that even protocol triggering is something that has a very large hardware component to it, with perhaps a highly optimized software component at the final stage).

It occurs to me that if the Siglent were capable of triggering off the math output, then you might be able to do some amount of combinatorial triggering.  But I don't see anything that lets you set the math output as a trigger source.  Indeed, I'm skeptical that any scope is capable of that.

Pass/Fail
I admit my lack of experience in using this and there are use cases where functionality that presently doesn't exist could indeed be useful. Instead I seek out the examples that rf-loop has posted and his comparisons against other brands.

Then I wonder if using some advanced Trigger and then sampling the Trigger out might not serve the same function ?

Well, it would be entertaining if one could wire the trigger out right back into the trigger input and have that work.      But methinks the scope's triggering system is already preoccupied by that point.   

Certainly if one had multiple scopes, one could do combined triggers.  But the idea here would be to minimize the need for that.

Anyway, we've moved rather far afield from the OP's original questions.   With respect to the Siglent vs the Instek, it looks like (as one would expect) they each have their advantages and disadvantages.  I think Siglent would do very well to implement a search capability against recorded waveforms akin to what Instek has implemented.  I think it would make Siglent's massive memory depth a lot more useful than it already is, and would put their scope head and shoulders above anything else.  You might suggest to them that they do precisely that, if you're so inclined.

For what it's worth, I don't think Instek implements any sort of ability to run recorded waveforms past their pass/fail mechanism either.  While such a thing might have limited uses, lack of it seems to be something of an arbitrary limitation, seeing how the pass/fail mechanism already exists.   How feasible it would be to implement such a thing surely depends on the way the pass/fail mechanism is already implemented.  It may be that it simply can't be implemented against already-recorded waveforms, at least without a lot of work.

[kcbrown]

My thanks to rf-loop for brining the technical details of the Siglent X series scopes.  That's good stuff there.   

[nctnico]

Maybe it is time to list the strong points of the GDS-2000E series as well:
- Fast hardware platform with quad core 1GHz ARM so it can do all kinds of waveform operations/measurements fast
- SCPI command over LAN (LXI) so you can telnet to the scope and send it commands by typing them
- Save data (images, samples data, etc) onto a network share directly over LAN
- Data logging
- Save screendumps in PNG format
- Up to 1MPts FFT
- Free form math equations
- Search function for trigger condition and peaks (for example a list of peaks in FFT)
- Statistical analysis of measurements over recorded segments
- Protocol decoding over the entire memory (up to 10MPts)
- UART protocol decoding has (limited) support for message/packet based protocols
- Triggering on specific data inside a protocol
- Input filtering (low, band and high pass)
- Peak detect also works in roll mode
- Reference traces can be used for analysis (math), saved/recalled using waveform data, scaled (horizontal/vertical) and moved (horizontal/vertical)
- Seperate select button and rotating knob which works better than when combined in one.
- Force trigger button
- User sets the record length. Automatic is terrible because often you'll want to zoom in or scroll left/right and if the automatic length is short you'll have no data to look at.
- Lifetime warranty (ends 5 years after GW Instek stops producing the model)
- Last but not least: no bugs I'm aware of and if I do find one GW Instek has proven to be able to fix them quickly.

Also don't get wound up about waveforms/s. It is a purely hypothetical number which can only be achieved at a specific time/div setting in dot mode. For starters nobody uses dot mode on a scope because it just doesn't draw a visible signal in many cases. Also the idea behind a high waveforms/s number is that you have a higher chance of seeing rare glitches. Unfortunaly many don't factor in that people blink their eyes and may want to take a coffee break.

BTW The wind turbine remark of rf-loop is way off. The fan in the GDS2000E series doesn't need replacing at all and (after mounting it with rubber fan mounts) the sound level is on par with what you'll get from the SDS2000X series. Maybe GW Instek already addressed this issue because I got a relatively early model produced two years ago when posting this.

[voltsandjolts]

GW Instek Warranty:

http://www.gwinstek.com/en-US/Page/warranty_service_procedure

Note: GW Instek GDS-2000, GDS-1000A, GDS-1000A-U, GDS-1000, and GDS-1000-U series DSO has a lifetime-warranty period. All Products with LCD displays carry a warranty for one year.

 

[kcbrown]

Also don't get wound up about waveforms/s. It is a purely hypothetical number which can only be achieved at a specific time/div setting in dot mode. For starters nobody uses dot mode on a scope because it just doesn't draw a visible signal in many cases. Also the idea behind a high waveforms/s number is that you have a higher chance of seeing rare glitches. Unfortunaly many don't factor in that people blink their eyes and may want to take a coffee break.

Some people seem to believe that the high waveforms/sec number is useful so that the user has some chance of seeing a rare glitch or something, certainly.  But that some people believe that doesn't mean that such is what a high waveforms/sec number is good for.

No, the real reason a high waveforms/sec rate is desirable is that it is indicative of the speed of the acquisition and processing engine, and that is useful because you can then turn that capability towards having the scope automatically detect anomalies.

While a high waveforms/sec rate is no guarantee that the scope will have a high probability of such automatic detection, a low waveforms/sec rate is essentially a guarantee that the scope will not have that.

BTW The wind turbine remark of rf-loop is way off. The fan in the GDS2000E series doesn't need replacing at all and (after mounting it with rubber fan mounts) the sound level is on par with what you'll get from the SDS2000X series. Maybe GW Instek already addressed this issue because I got a relatively early model produced two years ago when posting this.

Opening the scope is often sufficient grounds for a warranty claim denial, so performing that kind of surgery has to be done with that fact in mind.  One would hope that Instek has addressed that issue, however...

[nctnico]

Also don't get wound up about waveforms/s. It is a purely hypothetical number which can only be achieved at a specific time/div setting in dot mode. For starters nobody uses dot mode on a scope because it just doesn't draw a visible signal in many cases. Also the idea behind a high waveforms/s number is that you have a higher chance of seeing rare glitches. Unfortunaly many don't factor in that people blink their eyes and may want to take a coffee break.

Some people seem to believe that the high waveforms/sec number is useful so that the user has some chance of seeing a rare glitch or something, certainly.  But that some people believe that doesn't mean that such is what a high waveforms/sec number is good for.

No, the real reason a high waveforms/sec rate is desirable is that it is indicative of the speed of the acquisition and processing engine, and that is useful because you can then turn that capability towards having the scope automatically detect anomalies.

That is a wrong assumption. The only way to detect an anomaly with 100% certainty is by using the trigger system to look for it. Only the trigger system uses a sliding window over the signal (and thus no blind time). Any other method (high waveform update rates, mask testing) has blind time so the chance you capture an anomaly isn't 100%. Just look at the formulas used by R&S, Keysight, Tektronix, etc and you'll see you can proof that mathematically. I would not want to rely on chance to see if a product complies or not in an automatic test. If you don't test something 100% it won't work in the hands of the customer.

Also I really wouldn't want a product to be tested by just looking for anomalies. How long would you let the test run? IOW: you have to test with reproducable signals. So signal in (trigger from generator to scope) and mask test the outgoing signal is a much more likely use case for mask testing and this doesn't need high update rates because you'd have to record the result and switching to a different test point will take at least 1 millisecond.

Oh and my GDS-2204E doesn't have warranty void stickers.

[kcbrown]

Also don't get wound up about waveforms/s. It is a purely hypothetical number which can only be achieved at a specific time/div setting in dot mode. For starters nobody uses dot mode on a scope because it just doesn't draw a visible signal in many cases. Also the idea behind a high waveforms/s number is that you have a higher chance of seeing rare glitches. Unfortunaly many don't factor in that people blink their eyes and may want to take a coffee break.

Some people seem to believe that the high waveforms/sec number is useful so that the user has some chance of seeing a rare glitch or something, certainly.  But that some people believe that doesn't mean that such is what a high waveforms/sec number is good for.

No, the real reason a high waveforms/sec rate is desirable is that it is indicative of the speed of the acquisition and processing engine, and that is useful because you can then turn that capability towards having the scope automatically detect anomalies.

That is a wrong assumption. The only way to detect an anomaly with 100% certainty is by using the trigger system to look for it.

Sure, but all trigger systems are at least somewhat limited in their capability, and that means you might not be able to define a trigger to capture the anomaly.

If the pass/fail ("go/no go" for the Instek) mechanism is built into the triggering mechanism, then you might have a shot at always being able to define a trigger to capture an anomaly.  In the absence of that, however, you're left with the waveform update rate and the pass/fail mechanism's throughput (whichever is less) as the limiting factor in terms of how likely you are to be able to detect some arbitrary anomaly.

Only the trigger system uses a sliding window over the signal (and thus no blind time). Any other method (high waveform update rates, mask testing) has blind time so the chance you capture an anomaly isn't 100%. Just look at the formulas used by R&S, Keysight, Tektronix, etc and you'll see you can proof that mathematically. I would not want to rely on chance to see if a product complies or not in an automatic test. If you don't test something 100% it won't work in the hands of the customer.

I completely agree that the triggering system is what you should be using to detect the anomaly if you can.  But there's no guarantee that you can, right?

Also I really wouldn't want a product to be tested by just looking for anomalies. How long would you let the test run? IOW: you have to test with reproducable signals. So signal in (trigger from generator to scope) and mask test the outgoing signal is a much more likely use case for mask testing and this doesn't need high update rates because you'd have to record the result and switching to a different test point will take at least 1 millisecond.

I'm skeptical that product testing is the only use of a pass/fail system.  I expect you'd be able to use it for troubleshooting as well, no?

Regardless, we're talking about the probability of detecting an anomaly within some bounded period of time.  The waveform update rate and mask test throughput will surely affect that, because they will affect the blind time between waveform tests.  That's the sort of thing I'd expect the Instek to be very good at since it's such a fast scope in general.

I agree that the waveform update rate is a somewhat overblown metric -- there's so much more to a scope than just that.  But that doesn't mean it's irrelevant, either.

Oh and my GDS-2204E doesn't have warranty void stickers.

I'm pleasantly surprised.  Is the same true of their current production?  You did mention that you got an early one.

[nctnico]

I'm skeptical that product testing is the only use of a pass/fail system.  I expect you'd be able to use it for troubleshooting as well, no?

I never used masked testing for troubleshooting. It use a trigger condition to make 100% sure and/or infinite persistence to get a general idea. One purpose is to check whether interrupts are always handled in time and don't take too long while having a device do various tasks.

Regardless, we're talking about the probability of detecting an anomaly within some bounded period of time.  The waveform update rate and mask test throughput will surely affect that, because they will affect the blind time between waveform tests.

If there is a probability a product defect will be missed then the test isn't useable so just turning on mask testing for X time is not going to be acceptable as a test. Murphy's law is like the laws of physics: you cannot change it.

That's the sort of thing I'd expect the Instek to be very good at since it's such a fast scope in general.

I don't have the go/nogo testing option for my GDS-2204E but since it uses reference waveforms I guess it can do testing while comparing traces up to 1Mpts in length sample by sample. If it can do that it allows for testing signals with low and high frequency components with a very fine grained mask. It won't be fast but you can (for example) test several different output signals in one test cycle.

[kcbrown]

I'm skeptical that product testing is the only use of a pass/fail system.  I expect you'd be able to use it for troubleshooting as well, no?

I never used masked testing for troubleshooting. It use a trigger condition to make 100% sure and/or infinite persistence to get a general idea. One purpose is to check whether interrupts are always handled in time and don't take too long while having a device do various tasks.

Well, obviously the methods you use are going to be determined by what you're facing.

Infinite persistence is an excellent approach to visually determine whether or not there's a problem, but it's just as dependent upon the waveform update rate as anything else.  Correct me if I'm wrong, but isn't the waveform update rate a reflection of how quickly the scope is able to process the data it has on hand once the trigger fires?   Put another way, the trigger system itself operates on a continuous stream of data up until the trigger fires, but once that happens, the scope has to process the resulting data at that point and reset the trigger before moving on.  The waveform update rate is the rate at which the scope can process trigger events, no?   Isn't that why you can use the trigger out connector as a means of determining the waveform update rate?

Regardless, we're talking about the probability of detecting an anomaly within some bounded period of time.  The waveform update rate and mask test throughput will surely affect that, because they will affect the blind time between waveform tests.

If there is a probability a product defect will be missed then the test isn't useable so just turning on mask testing for X time is not going to be acceptable as a test. Murphy's law is like the laws of physics: you cannot change it.

Well, you certainly can't avoid Murphy's Law, I'll grant you that!   But much of quality control is statistical in nature already.  You can't guarantee 100% quality -- you can only approach it, and the thoroughness of your testing will determine how close you get.

Obviously one would prefer a non-statistical test, but such a test might not be available, depending on what you're looking for.

For instance, how would you use the triggering system to detect an unacceptable amount of phase noise in a signal (ignore for the moment that a scope is not the right instrument for that in the first place)?

That's the sort of thing I'd expect the Instek to be very good at since it's such a fast scope in general.

I don't have the go/nogo testing option for my GDS-2204E

I thought the option was freely available to anyone who purchases the unit, no?  I think it's a separate download, though.  You might find some uses for it in your own testing.  Or not.  Depends on what you're testing, and perhaps how creative you get.   

but since it uses reference waveforms I guess it can do testing while comparing traces up to 1Mpts in length sample by sample. If it can do that it allows for testing signals with low and high frequency components with a very fine grained mask. It won't be fast but you can (for example) test several different output signals in one test cycle.

For all I know, it might even be relatively fast.

[nctnico]

For instance, how would you use the triggering system to detect an unacceptable amount of phase noise in a signal (ignore for the moment that a scope is not the right instrument for that in the first place)?

Phase noise (jitter) is a frequency domain effect so it will result in periods which are too long AND too short. Assuming the phase noise/jitter limits you are testing against are worse than that of the DSO's sampling and trigger system the pulse width trigger should work just fine.

[kcbrown]

For instance, how would you use the triggering system to detect an unacceptable amount of phase noise in a signal (ignore for the moment that a scope is not the right instrument for that in the first place)?

Phase noise (jitter) is a frequency domain effect so it will result in periods which are too long AND too short. Assuming the phase noise/jitter limits you are testing against are worse than that of the DSO's sampling and trigger system the pulse width trigger should work just fine.

That's absolutely right, and I have no idea why that approach didn't occur to me.   

[kcbrown]

Earlier, I wrote:

The Instek's FFT function seems to be better than the Siglent's (or, indeed, anything else in the same price class from what I can tell) in at least a couple of ways.  The first is that the update rate is very fast -- it looks to me like it's around 10 times per second or so.  The second is that the display will actually show you X and Y axis values that you can use to determine at a glance what the FFT is showing (at least, if the user manual images are to be believed).  The FFT is Instek's big advertising point, but whether or not that really matters to you ultimately depends on what you're going to do with it.  That said, it seems to be indicative of the overall responsiveness of the scope as well.

If the 2000X series FFT is anything like that of the 1000X series, then I'm incorrect in the above as regards the Siglent's display of the FFT values.  This message from tautech shows the 1000X series FFT screen: https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg1069585/#msg1069585

The FFT screen shown in that message looks quite nice.

[nctnico]

It can look nice on a screendump but if the update rate is slow then using FFT becomes annoying because it doesn't follow what you are doing immediately (probing a test point or adjust something on a generator). Unlike any other scope I have (or owned before) I'm using the FFT function on my GW Instek quite often just to take a look at the frequency spectrum because the FFT is fast. Also long FFT means high frequency resolution showing frequencies as distinctive peaks you can aim a cursor at very precisely. Given the fact that the SDS2000X is driven by a low cost Analog Devices Blackfin series (I think I have a nearly 20 year old eval. kit from when this series was introduced somewhere) it must be clear it is no match for what the GDS2000E series can do when it comes to FFT. But don't take my word for it: https://www.eevblog.com/forum/testgear/gds-2072e-1mpoints-fft-gt-i'm-impressed/

[pascal_sweden]

Siglent users who like and trust Siglent gear, don't have to use a poor man's FFT-on-a-scope solution for looking at a frequency spectrum. They use the real thing, an affordable spectrum analyzer from Siglent! =)

[nctnico]

Good luck using a multi-GHz spectrum analyser on a 1kHz signal because they usually start at 9kHz. Also most spectrum analysers aren't very good at the low frequency range. And what if you need sub-Hertz resolution? For some measurements FFT on a scope really is the best solution.

[rf-loop]

If the 2000X series FFT is anything like that of the 1000X series, then I'm incorrect in the above as regards the Siglent's display of the FFT values.  This message from tautech shows the 1000X series FFT screen: https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg1069585/#msg1069585

The FFT screen shown in that message looks quite nice.

There is no any doubt that GoodWill 2000E FFT is far better than  Siglent SDS2000X or  SDS1000X FFT.
But, still I can use it for IF filter fast adjustment without any difficulties from update speed or any other thing.

These are SDS1102X  (SDS2000X is functionally same but it have bit more processing power.


(note freq counter. It is Trig counter and as can see triger is not continuous carrier (look trig level)
Carrier is < -10dBm 455kHz. Modulation 2.8kHz


Same 455kHz but full window and modulation 5kHz  Watching mod peaks is easy to tune filter. (even better if use dual or triple tone mod)

 

[kcbrown]

It can look nice on a screendump but if the update rate is slow then using FFT becomes annoying because it doesn't follow what you are doing immediately (probing a test point or adjust something on a generator). Unlike any other scope I have (or owned before) I'm using the FFT function on my GW Instek quite often just to take a look at the frequency spectrum because the FFT is fast. Also long FFT means high frequency resolution showing frequencies as distinctive peaks you can aim a cursor at very precisely. Given the fact that the SDS2000X is driven by a low cost Analog Devices Blackfin series (I think I have a nearly 20 year old eval. kit from when this series was introduced somewhere) it must be clear it is no match for what the GDS2000E series can do when it comes to FFT. But don't take my word for it: https://www.eevblog.com/forum/testgear/gds-2072e-1mpoints-fft-gt-i'm-impressed/

You'll get no argument from me on any of those points.  My purpose in writing what I did was to correct an error on my part with respect to the display of the scales on the FFT output.  What I'd previously seen suggested that the Siglent scopes didn't display the scale values, but if the SDS1000X FFT is indicative of what the SDS2000X series will show, then it means it will show the scales and, at least, you'll be able to easily see what the FFT is telling you.

I consider the FFT of the Instek line to be its showcase feature.

[pascal_sweden]

Good luck using a multi-GHz spectrum analyser on a 1kHz signal because they usually start at 9kHz. Also most spectrum analysers aren't very good at the low frequency range. And what if you need sub-Hertz resolution? For some measurements FFT on a scope really is the best solution.

Maybe a better alternative for those lower frequency measurements is the following device