EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: RBBVNL9 on January 06, 2022, 02:55:28 pm
-
Hello!
I recently made the first part of a video review (https://youtu.be/QyMbWtF67E0) of three popular oscilloscopes: the R&S RTB2000, Siglent SDS2000X Plus and Keysight InfiniiVision 1000 X Oscilloscopes.
The series will be an in-depth functional comparison of the devices. It may serve people that are considering purchasing one of them, but also help people to get to know their device better, quickly find functions and their description in the user manual, etc. Preparing overview, I (re)discovered many features myself.
In this location, I am also sharing the file with the functional comparison between the three devices. I plan to further update this file over time. Comments, corrections, additions etc. are welcome.
File: Functional comparison RTB SDS DSOX (https://github.com/RudisElectronicsLab/RTB_SDS_DSOX_review)
The ultimate aim here is that all of us can make the best possible use of our measurement instruments!
Future planned episodes include:
1. Physical devices
2. User interface
3. Acquisition systems, channels, horizontal system & trigger
4. Tools
5. Bus decode
6. Analysis
7. Signal generators
8. Memory, history, search
9. Computer access and atomization
10 System features
[attachimg=1]
https://youtu.be/QyMbWtF67E0
-
Respect for undertaking such an effort!
Looking forward to seeing the whole series.
Just a quick note for v28:
pg 7. SDS2000X+ 10Bit mode is 100Mhz not 10MHz.
pg 9. SDS2000x+ math: it is not obvious that it has freeform math where you can write freeform formula for math channel. Also there is a track, but not as a math channel but as a tool connected with measurements..
pg 10. 10Bit mode is missing from list acquisition modes. it is a separate setting "resolution 8/10 bit" but really it is a sort of Hires acquisition mode.
pg. 18. Mask failure operations: Stop on fail, Failure to history , Capture on fail, Beep. Note that those are not mutually exclusive operations, i.e. you can combine them.
Pg 18. Bode plot (FRA) it supports Vari-level and automatic gain.. You can have 4 Vari-level profiles (curves) predefined and saved. I don't recall if there is any preset point limit on curve complexity.
Pg 21. Siglent and Keysight memory is mixed. It is Keysight that has puny 4 Mpts of memory. Siglent has 100Mpts (full channel config) 200MPts (half channel)
Pg 23. It is not Web storage, but a network share (windows SMB) disk mounting /mapping. It is fully supported for any save/recall operations
All in all great work..
Best,
Sinisa
-
@2N3055/Sinisa,
Thanks for the corrections and additions! Have processed them and a new version will follow soon. PS.: The Mask and Bode sections are largely still to be written (like some other parts).
Looking forward to seeing the whole series.
Will probably post a new episode tomorrow.
-
This looks to be very interesting indeed, and I'm very much looking forward to seeing the videos you intend to produce.
A note about segmented memory in the Siglent: it's always on and available. Whenever the amount of memory taken by a single capture frame is less than half of the available memory, you'll get at least 2 segments available to you. The control you have over memory usage defines the maximum memory size of a captured frame. The rest of memory will automatically be used for storage of additional segments, up to 90,000 total. Some memory is needed for metadata about each frame, so the total number of segments you'll be able to capture is the total memory size in points divided by the capture size, minus some number. With a capture size of 20M and a total number of points of 200M, you'll get 9 segments. Similarly, with a capture size of 2M, you'll get 99 segments. That will start to diminish somewhat past that, so, for instance, with a capture size of 200K, you get 994 segments. In any case, the maximum number of segments scales roughly with the maximum number of points (100M or 200M for analog channels, depending on which channels you have active, and 50M for digital channels) divided by the capture size.
Note, too, that the capture size isn't guaranteed to be what you set it to in the acquisition settings. That defines the maximum capture size. The actual capture size can be less than that. The scope will limit its capture to the amount of time represented by the screen, and since the maximum sample rate of the scope is 2GS/s, a small enough timebase will result in fewer points captured than the maximum capture size would otherwise allow. When this happens, the scope will make more segments available to you.
The actual number of segments captured will, of course, depend on how many trigger events were captured between when you started the acquisition and when you stopped it. The scope keeps the most recent captures, up to the maximum number of segments allowed by the memory and the actual capture size.
Because the segment system is always in use, sequence mode is not necessary for segment use. The history function is always available, irrespective of whether or not you performed your capture using sequence mode. The only purpose of sequence mode is to minimize the overhead that might otherwise reduce the waveform update rate.
-
Add Keyboard, mouse, touch screen
-
Add Keyboard, mouse, touch screen
It is there..
pg.3 USB Host : FMKP
-
I just posted a new episode, about the physical design, the I/O connectivity, and the documentation of the three oscilloscopes.
Also updated the comparison document (https://github.com/RudisElectronicsLab/RTB_SDS_DSOX_review)(now V31) in quite a few points, including the feedback I received.
Further comments are welcome!
new episode (https://www.youtube.com/watch?v=b-TuDm92cn4)
Add Keyboard, mouse, touch screen
I now did some more experiments. While the RTB and DSOX have only one USB host connector, they work well with hubs, allowing to connect a keyboard and flash memory (and mouse, if applicable) at the same time. The SDS already has two USB connectors but for whatever reason, mine fails to work well with a hub.
include noise floor comparison if you can
That would be interesting for sure! But I think that for now, I want to focus on a functional comparison - it's already a lot of work. Performance comparisons are challenging to carry out well, and I'd be happy if others can pick that up.
-
The SDS already has two USB connectors but for whatever reason, mine fails to work well with a hub.
Interesting. Have you tried all three USB ports?
BTW, thanks for doing this :-+
-
The SDS already has two USB connectors but for whatever reason, mine fails to work well with a hub.
Interesting. Have you tried all three USB ports?
The rear USB-B is for USB device communication only.
Could be just RBBVNL9's hub, IDK. :-// We need some more feedback if other SDS2kX+ owners are having problems with hubs.
-
Hello Rudi!
As I said, very thorough and detailed work.
You asked for comments ^-^ ...
Firmware update frequency :
10 updates in 56 months is 5,6 months between updates
6 updates in 22 months is 3,66 months between updates
8 updates in 56 months is 5,6 months between updates
That makes it that Siglent has almost twice the update frequency, not same as others.
Not that frequency it is very important. Quality of updates, amount of bugs resolved and new features added would be more important. But that would be hard to measure and quantify.
All in all RB2000 and SDS2000X+ had significant quality improvements (RTB2000 came out very unfinished and buggy), and had added functions that they didn't have initially (where SDS2000X+ had some nice features, new protocols added more than others). Keysight OTOH is much simpler platform and has much less features, releases were mostly bug fixes and paid features unlocks. In my opinion, all 3 of them has shown manufacturers dedication to giving good product to customer.
Channel lights comment:
RTB and Keysight light up all the channel buttons for channels that are on. SDS doesn't. It lights up button only for a channel you're editing (or math or ref).
But all of them already show ON screen which channels are ON/OFF. So that information is readily available on the screen. Showing that also on the buttons is redundant.
But when you want to know which channel you're editing, on RTB2000 that is not obvious from the screen, and is signified by only color coding of rings around rotary dials, and slightly brighter font display for that channel.
On Siglent you can see directly on the button which one you're editing. 1 or 2 or 3...
I find that much clearer and obvious, not to mention that it works for people with color vision problems....
With single knob for all channels most important info is what are you currently editing (what is currently selected channel for editing). What channels are active is clearly and quite obviously visible on the screen.
On this I disagree with you: Siglent choice is more ergonomic despite not being what you expect.
This buttons behavior is probably remnant (old habits die hard) from previous scopes that had individual buttons and all you wanted to know is which channels are active.
I have it on MSOX3000T and it makes sense there, with individual channel buttons.
But even on on that scope, those elements that don't have individual buttons but share two dials(FFT, MATH, REF, DIGITAL) work exactly like Siglent: LED is lit only for the one you're editing, not for all the one that are enabled.
Since Siglent shares same set of knobs for all channels and other functions (channels, math, ref etc.) it does it like that for all of them. It is actually logical.
Again, admire the work you're putting in, very well done. I think it will be of great service to community..
Best,
Sinisa
-
One thing that bugged me was the statement that the SDS2000X had probe sense for 1x/10x. What about 20X and 100X? So I checked, and it doesn't do those. :( After all the trouble of adding the actual probe sense pads and circuitry, it seems silly to leave the implementation incomplete. Perhaps that can be fixed in firmware? It's open for 1X, 10k for 10x, 5K for 100X and 1.5k for 20X.
I can confirm that the Siglent is a bit of a power hog, 50-60W running and 4.2W when off. A hard power off switch would be good.
-
The SDS already has two USB connectors but for whatever reason, mine fails to work well with a hub.
Interesting. Have you tried all three USB ports?
The rear USB-B is for USB device communication only.
Could be just RBBVNL9's hub, IDK. :-// We need some more feedback if other SDS2kX+ owners are having problems with hubs.
No problems with hubs with either SDS2kX+, using cheap Yuanxin types from Adafruit. Can use wireless mouse/keyboard dongle, various USB thumb drives and such.
Best,
-
One thing that bugged me was the statement that the SDS2000X had probe sense for 1x/10x. What about 20X and 100X ? So I checked, and it doesn't do those. :(
What is the pin to BNC outer resistance ? This 100x probe measures 6.2k and autosenses just fine.
Don't have a SDS2kX+ unboxed so checked on my SDS5kX demo.
-
What is the pin to BNC outer resistance ? This 100x probe measures 6.2k and autosenses just fine.
Don't have a SDS2kX+ unboxed so checked on my SDS5kX demo.
I have a Tek P6156 with switchable 1x/10x/20x/100x. The resistances for each are open, ~10k, ~1.5k and ~5k. These all indicate correctly on my Tek scopes except for 20x, which was only supported on the 11000-series sampling scopes. I also have a Probemaster 100X w/ readout and it measures 6.9k. Again, both Tek scopes recognize it as 100x. The SDS2000X+ switches to 10X if any probe I have with a readout pin is attached, and I checked all 4 channels. From what I've read the nominal values are 10x--11k, 100x--6k, 1000x--??. My 2465B actually recognizes the 20x one as 1000x, so I assume that the 1.5k is in the ballpark for that. The 2221A probably doesn't know about 1000x probes.
-
What is the pin to BNC outer resistance ? This 100x probe measures 6.2k and autosenses just fine.
Don't have a SDS2kX+ unboxed so checked on my SDS5kX demo.
I have a Tek P6156 with switchable 1x/10x/20x/100x.
Seems entirely the wrong probe to use with a SDS2kX+.
https://w140.com/tekwiki/wiki/P6156
It is designed for use with wide band oscilloscope amplifiers with 50 Ω inputs
-
Seems entirely the wrong probe to use with a SDS2kX+.
https://w140.com/tekwiki/wiki/P6156
It is designed for use with wide band oscilloscope amplifiers with 50 Ω inputs
The SDS2xxxX+ isn't all that? What part is it not? At 500MHz the P6156 10x will have a higher impedance than any 10M 10x probe like the SP3050A. Of course it is resistive, not reactive, but that's another matter.
In any case, that shouldn't affect the operation of the readout pin, which is what I was testing. And my other probe that I tried is for a standard 1M input.
-
Seems entirely the wrong probe to use with a SDS2kX+.
https://w140.com/tekwiki/wiki/P6156
It is designed for use with wide band oscilloscope amplifiers with 50 Ω inputs
The SDS2xxxX+ isn't all that? What part is it not? At 500MHz the P6156 10x will have a higher impedance than any 10M 10x probe like the SP3050A. Of course it is resistive, not reactive, but that's another matter.
In any case, that shouldn't affect the operation of the readout pin, which is what I was testing. And my other probe that I tried is for a standard 1M input.
A post or 2 back you answered your own question:
What is the pin to BNC outer resistance ? This 100x probe measures 6.2k and autosenses just fine.
Don't have a SDS2kX+ unboxed so checked on my SDS5kX demo.
I have a Tek P6156 with switchable 1x/10x/20x/100x. The resistances for each are open, ~10k, ~1.5k and ~5k. These all indicate correctly on my Tek scopes except for 20x, which was only supported on the 11000-series sampling scopes. I also have a Probemaster 100X w/ readout and it measures 6.9k. Again, both Tek scopes recognize it as 100x. The SDS2000X+ switches to 10X if any probe I have with a readout pin is attached, and I checked all 4 channels. From what I've read the nominal values are 10x--11k, 100x--6k, 1000x--??. My 2465B actually recognizes the 20x one as 1000x, so I assume that the 1.5k is in the ballpark for that. The 2221A probably doesn't know about 1000x probes.
Earlier I posted this ~6.2k sense pin resistance for 100x probe for SDS5kX and in previous checks with SDS2kX+ also sensed fine with the same 100x stock probes we have.
I suggest you get a 10k pot out and find the 100x sense pin thresholds for your 2kX+ as it appears they don't match Tek but is that any surprise ?
Since forever there has been no hard and fast standard for sense pin resistances.
FYI this is how the same probe autosenses in 50 Ohm mode.
-
Hi,
loads of effort :-+
Regarding the UI Layout... I don´t share Your opinion about a unlogic Layout of the SDS -where I truely miss that You don´t show examples, but just talk talk talk. :=\
For example Meas and Cursor buttons are close to the universal rotary knob .... just where they should be.
The same applies to the Setup Run/Stop, Default buttons which I would expect in proximity of the trigger settings ... just where they are.
Others mentioned already the quite sensible logic behind the illumination of the channel buttons.
The only buttons which may seem be a bit off at first glance are the Navigate row-of-4. But then ... where better to put them?
I find the R&S layout not at all more intuitive ... let alone the Keysight, where you can´t even see the buttons due to the stupid black casing colour. :palm:
In the end its probabely just a matter of personal history and preference which UI one prefers.
I have lots of good experiences with Siglent -no lost foot at all on any of the 6 devices I work with and no terribly loud fan on either) and rather negative experiences with R&S (RTH handheld Osci) their service and their ridicolous accessories prices.
And I´m certainly p***** off by Keysights new ´we-sell-you-but-don´t-wanna-serve-after´ policy.
So I´m a bit biased in the opposite direction from Yours.
In the comparison table I miss the EasyWave software listed under the section Windows Apps.
Apart from that ... keep up the evaluation work :-+ :clap:
regards
Calvin
-
Hi,
loads of effort :-+
Regarding the UI Layout... I don´t share Your opinion about a unlogic Layout of the SDS -where I truely miss that You don´t show examples, but just talk talk talk. :=\
For example Meas and Cursor buttons are close to the universal rotary knob .... just where they should be.
The same applies to the Setup Run/Stop, Default buttons which I would expect in proximity of the trigger settings ... just where they are.
Others mentioned already the quite sensible logic behind the illumination of the channel buttons.
The only buttons which may seem be a bit off at first glance are the Navigate row-of-4. But then ... where better to put them?
I find the R&S layout not at all more intuitive ... let alone the Keysight, where you can´t even see the buttons due to the stupid black casing colour. :palm:
In the end its probabely just a matter of personal history and preference which UI one prefers.
I have lots of good experiences with Siglent -no lost foot at all on any of the 6 devices I work with and no terribly loud fan on either) and rather negative experiences with R&S (RTH handheld Osci) their service and their ridicolous accessories prices.
And I´m certainly p***** off by Keysights new ´we-sell-you-but-don´t-wanna-serve-after´ policy.
So I´m a bit biased in the opposite direction from Yours.
In the comparison table I miss the EasyWave software listed under the section Windows Apps.
Apart from that ... keep up the evaluation work :-+ :clap:
regards
Calvin
Yes.....
Not recognizing why Siglent have laid out the channel button indicators how they have seems like the user has recently migrated to a DSO after years of experience with only CRO's.
Channel tabs on the display indicate which channels are active and the channel LED indicates which one is active to the controls.....so simple....you don't even have to take your eyes away from the display if you need to know which is the active channel if you have a trace overlap as the control active trace is always on top.
We first saw this layout with the SDS1104X-E and it remains consistent throughout all Siglent's multiplexed control DSO's.
-
Dear all, thanks for the various replies and feedback, appreciate it. Let me start with the hub comments.
I wrote "The SDS already has two USB connectors but for whatever reason, mine fails to work well with a hub." Of course, this is N=1, and it may be due to my specific case.
So, the hub I tried is an Anker type A7516, a fairly straightforward, recent 4 port hub. When connected to a USB host connector on the front panel of the SDS, it failed to work with a fairly standard PC keyboard (an HP H3C52AA). That same keyboard does work directly on the SDS, and the combination of the said hub and keyboard do work on the RTB and the SDOX. Actually, with the DSOX, four keyboards worked at the same time!
I also noted that when the keyboard failed to work, the LEDs on the keyboard do not turn on (they do turn on when connected directly to the SDS, or connected to RTB or DSOX via the hub). That suggests a power issue. Perhaps the RTB and SDOX supply more power to the hub than the SDS, allowing them to use 'heavier' accessories.
So I tried to find some other keyboards I could try around the house. What I found is:
- An 'original' Raspberry Pi keyboard (the funky red and white one). And... that one works with my hub on the SDS!
- A Logitech wireless K270 keyboard with its supplied proprietary (not 'unity') Logitech dongle. That one also works with my hub on the SDS.
- An HP keyboard that came with an old all-in-one PC, type KBAH21. Does not work with my hub on the SDS
- An Apple full-size keyboard type A1243. Does not work with my hub on the SDS
So, my tentative conclusions are that (1) the use of SDS with hub may depend on the specific model of hub and/or used USB devices, (2) higher-powered accessories may cause problems on the SDS when connected via hubs and (3) the RTB and DSOX seem less sensitive to the type of keyboards connected via hubs.
Of course, I could try to find other hubs and test them too, but the number of permutations would get high and I would rather reply to some other comments today as well ;-)
On a final note: the RTB and DSOX provide clear feedback when USB devices are not recognized/allowed, or when you use flash drives with 'exotic' formatting (see screenshots). As far as I know, the SDS does not provide explicit error messages, it remains silent.
-
Concerning the probe sensing… It’s an area where the SDS certainly has a plus over the RTB and DSOX (as I mention in the video).
In my video and document, I just relied on the User Manual of the SDS, and an old 10x Tek P6105A 10x probe I happened to have in the lab (and which is correctly identified as a 10x probe by the SDS).
I now tried a couple of resistor values. As far as I can see, the SDS interprets any resistance between 0Ω and 56kΩ as “10x”, and resistance between 82k to infinity as “1x”. So, it seems that there is no recognition for other attenuation values, as it is.
No idea whether the hardware allows other detections (via a firmware upgrade) or not.
-
IMHO probe sensing is pretty much useless if you can't configure it for vendor specific probes. As soon as you connect a probe with vendor specific probe sensing (like 20x for example), it only gets in the way because the scope still thinks a 10x probe is connected. The R&S RTM3004 has several, easely accessible presets for the probe attenuation factor; I assume the RTB2004 is the same.
-
The R&S RTM3004 has several, easely accessible presets for the probe attenuation factor; I assume the RTB2004 is the same.
Looking at the RTM300 manual, the RTB2000 has the same general probe settings: 4 general presents (1:1, 1:10, 1:100 and 1:1000) a user setting (fully variable between 100μ to 10M (equals 10-4 ~ 107) (since FW02.300), and a V/A setting (where the attenuation units change to current).
Of course, the RTB does not have the more advanced probe options the RTM has, like support for probes with integrated data memory for ID (serial number, production data, electrical characteristics) and memory for individual probe correction, access to additional metering electronics in the probe itself ('ProbeMeter'), and the configurable button on the probe head ('microbutton'), degaussing for current probes, and so on. All of these goodies require the R&S probe interface (recognisable by the six round electric contacts next to the BNC), which you find on the RTM3000, the RTA4000, and 'above'.
-
Hi Rudi,
thanks for putting this series together, I really appreciate your work. Getting through all those detailed infos must be very time consuming. This is a really valuable contribution.
I only own the 2104x+ and actually find the overall button layout quite intuitive. Almost all sub menu items are "buttonized". However, in the beginning I had my issues with the five so called "Menu" buttons from which only three are actually corresponding to a real "Menu..." entry (which should rather be renamed into "Settings" or "Setup" to be aligned with the Trigger "Setup" button).
Why didn't they order the three top level "Menu..." buttons in the order of their appearance on the screen (Utility, Display, Aquire). I understand that they want to indicate AWG on/off state with an illuminated button but I really wished they made the "save/recall" button user assignable. And what's better than one user definable button? Right: two ;)
In regards to the online documentation:
I know that developing and maintaining a good and well integrated documentation is as much a challenging and expensive task as writing good software. If Siglent chose to cut corners here, we might have to accept that. In the end we buy this thing for its very good price/performance ratio.
But Siglent could really improve on their online docs and make use of the touch screen by heavily hyperlinking the content. Why can't I jump from chapter 9 into the dedicated sections and back. And why do I actually have to go to chapter 9 and navigate from there? Even my car's online help allows me to touch a virtual dashboard bringing me to the corresponding content. I also miss a free search and a cross reference (index/glossary).
I think, rendering HTML from a Word file just doesn't cut it anymore these days as there are better options available especially when this device has a builtin http server...
BTW: Did you notice that there is no chapter 20 and that the 'Developer Options' are still called 'Debug' in the online docs;) (FW 1.3.9R6)
Again thanks for putting this series up and for giving it such a clear and in depth structure. Let's hope your family grants you the time to produce all planed episodes;) That's going to become epic.
Could it be that the white balance in your camera is a little on the warm side?
Joachim
-
@Joachim (and others),
Thanks for the reactions and the various compliments.
Could it be that the white balance in your camera is a little on the warm side?
Ah yes, that is a good point ;-) I shot with a Nikon Z7 plus Atamos Ninja V and edited in Final Cut Pro, and normally speaking, that should leave one with quite some room for colour grading afterwards. But surprisingly, both colour temperature settings and colour grading wheels result in quite ugly results :-[ So, for the time being, I left it kinda reddish/warm.
There are a couple of possible solutions: (1) get the paid upgrade of the Z7 to get RAW output (have to send it in to the Nikon distributor for that) and get the Ninja upgraded dor ProRes RAW. Should give me much more leeway for colour grading. Takes time and money. (2) Get studio lights so I am less dependent on natural / room light. Probably the better option. Already bought those but my son confiscated them and and took them to his house ;-)
At some point in time, I will try to improve the video (colour) but now I will first give priority to the videos themselves ;-)
-
I suggest you get a 10k pot out and find the 100x sense pin thresholds for your 2kX+ as it appears they don't match Tek but is that any surprise ?
Since forever there has been no hard and fast standard for sense pin resistances.
I tried it with two probes, one ~5k and one ~6.9k, so I've sort of bracketed the nominal 6k spec, if that's correct. I assume any reasonable setup would allow for some variance. So I'm sort of suspecting that the SDS2kX+ is an all-or-nothing 1x/10x only setup. I'll try the potentiometer if I get a chance. b/t/w, having faulty or poorly implemented probe sensing is worse than none at all as it appears you can't override it. I'll have to come up with some insulating washers.
FYI this is how the same probe autosenses in 50 Ohm mode.
I don't think input impedance should matter to probe sensing?
-
What is the pin to BNC outer resistance ? This 100x probe measures 6.2k and autosenses just fine.
Don't have a SDS2kX+ unboxed so checked on my SDS5kX demo.
I have a Tek P6156 with switchable 1x/10x/20x/100x.
Seems entirely the wrong probe to use with a SDS2kX+.
https://w140.com/tekwiki/wiki/P6156
It is designed for use with wide band oscilloscope amplifiers with 50 Ω inputs
Not at all. The information on that page is simply wrong. The Tektronix P6156 is a general purpose Low-Z (passive) probe which is supported on many Tektronixs DSOs including the TDS500/600/700 series. I have a couple of these as well but it sucks to have the autosense pin isolated because non-Tektronix scopes interpret the resistance wrong.
-
Concerning having (button) LEDs on for all active channels (vs. selected channels): I realize from the comments this is a bit of a user preference aspect and also may depend on the devices you come from, respectively the other devices you use.
2N3055 makes an important point that we should not forget about people with visual impairment. They may indeed prefer to have button lights illuminating on selected channels only. I must note, however, that the RTB and DSOX both can show the text “Channel 3” written on the screen when channel 3 is edited, and both also show it with trace markers (left of the trace). The RTB furthermore shows it with a highlight at the bottom of the screen. So, there are multiple clues for the (colour) visually impaired onj these devices.
Not recognizing why Siglent have laid out the channel button indicators how they have seems like the user has recently migrated to a DSO after years of experience with only CRO's.
I don’t think that is a fair point, tautech: having lights on the front panel illuminated for all active channels does not seem to be uncommon for modern DSOs at all. Unless I am mistaken, this is the implementation on various models of Teledyne LeCroy (WavePro HD, WaveRunner 8000HD, HDO6000B, WaveSurfer 4000HD), Tektronix models (3 series, 4 series, 5 series), R&S (RTM3000, RTA4000, RTE1000, RTO2000 and RTP RTP), and Keysight (2000X, 3000X, 4000X), to name a few. Most of these examples have shared vertical controls.
Looking at various manufacturers, I even asked myself whether any brand other than Siglent on recent models made the choice to illuminate the buttons for selected channels only. But I am sure others can fill in the gap and show who did, and who did not.
In any case, it’s a matter of user preference; will change this in the document.
-
Concerning having (button) LEDs on for all active channels (vs. selected channels): I realize from the comments this is a bit of a user preference aspect and also may depend on the devices you come from, respectively the other devices you use.
2N3055 makes an important point that we should not forget about people with visual impairment. They may indeed prefer to have button lights illuminating on selected channels only. I must note, however, that the RTB and DSOX both can show the text “Channel 3” written on the screen when channel 3 is edited, and both also show it with trace markers (left of the trace). The RTB furthermore shows it with a highlight at the bottom of the screen. So, there are multiple clues for the (colour) visually impaired onj these devices.
Not recognizing why Siglent have laid out the channel button indicators how they have seems like the user has recently migrated to a DSO after years of experience with only CRO's.
I don’t think that is a fair point, tautech: having lights on the front panel illuminated for all active channels does not seem to be uncommon for modern DSOs at all. Unless I am mistaken, this is the implementation on various models of Teledyne LeCroy (WavePro HD, WaveRunner 8000HD, HDO6000B, WaveSurfer 4000HD), Tektronix models (3 series, 4 series, 5 series), R&S (RTM3000, RTA4000, RTE1000, RTO2000 and RTP RTP), and Keysight (2000X, 3000X, 4000X), to name a few. Most of these examples have shared vertical controls.
Looking at various manufacturers, I even asked myself whether any brand other than Siglent on recent models made the choice to illuminate the buttons for selected channels only. But I am sure others can fill in the gap and show who did, and who did not.
In any case, it’s a matter of user preference; will change this in the document.
Some scopes might have it like this but it is wrong and is remnant of old, and makes sense only for scopes that have individual controls for each channel.
Like I said my MSOX3000T does that, BUT for MATH, FFT, Digital and REF uses same logic as Siglent because those functions share same two controls.
Lecroys absolutely work same as Siglent, i.e. buttons light up only for currently selected channel. Entry level LeCroys are made by Siglent and have to have similar U/I logic..
EDIT: it seems I'm wrong and that current LeCroy models do light up buttons for enabled channels. I disagree with that choice either.
Tek and R&S do this but I don't understand why. Highlights are not that obvious. My eyesight is not what it used to be and I can clearly see if that 2x2 cm square on the screen is there or not on Siglent. On R&S it difference ifs font background is a bit more highlighted. I have to look for that.
It is not something useful and it is not color disability friendly. Hard fail in my eyes.
-
Hi,
Very interesting comparison, but...
The Rigol MSO5000 is hardly missed in there.
Yes, the question should I buy a SDS2k+ or RTB came several times up - But also should I buy a MSO5000 or SDS2k+.
And very rare or no times a DSOX1000 or RTB/SDS2K+/MSO50000.
-
At some point in time, I will try to improve the video (colour) but now I will first give priority to the videos themselves ;-)
The problem is that the lighting you're using is warm-ish, but the color temperature of the screen backlights is closer to daylight. This means that you can't get both of them right at the same time. If you set the white balance to match your lighting, then the screens will have a blueish tint to them.
The white balance you're currently using looks like a reasonably close match to the color temperature of the screen backlights, so the screens themselves look reasonably accurate.
For those parts of the video where the scopes are turned off, it may be reasonable to set the white balance to match your lights. But for those parts where you intend to demonstrate something on the screens of the scopes, your white balance needs to roughly match the scope backlights (i.e., be reasonably close to daylight).
You're going to have to change the lighting itself if you want the color temperature of the environment to be a reasonable match to the color temperature of the screens.
-
Concerning the probe sensing… It’s an area where the SDS certainly has a plus over the RTB and DSOX (as I mention in the video).
In my video and document, I just relied on the User Manual of the SDS, and an old 10x Tek P6105A 10x probe I happened to have in the lab (and which is correctly identified as a 10x probe by the SDS).
I now tried a couple of resistor values. As far as I can see, the SDS interprets any resistance between 0Ω and 56kΩ as “10x”, and resistance between 82k to infinity as “1x”. So, it seems that there is no recognition for other attenuation values, as it is.
Correct, I now have an SDS2104X+ out and these have a 100x probe detection bug whereas SDS5000X detect 100x probes correctly.
Will report it with a high priority fix request.
-
Correct, I now have an SDS2104X+ out and these have a 100x probe detection bug whereas SDS5000X detect 100x probes correctly.
Will report it with a high priority fix request.
If they can't fix it because the hardware is simply 0/1, then they should provide an option to disable probe sensing altogether. I could live with that, but having it override my input when I connect a 100X probe with a readout pin is pretty annoying.
-
bdunham7 wrote:
I can confirm that the Siglent is a bit of a power hog, 50-60W running and 4.2W when off. A hard power off switch would be good.
Yes, that is also what I measure. Some 4 watt is quite a bit (and from this standby, the device does not boot any faster than with a cold start). The RTB consumes 0.5 watts on standby.
Bit off-topic, but I love the way the power-save mode is implemented in my new Jura coffee machine. It was advertised as consuming 0 watts. I was curious, measured it, and… it’s true. I suppose it really disconnects itself from AC altogether after a timeout, and that the button to turn it back on actually restores the AC circuit temporary, until a relay takes over (although other implementations are possible as well). Anyway, well done!
-
The problem I am seeing here is that there are numerous persons commenting on the Siglent but the other scopes are not being mentioned. So if you have missed details on the Siglent then how can one be sure that details on the other scopes are not being mentioned. So I am afraid your video may be skewed in one direction and not give a fair comparison.
-
It would be great if there were timestamps on the video. It shouldn't be too complicated and definitely very handy in case someone would like to go back and forth on the whole video series. :)
-
The Rigol MSO5000 is hardly missed in there.
The honest answer is: I don’t own an MSO5000. If I had one, I would certainly be happy to include it. But I want to base my comparison on first-hand observations... If someone owns both the SDS2k+ and MSO5000, do compare, and be my guest to use the structure of the document (https://github.com/RudisElectronicsLab/RTB_SDS_DSOX_review) prepared for this comparison.
(And there are a couple of other scopes I’d love to lay my hand on, too ;-)
About including the Keysight DSOX: I thought it would be worth including this one because Keysight, with this oscilloscope, competes squarely with the R&S RTB oscilloscope in the educational market. While the DSOX1204G was only introduced in March 2019, it has a design/UI concept without a touch screen, and I thought it would be interesting to see how that compares. Is the touch screen design/UI concept overvalued, do other things matter more? Or is it really a no-go to buy a non-touchscreen device today? (Note that also the current Keysight InfiniiVision 2000 X-Series has no touch screen…)
I also recall EVVBlog’s Dave even recently writing that the DSOX is his go-to scope in the lab. Made me curious too, what qualities make him turn to this instrument, while he (arguable) has choices in his lab?
Finally, I found that the DSOX has some nice tricks up its sleeves too that the other scopes I reviewed could learn from. Some examples: (1) when a channel is set to AC coupling, it disables the DC mode of the DVM. The RTB, for instance, does not do this and hence present wrong measurement results. (2) It can do XY imaging with blanking coming in on a “Z” channel. (3) It can link the trigger system to modulation of the internal AWG, thus exploiting the fact the AWG is built into the same device. (4) When in web access mode, the device itself (!) delivers an extensive HTML guide of SCPI commands to the connected computer. Do such points alone make it a more attractive scope than others? I don’t think so. But we do learn from it.
-
Hello,
i think there is a mistake in the document regarding the vertical scale / sensitivity for the Siglent. At least my Siglent has a range from 500µV/div to 10V/div and it is the 100MHz version as received from the dealer without any hacks. So the full range is not only available if the 500MHz option is enabled.
This is also a major drawback of the R&S in my opinion. If you work with european mains voltage you need additional x100 probes because with x10 probes the RTB can "only" show 500Vpp. This might not be a big deal for most people i guess. But another drawback in that case is the more or less unusable FFT if you want to check harmonics of 50Hz mains voltage. At least until the last update. Might have changed now but i can't ckeck since i don't have the RTB anymore.
-
Thanks, Domitronic.
i think there is a mistake in the document regarding the vertical scale / sensitivity for the Siglent. At least my Siglent has a range from 500µV/div to 10V/div and it is the 100MHz version as received from the dealer without any hacks. So the full range is not only available if the 500MHz option is enabled.
You are right. On the SDS, the horizontal scale changes with the 500MHz option, but not the vertical scale. Have updated the document (will publish along with a list of other additions shortly).
This is also a major drawback of the R&S in my opinion. If you work with european mains voltage you need additional x100 probes because with x10 probes the RTB can "only" show 500Vpp. This might not be a big deal for most people i guess. But another drawback in that case is the more or less unusable FFT if you want to check harmonics of 50Hz mains voltage. At least until the last update. Might have changed now but i can't ckeck since i don't have the RTB anymore.
Indeed, the Siglent goes to 10V/div (thus 100V/div with a x10 probe) and the RTB only to 5V/div (thus 50V/div with a 10x probe). However, tho things to take into account:
1. The RTB has 12 vertical divisions (compared to 10 on the SDS), so can show 12 * 50 = 600V with 10x probes
2. For mains measurements, I myself prefer to use high voltage differential probes, instead of having to measure between live and the earth point. You can then choose a model with CAT safety ratings corresponding to your tasks These days, there is a fair offer of affordable HV differential probes with x50 and x100 attenuation.
Anyway, thanks for the feedback and keep on commenting!
-
Indeed, the Siglent goes to 10V/div (thus 100V/div with a x10 probe) and the RTB only to 5V/div (thus 50V/div with a 10x probe). However, tho things to take into account:
1. The RTB has 12 vertical divisions (compared to 10 on the SDS), so can show 12 * 50 = 600V with 10x probes
The RTB has 10 divisions while Siglent has 8 as far as i know. So its 500V with the 10x probes on RTB. And of course it is better to use differential HV probes with main voltages. Less risk to blow anything up compared to standard probes. Thats clear.
-
The RTB has 10 divisions while Siglent has 8 as far as i know.
Ah yes, you are right in that.
RTB2000: 12 horizontal, 10 vertical divisions
SDS2000X+: 10 horizontal, 8 vertical divisions
Had that correct in the overview document but misquoted myself :-[
-
The Rigol MSO5000 is hardly missed in there.
The honest answer is: I don’t own an MSO5000. If I had one, I would certainly be happy to include it. But I want to base my comparison on first-hand observations... If someone owns both the SDS2k+ and MSO5000, do compare, and be my guest to use the structure of the document (https://github.com/RudisElectronicsLab/RTB_SDS_DSOX_review) prepared for this comparison.
(And there are a couple of other scopes I’d love to lay my hand on, too ;-)
About including the Keysight DSOX: I thought it would be worth including this one because Keysight, with this oscilloscope, competes squarely with the R&S RTB oscilloscope in the educational market. While the DSOX1204G was only introduced in March 2019, it has a design/UI concept without a touch screen, and I thought it would be interesting to see how that compares. Is the touch screen design/UI concept overvalued, do other things matter more? Or is it really a no-go to buy a non-touchscreen device today? (Note that also the current Keysight InfiniiVision 2000 X-Series has no touch screen…)
I also recall EVVBlog’s Dave even recently writing that the DSOX is his go-to scope in the lab. Made me curious too, what qualities make him turn to this instrument, while he (arguable) has choices in his lab?
Finally, I found that the DSOX has some nice tricks up its sleeves too that the other scopes I reviewed could learn from. Some examples: (1) when a channel is set to AC coupling, it disables the DC mode of the DVM. The RTB, for instance, does not do this and hence present wrong measurement results. (2) It can do XY imaging with blanking coming in on a “Z” channel. (3) It can link the trigger system to modulation of the internal AWG, thus exploiting the fact the AWG is built into the same device. (4) When in web access mode, the device itself (!) delivers an extensive HTML guide of SCPI commands to the connected computer. Do such points alone make it a more attractive scope than others? I don’t think so. But we do learn from it.
There are many people that use digital scopes old way, like a CRT scope with memory and measurements and storage.
They twiddle buttons until what's on screen looks familiar. They don't think about digital scope as an dedicated analytic computer with a signal acquisition front end. They want for scope to emulate CRT scope, as much as possible. That is the way they think, the way they know how to use it, the familiar way.
They are the ones that love Keysight InfiniiVision scopes. They are good scopes for service, for instance, where you need to simply check if there is signal, that signal roughly looks like it should and have basic tools for that.
In a perfect world, one would have an advanced analytical scope that does advanced analysis, and one Keysight Infiniivision scope for service type of work. Preferably 3000T/A series, DSOX1000 series are too basic to justify purchase.
If I had only one scope, no way I would get DSOX1204 before RTB2000 or SDS2000X+.
If you just have a hobby, want a modern replacement for your old CRT scope and you only want to do basic things, DSOX1204 will do that job well.
For same money you can get more value if you look elsewhere.
-
@ PeDre
With the RTB2004 you can activate the Z channel with SCPI commands.
Awesome! Played a bit with it, it works. Noted you you first need to set the waveform brightness first to 50%, otherwise there is no blanking. And it takes a bit of experimenting to determine the input level/settings and the actual degree of blanking.
This trick is not anywhere in the RTB manual, however. (Searching for it, I did find it in RTM20xx manual..)
Are you (or others) aware of other functionalities of the RTB not documented in the manual?
If so, please share!!!
Thanks again.
-
@ Pope:
It would be great if there were timestamps on the video.
Done.
@2N3055:
Keysight OTOH is much simpler platform and has much less features, releases were mostly bug fixes and paid features unlocks
I was surprised myself to see how many actual new features were added by Keysight via firmware updates. Examples (just looking since at FW2.x versions, after Keysight moved to Linux OS):
- Measurement statistics (FW2.12)
- USB Keyboard entry for labels, annotations, file names, etc. (FW2.10)
- Table (lister) of serial decode messages (FW2.10)
- DEMO function with training signals etc. (FW2.10)
- LXI compliance and VXI-11 protocol support (FW2.10)
- Save and upload waveforms and other files via web interface (FW2.10)
- SCPI Device Control online manual via web interface (FW2.10)
- USB or LAN attached printer support (FW2.10)
Granted, some of these just brought the instrument in line with what was already there in competing scopes, but still, it's nice to see that functionalities are added, even as of recently (September 2021).
Performance improvements include:
- Increased waveform update rate (FW2.10)
- Increased number of memory segments (FW2.10)
- Additional memory depth (FW2.10) (even if it's still not impressive compared to competitors...)
-
@ Pope:
It would be great if there were timestamps on the video.
Done.
@2N3055:
Keysight OTOH is much simpler platform and has much less features, releases were mostly bug fixes and paid features unlocks
I was surprised myself to see how many actual new features were added by Keysight via firmware updates. Examples (just looking since at FW2.x versions, after Keysight moved to Linux OS):
- Measurement statistics (FW2.12)
- USB Keyboard entry for labels, annotations, file names, etc. (FW2.10)
- Table (lister) of serial decode messages (FW2.10)
- DEMO function with training signals etc. (FW2.10)
- LXI compliance and VXI-11 protocol support (FW2.10)
- Save and upload waveforms and other files via web interface (FW2.10)
- SCPI Device Control online manual via web interface (FW2.10)
- USB or LAN attached printer support (FW2.10)
Granted, some of these just brought the instrument in line with what was already there in competing scopes, but still, it's nice to see that functionalities are added, even as of recently (September 2021).
Performance improvements include:
- Increased waveform update rate (FW2.10)
- Increased number of memory segments (FW2.10)
- Additional memory depth (FW2.10) (even if it's still not impressive compared to competitors...)
Out of all these DEMO with training signals is only thing that is optional and useful. Printer support is useless and never in my life I used it or will. Saving data to network share is useful thing. They have same stupid thing in expensive 3000T series too.
The rest of the features are things that they HAD to add because they were ridiculed about it. Even 300€ Rigol DS1054Z and Siglent SDS1104X-U has statistics... SDS1104X-E has all of it for whooping 500€...
Memory was pathetically small, it had 50 segments in segmented memory.. etc etc..
It wasn't them being nice, it was the struggling to survive...
Funny thing, is by doing all that they made it actually usable, and if I had to buy low end Keysight scope, I would buy DSOX1200X and not 2000S series.. It is much more affordable and basically better.
But DSOX1204 is seriously outclassed by both RTB2000 and SDS2000X+. They are two levels up from it.
There is nothing impressive about DSOX1204. Just a nice CRT emulation with good refresh rate. Which, by the way is NOT at the level of 3000a/T series (that is "legendary" for it's 1 Milion triggers per second) but only has 1/5 of that. Still very good thou, but nothing special.
Rigol MSO5000 is more than twice faster than that.
It reminds me of one of those Ferrari branded golf carts. Whooohoo but bla...
If it where 500-600 € scope then fine. Even then, competition has more memory etc etc. But that is it's class. And we could argue feature ws polish and brand name ...
-
@ PeDre
I have played around with the RTB2004 XYZ mode for some time,
My own experiments largely align with yours.
- In analogue mode, it seems from min to max channel values there are four equal ‘zones’ in which brightness goes from low to high.
- In digital mode, the threshold can be set from -100 to +100 (different from the RTM) but value 0 puts the threshold at the minimum channel value (next to negative overload) and other values dont change this behavior.
Having this said, this is not a claimed or documented feature, so we should not complain. After some experimentation it’s useful for those that need it.
But should R&S (in a future firmware upgrade?) ever introduce this function to the RTB, the above things need to be ironed out for sure - even if that might not be difficult for them to do. Probably low hanging fruit (and they are already written the UI code for other devices using the same software platform...)
Also, if they do so, it would be great if a math channel can be selected as Z source. That way the user can 'prepare' the signal in a way fitting the purpose. (Typically, in scopes that call this feature 'blanking', a positive value dimes the screen, and those that cal it 'intensity control', a positive value makes the screen bright. Using math can make the user make it behave anyway he wants).
-
Now posted the next video, which is on user interface and customization (Episode 2). I also updated the functional comparison documents with lots of additions and a couple of changes and corrections, thanks to the input on this forum.
https://youtu.be/T_A3TPn-2IU
-
That's the link to youtube studio and not the video for viewing ;)
-
That's the link to youtube studio and not the video for viewing ;)
Eh, yes. :-[
Video is here (really):
https://youtu.be/T_A3TPn-2IU
-
That's the link to youtube studio and not the video for viewing ;)
Eh, yes. :-[
Video is here (really):
https://youtu.be/T_A3TPn-2IU
An error with the 10Bit mode. SDS2000X+ is limited to 100MHz in 10Bit mode. Not 10MHz or 20Mhz.
-
An error with the 10Bit mode. SDS2000X+ is limited to 100MHz in 10Bit mode. Not 10MHz or 20Mhz.
Yes, correct. I added an erratum. Recording videos without mistakes is much harder than writing documents of forum posts :-| The overview document was correct on this, fortunately.
-
v40 - Page 8 - Acquisition system & memory
- Segmented memory depth
RTB2000 - 160Msample
should be: 320 Msample (e.g. 1 Channel, Record Length 10 MSa, No. of Segments 32)
Thanks! I was still planning to dig into memory in much more detail.
The Product Brochure | Version 06.00 (https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/RTB2000_bro_en_3607-4270-12_v0600.pdf) mentions 160 Msample segmented memory, without further details. But the Data Sheet Version 15.00 (https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/RTB2000_dat-sw_en_3607-4270-22_v1500.pdf) indeed notes that memory is 320 Msample per channel in interleaved (i.e., 2 channel) mode.
So, somewhat surprisingly, the product brochure is underselling a bit ;-)
Will update!
-
When testing decoding (it looks like you are doing that), don't forget to test where the bitrate tops out at different memory lengths. You can find nasty surprises there.
-
I have a request: when you're showing the UI of any given scope, can you show the screen itself, as opposed to the remote UI for it? I ask because the real responsiveness (good or bad) of the scope's UI isn't going to come through in the remote UI. This is especially true of the Keysight, where the remote UI looks very slow, but the in-person experience is very fast.
-
I have a request: when you're showing the UI of any given scope, can you show the screen itself, as opposed to the remote UI for it? I ask because the real responsiveness (good or bad) of the scope's UI isn't going to come through in the remote UI. This is especially true of the Keysight, where the remote UI looks very slow, but the in-person experience is very fast
Thanks for the feedback.
I understand your wish and originally had planned to do that. But shooting a comparison video with >2 devices using camera’s takes a lot of additional resources, which eventually would compete with the overall scope and the feasible timeline. (It’s already surprising how much one underestimates the time it takes to make such videos before actually starting..)
But what I will try is to have at least have some parts in from real cameras where speed matters. And yes, there we will probably see the Keysight is very fast in many ways indeed. It's a satisfying experience.
Also, note there are quite some different dimensions in the ‘perceived’ display speed of a device. There is the update of waveforms (e.g., when changing time base or vertical settings, there is possible sluggishness in the overall user interface, there are possible delays in specific more demanding functions. There is the update rate of real-time tables (measurements, serial decode) and (decode) diagrams. There is the catching of infrequent events (where both waveform update and screen-related aspects play a role). One could almost make a video on this alone (which I am not planning to do).
Also otherwise, there is a bewildering number of aspects on which these oscilloscopes differ (in the comparison document - which will soon be updated - I now distinguish over 600 in 40 pages). This can make it challenging to choose the one that fits your needs.
At the same time, it reflects how sophisticated these instruments have become. And by virtue of a rather significant market size, these devices are much more affordable than more dedicated instruments- so you get an incredible bang for the buck ;-)
-
On top of that a UI may be fast but you'll also need to look at efficiency. Needing to go through several layers of menus versus having all settings in 1 screen to setup decoding for example.
-
On top of that a UI may be fast but you'll also need to look at efficiency. Needing to go through several layers of menus versus having all settings in 1 screen to setup decoding for example.
Certainly so. While preparing the next video episode on serial coding, I noted that for one device you need to visit 7 different menu pages to see and set all serial decode and serial trigger settings (plus two menu pages to get there).
While another device has all these settings on one single page, where you can see and set them all.
-
New video is out! Over one hour of in-depth discussion on serial protocol decoding of the three scopes.
And if that is too long for you, there is a TOC that allows you to jump right away to the parts that you want to see.
https://youtu.be/5MofTw7N2t8
-
Hello,
thx for your videos.
In 40:43 on the right side is a USB scope. It looks like some 3000 or 5000 series from Picotech.
Sorry but I am curious what it is exact?
Best regards
egonotto
-
Hi egonotto,
In 40:43 on the right side is a USB scope. It looks like some 3000 or 5000 series from Picotech.
Sorry but I am curious what it is exact?
Indeed, it's a PicoScope 3405D. Due to its compact form, I take it sometimes with me when I want to measure on location. I particularly like the wide choice of serial protocol decoders, including USB (1.5 Mbps LowSpeed and 12 Mbps FullSpeed) and some of the features it offers for decoding. But the lack of a serial trigger puzzles me and is the reason I do not use it that often after all for that purpose. (I think I recently noted that before on this forum.)
I considered taking it along in the comparison video. But for a variety of reasons, I eventually opted not to do so.
-
Really interesting to see the comparison of decoding between those scopes. Hope Siglent watches your videos for inspiration :)
-
Today I posted a new episode, on measurement tools (cursors, measurement mode, DVM and frequency counters). And this episode has a new winner: Siglent.
This is the fifth episode I am posting (not in subsequent order though). Stay tuned for the next one!
https://youtu.be/TAoB5614hs4
-
https://youtu.be/TAoB5614hs4
maybe its still set to private, or not publish yet? cannot seem to access it
-
@dreamcat4, thanks for letting me know.
The video was set to public, but it may take a little while before that seems to work everywhere. (Maybe YouTube has some replication mechanism across their servers?)
In any case, it works here for a computer not logged in to my account.
Hope you find the video useful!
-
thanks, yes can see it here now, all fine. and for sure: these video are very much appreciated, i am pretty grateful. as someone saving up to buy their 1st oscilloscope
-
I'm not sure why--perhaps YouTube hosting this far away from me--but I see low video quality (resolution), buffering and skipping. I'll try downloading it and see what I get.
-
I'm not sure why--perhaps YouTube hosting this far away from me--but I see low video quality (resolution), buffering and skipping. I'll try downloading it and see what I get.
bdunham7, sorry to see that. The video is definitely posted in HD (1080p50), I do that because otherwise it is hard to really read the screens on these devices...
Probably a YouTube thing, hope your stream is better now!
-
I just watched your episode about the signal generators, and was interested in the SDS2000 problem with loading arb waveforms from channels - I get the same 'File does not exist!' error when attempting to use this feature on my scope.
So, I was interested in what file is missing, and attached to the scope via telnet to have a dig about, and get this entry in the logs when this happens:
W0327 19:20:09.298774 894 bu_app_msg_awg.cpp:626] /usr/bin/siglent/usr/usr/AWG_channel_wave.bin not exist
So there appears to be a missing binary file which it is expecting to launch at this moment. It's possible that this is a release issue from Siglents end, so they may be able to run and test this feature in their QA team, but it doesn't make it to the binary release onto the production scopes?
I'm also wondering if the SDS5000 has this same functionality, and whether it works, and whether such a binary is included in their software install.
Anyhow, interesting series of videos, i'm learning stuff about the scope I already own!
-
Hi Cesare, thanks for the comments, and information on the specific file that the scope is looking for when that error pops up. My current thinking is that the BIN file might you identified is not, as you suggest, an executable file that needs to be launched, but instead a waveform data file (Siglent can save waveforms as Binary (BIN) as well as CSV and matlab). I tried to save a BIN file with that specific name from the device interface itself but I don't seem to be able to get to that specific folder the scope is looking into. Perhaps a TELNET session allows us to move a file there. Something we should dig deeper into!
And.... you are ahead of me: there is indeed a new episode out (two hours ago ;-), did not have the chance yet to write it here.
For those that have not seen it yet: new episode 7 talks about signal generators (function generator, ARB, pattern generator, training signals). So about scopes generating signals instead of analyzing them.... ;-)
Along with the episode, there is also an updated comparison document, as well as two XLS files: one to create your own ARB waveforms for both RTB and SDS, and one to create 4-pin patterns for the RTB.
Enjoy!
-
Hello,
thanks RBBVNL9 for the video.
In the datasheet from RTA4004 is the same 10 Ms/s.
I think they mean the frequency is max 10 MHz and 250 Ms/s.
I copy a part of a sine wave to the function generator of my RTA4004.
This arb function is played with 1 kHz and 10 MHz.
The pictures shows, that the max sample rate from the function generator must be far more than 10 Ms/s.
Best regards
egonotto
PS.: The fall time is about 6 ns.
-
Hi Cesare, thanks for the comments, and information on the specific file that the scope is looking for when that error pops up. My current thinking is that the BIN file might you identified is not, as you suggest, an executable file that needs to be launched, but instead a waveform data file (Siglent can save waveforms as Binary (BIN) as well as CSV and matlab). I tried to save a BIN file with that specific name from the device interface itself but I don't seem to be able to get to that specific folder the scope is looking into. Perhaps a TELNET session allows us to move a file there. Something we should dig deeper into!
Yes of course, silly me, it'll be expecting a BIN waveform file.
The built-in standard waveforms are stored on the scope in /usr/bin/siglent/config/arb, if I copy one of these to the specified .bin filename, all of a sudden selecting the stored/channel arb waveform works (well, it works in the sense that it loads the waveform i've copied). So i ran:
# cp /usr/bin/siglent/config/arb/18_sinc_ram.bin /usr/bin/siglent/usr/AWG_channel_wave.bin
And then selecting stored/channel pops me up with a sinc waveform.
So this does indeed feel like an incomplete feature - i'm guessing there is a missing stage where the channel is chosen and data is written to this directory with the given name. I'm assuming they do this to persist the waveform, so that, for example, if you disable and re-enable the AWG you get back your previously used waveform.
-
Dear Egonotto,
I think they mean the frequency is max 10 MHz and 250 Ms/s.
Yes, that does make sense. The sample rate indeed needs to be more way than the 10 MSa/s R&S mention in the specifications in order to output the waveform you show (and assuming it would be the same on the RTB as the RTA). I agree with you it is likely the same 250 MSa/s as used for the regular waveform generation. Will update my overview document. Thanks for checking!
-
Dear Cesare,
So i ran:
# cp /usr/bin/siglent/config/arb/18_sinc_ram.bin /usr/bin/siglent/usr/AWG_channel_wave.bin
And then selecting stored/channel pops me up with a sinc waveform.
Good to know! The first next thing to try is to copy an actual waveform saved from an analogue channel to the right location and with the right name and see if that works too (while the build-in ATB waveforms may be optimized for 16kpts, a BIN saved from a measured waveform will be much, much larger and the ARB will need to have some strategy to reduce that to 16kpts).
The second next thing is for Siglent to fix this in the scope so we would not need a telnet session to make an advertised function work...
-
I've tried different size files captured from the device, written to USB and copied across to the right place, and no, these aren't correctly loaded. This doesn't surprise me, I imagine the missing stage is where this would happen.
As you say, it's a missing feature, Siglent need to resolve this. The overall feel of the AWG is that it's just about enough to get by with, but given the licence cost is approaching that of a SDG1032X with dual channels it does seem an odd set of features with odd omissions. It does feel like the software is limiting what the hardware is capable of, although maybe the missing modulation and sweep options suggest the hardware is quite compromised? I don't know how the SDS5000 compares for example.
-
@RBBVNL9,
It is possible to transfer a waveform from one of the vertical channels to the Arbitrary Waveform Generator.
This is done from the vertical channel menu dialog box.
One of the menu items is " Apply To ".
Selecting " Apply To ", brings up a list of options, one of these is ARB.
This copies the current channel waveform to the Arbitrary Waveform Generator.
You can then go to the Arbitrary Waveform Generator and select "Stored" and then " Channel' to output the waveform.
This is mentioned in the User Manual in section 12.2, Channel Setup, but the way it is explained is somewhat confusing.
Regards.
-
Dear seronday,
It is possible to transfer a waveform from one of the vertical channels to the Arbitrary Waveform Generator.
This is done from the vertical channel menu dialog box.
One of the menu items is " Apply To ".
Selecting " Apply To ", brings up a list of options, one of these is ARB.
This copies the current channel waveform to the Arbitrary Waveform Generator.
You can then go to the Arbitrary Waveform Generator and select "Stored" and then " Channel' to output the waveform.
That is wonderful! I just tested it and it indeed works. In fact, the very moment I tick "Apply To" in the vertical channel menu the wave appears on the output of my AWG (at least when it is turned on), so there seems to be no need in the AWG menu to go to "Stored" and "Channel". The latter only seems relevant if you in-between switch to another AWG waveform and want to go back to the captured one again.
Just for the sake of completeness: a week before I said in my video I did not get this to work, I did already posted my problem in the EEVBLOG forum but no one seemed to be able to provide a solution at that time...
But you are the one who provides the solution so compliments go out to you!
This is mentioned in the User Manual in section 12.2, Channel Setup, but the way it is explained is somewhat confusing.
True. In the last weeks, I went through the manual as well as all the device menu's quite carefully but missed this. Even searched the manual on keywords "ARB" and "Arbitrary' with no success, but I see in Section 12.2 they do not use these terms... Anyway, this information should really have been in the part of the manual that describes the ARB (like Section 28.3)!
-
Dear Egonotto,
I think they mean the frequency is max 10 MHz and 250 Ms/s.
Yes, that does make sense. The sample rate indeed needs to be more way than the 10 MSa/s R&S mention in the specifications in order to output the waveform you show (and assuming it would be the same on the RTB as the RTA). I agree with you it is likely the same 250 MSa/s as used for the regular waveform generation. Will update my overview document. Thanks for checking!
Hi Rudy - Not 100% sure about the question here, but the waveform generator in the RTB2000 (option RTB-B6) does have a sample rate of 250 MSamples/sec (as per the specifications)
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/RTB2000_dat-sw_en_3607-4270-22_v1600.pdf (https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/RTB2000_dat-sw_en_3607-4270-22_v1600.pdf)
Incidentally, I just did a video walkthrough on the basics of using the RTB2000 function generator.
https://www.youtube.com/watch?v=g7hw9EcB8kE (https://www.youtube.com/watch?v=g7hw9EcB8kE)
-
Dear pdenisowski, thanks for the reply.
The discussion above is (specifically) about the sample rate for the arbitrary wave function.
For this, the RTB2000 specifications (V.1600) you refer to mention: "Sample rate: max. 10 Msample/s" and "Memory depth: 16k points" (see screenprint attached, yellow highlights)
Document R&S RTx-B6 ARBITRARY WAVEFORM AND 4 BIT PATTERN GENERATOR (https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/Option_sheet_-_RTx-B6__arbitrary_waveform_and_4_bit_pattern_generator__v1.10.pdf) (Version 01.10, May 2020), for the RTB series, reads "Signal forms frequency ranges (arbitrary): max. 10 Msample/s; 32k points" (see screenprint attached, yellow highlights)
I think that in both documents, the 10 Msample/s is an error and should probably be 250 MSa/s (otherwise it could not generate the waveforms it actually does in practice!). Moreover, in the specifications, the 16k points is probably an error and should be 32k, as confirmed by tests in practice.
PS thanks for the walkthrough video, just looked at it!
-
Preparing for a new video on observing infrequent events and mask tests, and seeing huge differences there, so I thought I should first dig a bit more into actual triggering behaviour.
I see something I am not sure I understand well.
In short:
- I feed all oscilloscopes with a 1kHz square wave on channel 1.
- I set the horizontal time base such that I see two periods on the screen (200uS/DIV on the SDS and DSOX, and 170uS/DIV on the RTB as it has 12 instead of 10 horizontal divisions). Attaching a pic.
- I activate the trigger out on each device and look at these on a fourth oscilloscope (a PicoScope 3405D). Channels are 1: RTB, 2: SDS, 3: DSOX and 4: input square to scopes.
All scopes are set to regular trigger settings (trigger on positive edge, level halfway square, no holdoff, DC coupling, no noise reject or filter). Record length / memory depth is chosen for best results, if there is any difference. Segmented acquisition off. Auto trigger or normal trigger makes no difference on any of the devices. Lastly, on the RTB I set the trigger out a pulse to 1mS to make it well visible (using SCPI command TRIGger:OUT:PLENgth 1E-3).
Ideally, I would expect to see a trigger every one out of three periods (where the positive edges of the two other periods are shown on the screen), so a constant 333.3 pulses per second on the trigger out bus. After all, 1kHz is such a slow signal and any eventual blank time these scopes need to write to memory etc. should be neglectable.
The results are in the attached screen print.
- The Keysight DSOX behaves exactly as expected, triggering every third period.
- The Rohde & Schwarz RTB mostly every third period but there are some (predictable) interruptions. Is the scope doing something else every once in a while ?!?
- The Siglent SDS triggers much, much less. Only 30 pulses per second instead of the expected 333.
Can anyone enlighten me? Why does the RTB have periodic interruptions? And, more importantly, why is the SDS so slow to re-trigger ?!?
Do I overlook relevant device settings?
Thanks for your insights!
-
Hello,
my conjecture: RTB and SDS take time to execute the samples. Meanwhile they do not sample.
RTA behave little wilder.
Best regards
egonotto
-
Can anyone enlighten me? Why does the RTB have periodic interruptions? And, more importantly, why is the SDS so slow to re-trigger ?!?
Do I overlook relevant device settings?
Double check the memory depth you have set, it often has a large effect on the update rate. Not sure if the SDS 2000X will approach "perfection", older models were similar to what you see:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3169060/#msg3169060 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3169060/#msg3169060)
(no idea if there is a set of measured data for the 2000X, so hard to search through the mountains of information on this forum).
If you look very carefully over a long period even on the Keysight there will be some gaps in the triggers (or use a pulse width trigger to catch it!).
Edit, found some measured values for the 2000X:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3133558/#msg3133558 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3133558/#msg3133558)
Not fully explained the methodology, but suggests better performance is possible in some configuration/situation.
-
Thanks egonotto, Someone and PeDre for taking the time to respond so swiftly. Some quick replies:
Double check the memory depth you have set, it often has a large effect on the update rate.
I tried each memory depth setting available in the SDS (see my post) but none of made a difference in seeing this pattern. But will do some more attempts later. (This setting did make a difference for the RTB though.)
If you look very carefully over a long period even on the Keysight there will be some gaps in the triggers (or use a pulse width trigger to catch it!).
That might be the case. But as can be seen from the PicoScope screen print, the Keysight DSOX’s average of 333.3 trigger out pulses per second was very stable; over 109 observations (of each ~150 pulses) there is an extremely low standard deviation. So, if it misses triggers, it’s not many. Indeed, a pulse width trigger (or mask test) could reveal this.
Edit, found some measured values for the 2000X:
Like in the post of Martin72 you refer to, I am indeed finding similar, very low waveform update rates on the SDS (orders of magnitude lower than advertised). That is the reason why I started to do these trigger experiments…
This has been asked before, here is Rich's answer:
Thanks for forwarding Rich’s answer. Before posting, I did a search on the forum but it’s not always easy to find what you are looking for, even if it’s there :-| But anyway, questions answered!
RTB and SDS take time to execute the samples. Meanwhile they do not sample.
Yes, seems so. Perhaps the reason the DSOX is doing so well here is that it dedicated these tasks to different hardware resources so it can keep on triggering even when it’s buffering and plotting on the screen.
RTA behave little wilder.
Can you perhaps elaborate on what you mean here?
Bottom line: While it’s now clear to me what the RTB is doing, the bigger concern here is the SDS. After a trigger, it misses something like 10 possible triggers before its ‘arming’ again. For a trigger signal as slow as 1 kHz, this is quite strange. Perhaps, like Martin72 suggests, there might be a serious bug here that is still waiting to be fixed?
-
RTB and SDS take time to execute the samples. Meanwhile they do not sample.
Yes, seems so. Perhaps the reason the DSOX is doing so well here is that it dedicated these tasks to different hardware resources so it can keep on triggering even when it’s buffering and plotting on the screen.
Bottom line: While it’s now clear to me what the RTB is doing, the bigger concern here is the SDS. After a trigger, it misses something like 10 possible triggers before its ‘arming’ again. For a trigger signal as slow as 1 kHz, this is quite strange. Perhaps, like Martin72 suggests, there might be a serious bug here that is still waiting to be fixed?
I do not think it is a bug, but just the way they work. As you say above these different scopes have different hardware separation of the work, DSOX puts most things in ASIC/FPGA which makes it fast but less flexible (examples: cannot reduce memory depth, or turn off interpolation, even though that would make it faster). Probably Siglent do much more of the display drawing in CPU/software for more flexibility/cheaper product (example benefit: colourised intensity view).
-
I do not think it is a bug, but just the way they work.
Well, even if these devices do work differently, Siglent does publish a waveform update rate. And if the actual update rate is orders of magnitude lower than what is published (see the posts of Martin72 and Performa01 referred to above, which are indeed in line with my own measurements, see my video Episode 7 at 47:27) then I think it is correct to speak of a bug...
-
Bottom line: While it’s now clear to me what the RTB is doing, the bigger concern here is the SDS. After a trigger, it misses something like 10 possible triggers before its ‘arming’ again. For a trigger signal as slow as 1 kHz, this is quite strange. Perhaps, like Martin72 suggests, there might be a serious bug here that is still waiting to be fixed?
Hi.
Could you check something on Siglent? If you go into Acquistion menu, do you have Slow or Fast mode set there? You need to be in the dot mode also..
A small suggestion, if I may. To avoid confusion, may I suggest a wording specificum: a time that scope needs to be ready for a new trigger event can be called retrigger time. We can also use a term rearm time or even a blind time to signify time that scope is "blind" to new events while trigger engine is being rearmed for another go. I say that because saying that "scope is missing triggers" can be misconstrued as scope being ready for trigger but it didn't recognize it properly.
Difference is that first one is operating specification of the scope and the other one (missed triggers) is defect, a bug.
A bit of pedantry, I know, but nevertheless not unimportant sometimes.
As Someone correctly said, phosphor emulation works by virtue of sampling short bursts of acquisitions synchronised with screen refresh rate. Keysight also does it on certain timebase settings. Even KS 3000T that is clocked at more than 1 milion triggers per second does it at some settings.
But this is nothing new, really. This is pretty much only thing KS does better in Infiniivision scope series (Megazoom IV based). Whole architecture is based around this feature. With all the compromises that stem from it, like very small memory, use of decimated buffers for all measurements, all time interpolation with no user control etc. These are pretty much speciallistic scopes made to emulate something similar to analog CRT scope triggering performance as primary design goal.
Both R&S and Siglent, with their long memory architecture are closer to "analytic" scope type, where you capture longer sequences and then analyse it. In fact, we can argue that these scopes with long memory can achieve "zero" blind time for bursts of, say, 100ms. This way of thinking, though, does need for user to actually adjust way how they are using scopes, because it is slightly different to how you would use CRT scopes many people are used to.
That is why I always keep repeating that, for instance, KS 1000X series are not very capable scopes (they have very limited capabilities compared to even scopes many times cheaper) but are good for people that don't need advanced features (user wants to to only look at waveform on the screen and maybe use cursors and basic measurements) and that want as good as possible CRT emulation.
-
I do not think it is a bug, but just the way they work.
Well, even if these devices do work differently, Siglent does publish a waveform update rate. And if the actual update rate is orders of magnitude lower than what is published (see the posts of Martin72 and Performa01 referred to above, which are indeed in line with my own measurements, see my video Episode 7 at 47:27) then I think it is correct to speak of a bug...
I have not seen published/advertised waveform rates for different timebases, do you have a link/copy? Only value in the advertising/marketing is the peak:
Waveform capture rate up to 140,000 wfm/s (normal mode), and 500,000 wfm/s (sequence mode)
We usually only see these figures across many acquisition window sizes in "competitive comparisons" or user generated figures (such as on this forum).
Many scopes have advertised "headline" or show high rates in unusual/non-typical modes such as very short memory depth and/or interpolation disabled, getting lower rates with normal memory depth and interpolation on is not wrong/bug but normal/expected.
-
so if this part of the series is all about detecting unusual events or glitches then...
it makes me wonder a lot how do the SDS and RTB compare to lecroy system. because in those products it seems like the most ideally executed feature. where it automatically recognized in the buffer any 'unclean' logic transition. or other such intermittent excursions. you just press a button and the scope does all of the work for you. and brings it up on the display
this feature makes me wonder what is the right lecroy scope to compare to the RTB. for example if it includes that specific feature at a low enough price point to be an alternative option to the RTB 2004
-
I do not think it is a bug, but just the way they work.
And if the actual update rate is orders of magnitude lower than what is published <clip> then I think it is correct to speak of a bug...
In Siglent SDS2000X Plus data sheet (DS0102XP_E01A)
Waveform capture rates up to 120,000 wfm/s (normal mode) and 500,000 wfm/s (sequence mode)
Waveform capture rate (Max.)
Normal mode：120,000 wfm/s;
Sequence mode：500,000 wfm/s
Waveform capture rate
Normal mode: 120,000 wfm/s max.
Sequence mode: 500,000 wfm/s max.
And same oscilloscope but now Teledyne LeCroy brand.
Teledyne test tools T3DSO2000A Data Sheet, datecode 22july20
Key Features
New generation of high speed display technology
› Waveform capture rate up to 120,000 wfm/s
(normal mode), and 500,000 wfm/s (sequence
mode)
Waveform Capture Rate (Max.) 120,000 wfm/s (normal mode), 500,000 wfm/s (sequence mode)
Waveform Capture Rate Up to 120,000 wfm/s (normal mode), 500,000 wfm/s (sequence mode)
(bolded by me)
What is wrong now. Is it difficult to uderstand "up to" or "max"
If this is difficult I think it is education problem or lack of enough knowledge and experience. I can predict this kind of problems may lead to severe problems when need read what ever instruments or electronics, mechatronics, etc data sheets. Is it correct to say... bug in understanding data sheets. :) :)
-
do you have Slow or Fast mode set there? You need to be in the dot mode also..
A small suggestion, if I may. To avoid confusion, may I suggest a wording specificum: a time that scope needs to be ready for a new trigger event can be called retrigger time. We can also use a term rearm time or even a blind time to signify time that scope is "blind" to new events while trigger engine is being rearmed for another go. I say that because saying that "scope is missing triggers" can be misconstrued as scope being ready for trigger but it didn't recognize it properly.
Difference is that first one is operating specification of the scope and the other one (missed triggers) is defect, a bug.
First I think dot mode is not a normal situation to use a scope when wanting to look at waveforms! Its these sorts of "games" that can make comparisons silly, always best to try and find a common setting that all products can meet (and mention that they can do better in their special/preferred setting).
A problem with blind time as a measure is that it is not a constant/deterministic value in most (all?) scopes when in realtime mode, it may be accurate for sequence/segmented modes where nothing is drawn to the screen.
-
what is the right lecroy scope to compare to the RTB. for example if it includes that specific feature at a low enough price point to be an alternative option to the RTB 2004
ah, i remember now Martin72 had one...
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4054573/#msg4054573 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4054573/#msg4054573)
it was the WS3024Z
-
What is wrong now. Is it difficult to uderstand "up to" or "max"
If this is difficult I think it is education problem or lack of enough knowledge and experience. I can predict this kind of problems may lead to severe problems when need read what ever instruments or electronics, mechatronics, etc data sheets. Is it correct to say... bug in understanding data sheets. :) :)
Peak value does not predict others! yes. A previously popular scope claimed best waveform rate but in real world performed badly:
https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/msg973064/#msg973064 (https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/msg973064/#msg973064)
-
what is the right lecroy scope to compare to the RTB. for example if it includes that specific feature at a low enough price point to be an alternative option to the RTB 2004
ah, i remember now Martin72 had one...
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4054573/#msg4054573 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4054573/#msg4054573)
it was the WS3024Z
Only LeCroy had rights to market SDS3000X (WS3000Z) DSO's to western markets and SDS3000 (WS3000) models before them as their development was a joint venture.
-
what is the right lecroy scope to compare to the RTB. for example if it includes that specific feature at a low enough price point to be an alternative option to the RTB 2004
ah, i remember now Martin72 had one...
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4054573/#msg4054573 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4054573/#msg4054573)
it was the WS3024Z
AFAIK Martin has WS3024 and WS3024Z at work (among other LeCroys). At home he has SDS2104X+..
They recently bought Siglent SDS2104X+ at work too and it seems it fits nicely among its LeCroy "distant relatives"..
-
what is the right lecroy scope to compare to the RTB. for example if it includes that specific feature at a low enough price point to be an alternative option to the RTB 2004
ah, i remember now Martin72 had one...
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4054573/#msg4054573 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4054573/#msg4054573)
it was the WS3024Z
AFAIK Martin has WS3024 and WS3024Z at work. At home he has SDS2104X+..
And now at work too !
The lad should be paid a commission. ;D
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4067635/#msg4067635 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4067635/#msg4067635)
-
Thanks all for digging so deep into this. And thanks to 2N3055 for suggesting clear terminology. I noted that sometimes specifications sheets are also not super clear on this. The SDS2000X+ spec sheets talk both of “waveform capture rate” and “waveform update rate”. They seem to mean the same thing with these two terms, but I’m not 100% sure and find it confusing.
And yes, the specifications of Siglent use terms such as “up to” or “max" (and they are not the only ones *). Not knowing under which conditions these maxima are reached, it’s hard to decide whether a device meets the specs, and when we can speak of a bug or not.
Having that said, if in a non-trivial case (triggering a simple 1kHz square wave) a device has a score that is orders of magnitude lower than what one would expect (and is orders of magnitude lower than other devices) I do think it’s a relevant thing for users to know about.
so if this part of the series is all about detecting unusual events or glitches then...
I know I called for input on this topic, but I should also mention that my comparison is certainly not aiming to focus on this aspect only, it’s one among many aspects I’m liking into.
* I love, however, the way Keysight provided its waveform update specs: “≥ 200,000 waveforms/sec” on page 12 of their Keysight InfiniiVision 1000 X-Series Oscilloscopes Data Sheet (https://www.keysight.com/nl/en/assets/7018-06411/data-sheets/5992-3484.pdf)
-
Preparing for a new video on observing infrequent events and mask tests, and seeing huge differences there, so I thought I should first dig a bit more into actual triggering behaviour.
I see something I am not sure I understand well.
In short:
- I feed all oscilloscopes with a 1kHz square wave on channel 1.
- I set the horizontal time base such that I see two periods on the screen (200uS/DIV on the SDS and DSOX, and 170uS/DIV on the RTB as it has 12 instead of 10 horizontal divisions). Attaching a pic.
- I activate the trigger out on each device and look at these on a fourth oscilloscope (a PicoScope 3405D). Channels are 1: RTB, 2: SDS, 3: DSOX and 4: input square to scopes.
All scopes are set to regular trigger settings (trigger on positive edge, level halfway square, no holdoff, DC coupling, no noise reject or filter). Record length / memory depth is chosen for best results, if there is any difference. Segmented acquisition off. Auto trigger or normal trigger makes no difference on any of the devices. Lastly, on the RTB I set the trigger out a pulse to 1mS to make it well visible (using SCPI command TRIGger:OUT:PLENgth 1E-3).
Ideally, I would expect to see a trigger every one out of three periods (where the positive edges of the two other periods are shown on the screen), so a constant 333.3 pulses per second on the trigger out bus. After all, 1kHz is such a slow signal and any eventual blank time these scopes need to write to memory etc. should be neglectable.
The results are in the attached screen print.
- The Keysight DSOX behaves exactly as expected, triggering every third period.
- The Rohde & Schwarz RTB mostly every third period but there are some (predictable) interruptions. Is the scope doing something else every once in a while ?!?
- The Siglent SDS triggers much, much less. Only 30 pulses per second instead of the expected 333.
Can anyone enlighten me? Why does the RTB have periodic interruptions? And, more importantly, why is the SDS so slow to re-trigger ?!?
Do I overlook relevant device settings?
Thanks for your insights!
Please can you clarify every oscilloscope sampling speed and current acquisition true memory length used in this image.
-
ah ok. but then does that lecroy 3000 series actually have the feature in question? if it is actually a rebranded siglent and not a true windows based lecroy scope?
the feature seems to be able to detect any arbitrary random glitches or anomalies. such as the failed or unclean logic transitions etc
-
First I think dot mode is not a normal situation to use a scope when wanting to look at waveforms! Its these sorts of "games" that can make comparisons silly, always best to try and find a common setting that all products can meet (and mention that they can do better in their special/preferred setting).
A problem with blind time as a measure is that it is not a constant/deterministic value in most (all?) scopes when in realtime mode, it may be accurate for sequence/segmented modes where nothing is drawn to the screen.
I agree with you in general. But fact is that SDS6000H12 works well in dot mode. As soon as you have 1000 pixels horizontally, it looks like continuous line, without any interpolation artefacts. Retriggered events overlay on top and you get SARI, a RIS alike random repetitive sampling. So I keep jumping between line and dot mode.
But making clear specifications is important. It's a shame not even big ones are doing it right. There is a Keysight whitepaper where they compare 3000T wfms/s with competition, carefully choosing test to favour Keysight. And forgetting to mention that much more expensive Keysight scopes have like 100 Wfms/s trigger rate because they have large memories and are doing full buffer managements on large datasets.
They also mention casually memory sizes, but 3000T has only 500k of sample memory when doing 4ch+ digital normal mode (4 buffer-2 per ch-1 with digital -0.5 Mpts for ping pong buffers. 1Mpts for Single mode). Scope with 100Mpts will be 100x slower everything else being equal. Scope with 500MPts will have soo much more work to do.
To make it short, Keysight will have faster retrigger rate because it is specifically designed to do so. Siglent was made to work LeCroy way, and those don't maximize raw retrigger rate but analytic capabilities in long memory.
-
ah ok. but then does that lecroy 3000 series actually have the feature in question? if it is actually a rebranded siglent and not a true windows based lecroy scope?
the feature seems to be able to detect any arbitrary random glitches or anomalies. such as the failed or unclean logic transitions etc
Not even windows based Wavesurfers have that feature fully implemented (parametric triggers).
But you have advanced triggers on Siglent Touch series and also always running (if enabled) search function that you can parametrize to look for several waveform parameters. Those can detect runts, non monotonic edges, slow edges, pulse widths out of spec etc... Combined with advanced triggers it has (including zone triggers), measurements and history mode there are many things that can be detected.
-
Thanks all for digging so deep into this. And thanks to 2N3055 for suggesting clear terminology. I noted that sometimes specifications sheets are also not super clear on this. The SDS2000X+ spec sheets talk both of “waveform capture rate” and “waveform update rate”. They seem to mean the same thing with these two terms, but I’m not 100% sure and find it confusing. .....
Just to make it clear, it wasn't a critique to you, but a suggestion to actually address that problem you're mentioning: a nonuniform language that confuses us all. If we agree to common language, we understand each other better..
-
Just tested it with one other Siglent scope model (not just SDS2000X Plus because I do not have it now). ETA 2022-04-16: yes it was unpublished SDS2000 HD what I can tell now after Performa01 have published it.
what have around same memory, samplerate and royghly same wfm speed specs.
Only for show that different settings give different result.
Also looked how dots/vectors x/Sinc affect in this case and no notable changes.
This is NOT comparable directly with SDS2000X Plus!! So for it this is nonsense but only show that different setup give different result.
Same signal and only to CH1 and same trig. CH2, 3 and 4 just only on without signal.
All memory lengths same as displayed wfm length (display width 2ms (200us/div))
10k memory, 5MSa/s ~317 acquistion/s (wfm/s)
100k memory 50MSa/s ~319 acquistion/s (wfm/s)
1M memory 500MSa/s ~245 acquistion/s (wfm/s)
2M memory 1GSa/s ~179 acquistion/s (wfm/s)
Same signal and only to CH1 and CH4 just on without signal, same trig.
20k memory, 10MSa/s ~319 acquistion/s (wfm/s)
200k memory 100MSa/s ~313 acquistion/s (wfm/s)
2M memory 1GSa/s ~179 acquistion/s (wfm/s)
4M memory 2GSa/s ~91 acquistion/s (wfm/s)
Same signal and only to CH1, same trig.
20k memory, 10MSa/s ~326 acquistion/s (wfm/s)
200k memory 100MSa/s ~326 acquistion/s (wfm/s)
2M memory 1GSa/s ~179 acquistion/s (wfm/s)
4M memory 2GSa/s ~91 acquistion/s (wfm/s)
All these "memory" lengths mean true current acquisition lenght (not max memory length set value - if it differ)
And this length is same as displayed signal lenght.
Measured trig out using HP 53131A HS010 using 1s Gate time. Peak values are, or may be, slightly higher.
And now I repeat again.
Please, @RBBVNL9, can you tell what was different scopes current true acquisition lengths (samples) and sampling speed. (in your image)
-
In reponse to 2N3055 and rf-loop:
Please can you clarify every oscilloscope sampling speed and current acquisition true memory length used in this image.
Could you check something on Siglent? If you go into Acquistion menu, do you have Slow or Fast mode set there? You need to be in the dot mode also..
Below are the settings that were used for the measurement reported earlier (in the PicoScope screen print):
RTB:
- Record length: 10 kSa. Note: at 200kSa I start to see a slight reduction in trigger events per second. At 10Msa there are roughly half the number of trigger events per second.
- Sample rate is 4.81 MSa/s (this number changes when other record lengths are selected)
- Trigger output pulse set to 1ms using TRIGger:OUT:PLENgth 1E-3
- Only Channel 1 activated.
SDS
- Record length (parameter “MAX record length”) setting is 20k. Interestingly, any other setting (200k, 2M, 20M, 200M) does not make any difference for this measurement
- Sample rate is 10.0 MSa/s (this number changes when other record lengths are selected)
- “Acqu Mode” set to “Fast”. Interestingly, changing it to “Slow” does not make any difference for this measurement
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS 100ms in between, so a considerable drop in the number of trigger events per second.
- Display Type = Vectors. But setting it to dots makes no difference whatsoever.
- Only Channel 1 activated.
DSOX
- Sample rate is 500MSa/s. ASAIK this rate is simply a function of the chosen timebase setting, there is no other way to choose this.
- Segmented memory is off (but when turned on, that has no impact on the number of trigger out pulses)
- Only Channel 1 activated.
Those are the kind of relevant parameters, I guess. But perhaps there are others that matter?
-
In reponse to 2N3055 and rf-loop:
Please can you clarify every oscilloscope sampling speed and current acquisition true memory length used in this image.
Could you check something on Siglent? If you go into Acquistion menu, do you have Slow or Fast mode set there? You need to be in the dot mode also..
Below are the settings that were used for the measurement reported earlier (in the PicoScope screen print):
RTB:
- Record length: 10 kSa. Note: at 200kSa I start to see a slight reduction in trigger events per second. At 10Msa there are roughly half the number of trigger events per second.
- Sample rate is 4.81 MSa/s (this number changes when other record lengths are selected)
- Trigger output pulse set to 1ms using TRIGger:OUT:PLENgth 1E-3
SDS
- Record length (parameter “MAX record length”) setting is 20k. Interestingly, any other setting (200k, 2M, 20M, 200M) does not make any difference for this measurement
- Sample rate is 10.0 MSa/s (this number changes when other record lengths are selected)
- “Acqu Mode” set to “Fast”. Interestingly, changing it to “Slow” does not make any difference for this measurement
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
- Display Type = Vectors. But setting it to dots makes no difference whatsoever.
DSOX
- Sample rate is 500MSa/s. ASAIK this rate is simply a function of the chosen timebase setting, there is no other way to choose this.
- Segmented memory is off (but when turned on, that has no impact on the number of trigger out pulses)
DSOX have 1us and SDS have 2us max trig interval in segment & sequence mode.
SDS
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and when I look segments time stamps they have all 3ms (3000us) delta time. So 333.33 segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33... segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)... still all 19 segments delta time is 3ms.... 333.33... segment/s
What is this your 100ms or (or mS as you said, aka milli Siemens what is conductance SI derived unit)
In SDS2000X Plus is some severe bug in Sequence mode or some external reason... ;)
-
They also mention casually memory sizes, but 3000T has only 500k of sample memory when doing 4ch+ digital normal mode (4 buffer-2 per ch-1 with digital -0.5 Mpts for ping pong buffers. 1Mpts for Single mode). Scope with 100Mpts will be 100x slower everything else being equal. Scope with 500MPts will have soo much more work to do.
You can keep pulling up the same "small memory" argument, except it is common for memory to change in different acquisition settings across most scopes. Those characteristics are not avoided in the Keysight data sheets or left as only up-to/maximum/peak values, and made very clear in the manuals (contrasting to these other examples discussed here where it is not clear at all what is expected).
But you make the false claim that there is a comparison with memory depth, the waveform capture measurements that competitors use keep the memory depth very short to inflate their numbers. Look at how much slower the competitors are despite choosing less memory! (when at same memory they are far behind). Scopes are not some computer system where the parts are put together in imbalanced ways by the end user, they are a finished product from the manufacturer who has decided on the system performance. Keysight make a real time scope with 100Mpts of memory, the EXR or MXR series, without a significant drop in waveform rate (keeping the system balanced).
Where you keep falling over is trying to make out like all scopes work/function the same. The Keysight megazoom method has been to decouple display and waveform memory, they are two different paths that dont interact. Acquisition data is piped to the display plotter/memory (through decimation etc) separately to the waveform memory. As you say before, to make things fast they chose to put most of the emphasis/features on the decimated view (positive example: fast eye diagrams). Most other scopes draw the waveforms from the acquisition memory, and take measurements from the original data (Lecroy being the extreme example of that, positive example: higher resolution measurements). Completely different with advantages and disadvantages, for comparisons they are best listed as characteristics rather than put as a good/bad binary check box against specific/your preference.
-
SDS
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and when I look segments time stamps they have all 3ms (3000us) delta time. So 333.33 segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33... segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)... still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc
Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.
-
OK, lots of input from various persons, need to find some time to digest all of it (got other work to do today...)
(or mS as you said, aka milli Siemens what is conductance SI derived unit)
You caught me there! It usually upsets my when people make errors in SI units or prefixes, but here I had a slip of the pen and did it myself :(
-
They also mention casually memory sizes, but 3000T has only 500k of sample memory when doing 4ch+ digital normal mode (4 buffer-2 per ch-1 with digital -0.5 Mpts for ping pong buffers. 1Mpts for Single mode). Scope with 100Mpts will be 100x slower everything else being equal. Scope with 500MPts will have soo much more work to do.
You can keep pulling up the same "small memory" argument, except it is common for memory to change in different acquisition settings across most scopes. Those characteristics are not avoided in the Keysight data sheets or left as only up-to/maximum/peak values, and made very clear in the manuals (contrasting to these other examples discussed here where it is not clear at all what is expected).
But you make the false claim that there is a comparison with memory depth, the waveform capture measurements that competitors use keep the memory depth very short to inflate their numbers. Look at how much slower the competitors are despite choosing less memory! (when at same memory they are far behind). Scopes are not some computer system where the parts are put together in imbalanced ways by the end user, they are a finished product from the manufacturer who has decided on the system performance. Keysight make a real time scope with 100Mpts of memory, the EXR or MXR series, without a significant drop in waveform rate (keeping the system balanced).
Where you keep falling over is trying to make out like all scopes work/function the same. The Keysight megazoom method has been to decouple display and waveform memory, they are two different paths that dont interact. Acquisition data is piped to the display plotter/memory (through decimation etc) separately to the waveform memory. As you say before, to make things fast they chose to put most of the emphasis/features on the decimated view (positive example: fast eye diagrams). Most other scopes draw the waveforms from the acquisition memory, and take measurements from the original data (Lecroy being the extreme example of that, positive example: higher resolution measurements). Completely different with advantages and disadvantages, for comparisons they are best listed as characteristics rather than put as a good/bad binary check box against specific/your preference.
I'm not sure what I wrote was false.
Fact is that real time processing of 250 Mpts is harder than 4 MPts. Which, I agree with you, is no problem if you're sampling at such sample rate and timebase that all scopes take only 1000 samples..
I wasn't attacking anything and was not commenting OP specific results on this test but in general this old (you surely remember massive talk about this on previous many occasions) topic.
Keysight was always big on marketing this Wfms/s advantage (which is real) against other scopes from competition. Always pointing out that this is very important advantage of Megazoom IV to other scopes that don't have it, conveniently forgetting their own higher ends scopes also having 100 Wfms/s if they had same large memory as competition.
And thank you for pointing out that Keysight managed to make new gen of scopes that manage to have large memory and fast Wfms/s. Only problem is that those still barely achieve 200000 Wfms/s, same as lowly 1000X. And that despite massive processing power of high end scope with prices north of 20000 USD.. That shows you what price and performance is needed to make a 200 Mpts scope that will achieve high Wfms/s rates.
So in a range of prices of several thousands USD, compromises will exist. One extreme is 1 MWfms/s on KS 3000T with small memory. Other side is hundredths of MPts at slower update rate.
An it is not about sheer amount of data being processed. It is about architecture that changes with larger memories and high bandwidths needed.
Architecture can be more easily optimised if you have small memory. I suspect KS is using dual port memory architecture somewhere in side Megazoom IV to achieve simultaneous sampling in one buffer and rendering from another to achieve ping pong double buffering.. Or maybe hardware bank switching of memory pages onto two separate address/data spaces.. To achieve bandwidths needed, they use wide words and banks, and interleaving.
Bottom line small memory (full size small memory) allowed them to optimize architecture to fastest possible for fast acquisition in circular buffer/trigger/switch to other buffer/render in parallel.
FPGAs, as powerful as they are, are not as flexible as ASIC, where you can really draw up what you want (*).
That means that even with same sizes of data, Megazoom will be faster. It is optimized for that.
For instance, datapath on Megazoom IV is 8 bit. On SDS2000X+ is 16 bit, courtesy of 12+bit capable architecture.
Etc etc...
I'm not trying to pretend that all scopes function the same way. Quite the opposite. General population are thinking of them like they work the same way. They don't, and those types of comparisons end up being looked upon as comparisons which one is better, instead of which one is different and how. And how can you best utilize the tools they provide.
They each are best when used and considered in a specific way. These comparisons end up being perceived as some scoring competition, instead of nice resource for people to dig in to make their own decision based on good quality resource. I believe Rudy's original intention was exactly that.
And I try to explain that and you say the same, except I'm wrong... I think that sometimes you overestimate my English. Although I'm quite eloquent on occasion, it takes a lot of effort to find right words. It is hard to express what you think in foreign language, despite good command of it in general. False modesty on the side, I know my English is quite OK, but far from efortles or perfect.
In a short, I agree with your last paragraph (except first sentence), that is exactly what I try to say. You cannot simplistically compare these platforms based on few numbers taken out of context.
Honestly, I miss MSO5000 from Rigol in this. It would have been good to add it to what so far I see as very good and impartial research by Rudy. There have been quite a few discussions where there are no good info on real performance form real life MSO5000 users. I know there are quite a few of them out there, but maybe one or two contribute quality info.
(*) "I'm not bad. I'm just drawn that way." Jessica Rabbit
-
SDS
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and when I look segments time stamps they have all 3ms (3000us) delta time. So 333.33 segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33... segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)... still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc
Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.
Touchscreen Siglents indeed run Segmented capture in circular (forever as you say :-) mode if you start it in RUN mode. They will get one burst, and again and again with a slight pause in between. In order to get a single segmented burst you must press Single while in segmented mode..
-
Honestly, I miss MSO5000 from Rigol in this. It would have been good to add it to what so far I see as very good and impartial research by Rudy. There have been quite a few discussions where there are no good info on real performance form real life MSO5000 users. I know there are quite a few of them out there, but maybe one or two contribute quality info.
Thanks for the nice words. I have been thinking of buying a Rigol MSO5000 for this comparison. Buts it's quite an investment if I do so only for these videos. Also, this comparison plus its videos have proven to be quite time-consuming (surprise, surprise). I have some work trips and a sabbatical leave coming up (was offered a guest professor position in Tokyo for that leave, and I am not going to drag any test equipment along ;-) With less time, adding an extra scope means it would delay the completion of the series.
-
They also mention casually memory sizes, but 3000T has only 500k of sample memory when doing 4ch+ digital normal mode (4 buffer-2 per ch-1 with digital -0.5 Mpts for ping pong buffers. 1Mpts for Single mode). Scope with 100Mpts will be 100x slower everything else being equal. Scope with 500MPts will have soo much more work to do.
You can keep pulling up the same "small memory" argument, except it is common for memory to change in different acquisition settings across most scopes. Those characteristics are not avoided in the Keysight data sheets or left as only up-to/maximum/peak values, and made very clear in the manuals (contrasting to these other examples discussed here where it is not clear at all what is expected).
But you make the false claim that there is a comparison with memory depth, the waveform capture measurements that competitors use keep the memory depth very short to inflate their numbers. Look at how much slower the competitors are despite choosing less memory! (when at same memory they are far behind). Scopes are not some computer system where the parts are put together in imbalanced ways by the end user, they are a finished product from the manufacturer who has decided on the system performance. Keysight make a real time scope with 100Mpts of memory, the EXR or MXR series, without a significant drop in waveform rate (keeping the system balanced).
Where you keep falling over is trying to make out like all scopes work/function the same. The Keysight megazoom method has been to decouple display and waveform memory, they are two different paths that dont interact. Acquisition data is piped to the display plotter/memory (through decimation etc) separately to the waveform memory. As you say before, to make things fast they chose to put most of the emphasis/features on the decimated view (positive example: fast eye diagrams). Most other scopes draw the waveforms from the acquisition memory, and take measurements from the original data (Lecroy being the extreme example of that, positive example: higher resolution measurements). Completely different with advantages and disadvantages, for comparisons they are best listed as characteristics rather than put as a good/bad binary check box against specific/your preference.
I'm not sure what I wrote was false.
Fact is that real time processing of 250 Mpts is harder than 4 MPts.
Right there, the opening statement. You keep bringing it back to memory depth.
The main limitation of waveform update rate is the throughput of the plotter, the plotting rate of dots/vectors per second that is sometimes reported. By separating the acquisition memory and waveform plotter/display the Keysight megazoom IV continues fast realtime display with the full ADC rate out to 20GS/s in the higher end uses of it (with a proportionally slower waveform update rate from the higher sample rate). There is no compromising on waveform rate as the display window (and acquisition memory depth) gets larger, if they had more acquisition memory they wouldn't slow down at all, because the plotting keeps up at the highest ADC sample rates already. This is also why the intensity graded display doesn't show aliasing, it has data oversampled enough to produce the real time plotting. No trade off for memory depth vs update rate as they are largely independent.
That is a fundamentally different way of operating compared to other scopes, that buffer the acquisition as a continuous (often decimated/filtered) waveform and then turn that data into a waveform for display. Needing the waveform kept in memory while it is being processed for display, blocking further acquisitions, producing longer blind times.
Parallel vs Serial. Night vs Day.
-
SDS
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and when I look segments time stamps they have all 3ms (3000us) delta time. So 333.33 segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33... segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)... still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc
Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.
It was nice you rise this circular mode up.
Siglent do not have it (least yet afaik)
It works sequentially. (kind of burst)
It take one sequence (user defined n amount of segments in one fast *) sequence) and after this is ready, it processes all of these for display - stacking (overlay) them all, without interleaving together in one TFT image. And this take time, in some cases it may take really long time and during this it do not capture signal at all (just total blind). After then (in continuous mode) it start new squence. Trigger mode Normal (and also Autyo) mode is this repeating sequence mode and Single run just one single sequence and after all n seqments captured it stop and then processes all these for display n segments overlaid.
In some cases it may be useful if there is "circular" or this kind of continuous mode where it can capture as normal fast sequence mode but without user defined n, working just as circular buffer or fifo... how want think it. It capture segments until user or some signal stop it.
After then can look last captured segments (limited by total available memory and user defined seegment length). Only after stop it can display what is captured. (Siglent HW can not simultaneously handle displaying signal and run fast sequence mode capturing.) But this kind of mode is not implemented.
Is this kind of mode useful or not... and if, when.
*) fast mean that it can repeat trig "fast". (fastest trig interval 2us)
-
SDS
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and when I look segments time stamps they have all 3ms (3000us) delta time. So 333.33 segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33... segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)... still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc
Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.
It was nice you rise this circular mode up.
Siglent do not have it (least yet afaik)
AFAIK the history buffer should work thay way (although likely not with fast sequence mode).
-
It was nice you rise this circular mode up.
Siglent do not have it (least yet afaik)
I am not fully familiar with all these models, thanks for confirming how the Siglent handles it: burst - display - burst - display - etc
As I recall the Keysight 1100 and 1200 have a (speed crippled in the 1100) segmented buffer, that does not display them until you stop and manually request it. But it can be switched between circular and one shot. The run/single buttons are not used as the obvious controls for that, more confusions.
Would be interesting to hear more on what options and controls the R&S (optional?) segmented and history modes have, looks like more depth/options than the other two.
My favourite implementation of history/segmented memory is the Lecroy Wavejet 300 (oem: Iwatsu) it is a good balance of realtime update rate, and continuous "replay" segment history. Priced well above the comparisons considered here though.
-
SDS
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and when I look segments time stamps they have all 3ms (3000us) delta time. So 333.33 segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33... segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)... still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc
Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.
AFAIK the history buffer should work thay way (although likely not with fast sequence mode).
Looking at the manual, and getting the confirmation from rf-loop, the Siglent does not have any continuous mode. While the Keysight does not have any mode where it will do displays along the way. Quite different, orthogonal, and singular/forceful/narrow minded in their approaches!
-
Hello,
RBBVNL9 wrote:
"
"RTA behave little wilder."
Can you perhaps elaborate on what you mean here?
"
in RTB the blind time seems has always the same length just as the non blind time, so the picture looks almost periodic.
Different in RTA there has the blind time several length as the non blind time. It looks noway periodic.
Best regards
egonotto
-
SDS
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and when I look segments time stamps they have all 3ms (3000us) delta time. So 333.33 segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33... segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)... still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc
Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.
It was nice you rise this circular mode up.
Siglent do not have it (least yet afaik)
AFAIK the history buffer should work thay way (although likely not with fast sequence mode).
Yes it works as continuous FIFO (always bacround). When stop there is always last segments available.
But even when it (SDS1kX-E) may have up to >100kwfm/s (ksegment/s) average speed in second! (1 channel on, 50ns/div and display mode dots, measurements off).
This mode quaranteed speed is extremely slow. So if it is important to be sure it do not drop out any single trig event... example with SDS1104X-E if measurements off theree can be 3.5ms pause. So quaranteed speed may example 280wfm/s (segment/s) and with measurements on example 24ms pause (with average speed example around ~70kwfm/s) means quaranteed speed around 40wfm/s.
Many times in segmented mode we need some quarenteed speed to be sure any trig event is not dropped out. If this is not important then of course this mode can use as continuous segment mode (fifo mode) and after stop last segments are in buffer and every segment can analyze.
-
SDS
- Record length (parameter “MAX record length”) setting is 20k. Interestingly, any other setting (200k, 2M, 20M, 200M) does not make any difference for this measurement
- Sample rate is 10.0 MSa/s (this number changes when other record lengths are selected)
- “Acqu Mode” set to “Fast”. Interestingly, changing it to “Slow” does not make any difference for this measurement
- “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS 100ms in between, so a considerable drop in the number of trigger events per second.
- Display Type = Vectors. But setting it to dots makes no difference whatsoever.
- Only Channel 1 activated.
I was able to reproduce this, but there's a caveat that I'll explain below. My suspicion is that you set the final memory depth after you set your timebase and that your initial memory depth was at least 20M. From what I've seen it makes all the difference in the world.
Once you have your acquisition settings finalized, change the timebase and the settings will "take". Sometimes that's not necessary, while other times it is (with the timebase set as you have, going from 20M or 200M to anything less than 20M will necessitate a twiddle of the timebase to get the new waveform update rate to take hold).
With the timebase set as you have (200 us/div), with a 1 kHz waveform, here's what I get for trigger output frequency (average), which presumably is a representation of the internal waveform update rate:
| Points | Samples/sec | Frequency (avg) |
| ------ | -------------- | ------------------ |
| 20k | 10M | 333 |
| 200k | 100M | 300 |
| 2M | 1G | 153 |
| 20M (actual: 4M) | 2G | 30 |
| 200M (actual: 4M) | 2G | 30 |
If I start with maximum memory depth, set up the timebase and volts/div, I get 30 Hz as described above. If I then set my memory depth to 200k, it will stay at 30 Hz until I twiddle the timebase. Twiddling other settings (including things like hitting the "normal" trigger button again) makes no difference. Only the timebase seems to actually cause the update rate to change under these conditions.
-
@ kcbrown,
Thanks a lot for replicating this, leading to what seems to be a quite important finding!
So it seems a change in memory depth setting (and hence sample rate) only takes effect if the user afterwards changes the timebase settings... That would be strange and non-intuitive behaviour from the user's point of view, but it would certainly explain a lot about the low (re-)trigger rate we were observing.
Hope to have some time tonight to test this myself, and also find out what this means for the poor visual observation of infrequent glitches (which I talked about in my video episode 7 at 47:27) and the ability to observe mask failures (for which I have some preliminary measurements mentioned in the comparison document V61 on page 33).
So, thanks again! Excellent work!
. rudi
-
@ kcbrown,
Thanks a lot for replicating this, leading to what seems to be a quite important finding!
So it seems a change in memory depth setting (and hence sample rate) only takes effect if the user afterwards changes the timebase settings...
Not necessarily. Going from a smaller memory depth to a larger memory depth seems to make the new setting have an immediate effect on the waveform update rate (which might be a small change, as it was when going from 20k to 200k). I haven't tested other timebases and, thus, other maximum capture lengths. It may be that the issue only happens when the capture size you're going from is limited by the maximum sample rate versus the screen width in time, as it is with 20M and 200M at 200 us/div (which limit the capture size to 4M). So a bit more testing is needed to fully characterize this.
I do think it's safe to say, though, that if you change the memory depth, then changing the timebase will make the new setting have the appropriate effect on the waveform update rate if that effect hasn't already taken place.
So, thanks again! Excellent work!
. rudi
You are most welcome!
-
As has been mentioned before, the trigger engine in the SDS2000X Plus is not working properly.
That it fails to apply changes in max. record length without a detour (nice finding, @kcbrown!) might add to the problems, but it's certainly not the only one.
I did a test with the yet unreleased sibling of the SDS2000X Plus, the new 12 bit SDS2000X HD, since it doesn't seem to have a comparable bug.
The max. record length is important. We need to limit it to 200kPts to get 333 wfms/s peak (325.86 average). At 2 Mpts the average rate is about 180 Wfms/s and at 4 Mpts it is around 100 Wfms/s. So this sounds as if it is faster than the RTB, just as was to be expected from the technical data. display mode dots or vectors doesn't make a difference, the same is true for x or sin(x)/x of course.
In general, dots mode is only effective at timebase settings faster than 50 ns/div, where any interpolation errors such as Gibbs ears can be avoided and the wavform update-rate sped up at the same time.
See attached two screenshots:
SDS2504X HD_Signal_Square_1kHz_Mem200k
This is the test signal, a ~1kHz square wave on the SDS2000X HD. Vector Mode, Sin(x)/x, "Fast" Acquisition. We certainly won't get more than 30 Wfms/s in "Slow" mode.
Trig_Out_1kHz_Mem200k
This is the Aux Out (triggger out) signal, monitored by another scope with the counter application including statistics.
-
Performa01, thanks for the input.
That it fails to apply changes in max. record length without a detour (nice finding, @kcbrown!) might add to the problems, but it's certainly not the only one.
Can you explain exactly what you believe these other problems are with the SDS2000X+ in terms of its trigger engine?
Thanks!
-
Dear all,
A new episode is ready on the comparison series, now on Bode Analysis. On paper, the Siglent SDS2000X Plus has the best cards of our three instruments. Is this true?
(Spoiler: yes, but you need to be very patent, and the specs don’t tell you the full story…)
The updated comparison document is available here (https://github.com/RudisElectronicsLab/RTB_SDS_DSOX_review/blob/main/v67%20RTB%20SDS%20DSOX%20Functional%20Comparison.pdf).
YouTube video (https://www.youtube.com/watch?v=qlJPiJpY6oQ)
-
Performa01, thanks for the input.
That it fails to apply changes in max. record length without a detour (nice finding, @kcbrown!) might add to the problems, but it's certainly not the only one.
Can you explain exactly what you believe these other problems are with the SDS2000X+ in terms of its trigger engine?
Thanks!
Sorry for the late reply...
See reply #3274 in thie thread below:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4061779/#msg4061779 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4061779/#msg4061779)
Topics 3 an 4 in that post might not be valid though, as I only saw them once after a FW-update and wasn't able to reproduce it after a reboot.
-
Dear all,
A new episode is ready on the comparison series, now on Bode Analysis. On paper, the Siglent SDS2000X Plus has the best cards of our three instruments. Is this true?
(Spoiler: yes, but you need to be very patent, and the specs don’t tell you the full story…)
The updated comparison document is available here (https://github.com/RudisElectronicsLab/RTB_SDS_DSOX_review/blob/main/v67%20RTB%20SDS%20DSOX%20Functional%20Comparison.pdf).
Thanks for that episode, nicely done!
A few remarks:
- The Bode Plot in the Siglent is slow, especially at low frequencies. There might be reasons for this, like frequency selective detector and averaging for precise measurement results even at very low input signal levels in high dynamic range measurements.
- Your simple tests did not reveal anything about the dynamic range of the measurements, where I expect the up to 120 dB dynamic to be another significant advantage for the Siglent. And it's mainly the dynamic range that makes up for a useful analysis tool in this area.
- Your complaint about not being able to set fine steps for the amplitude axis has aready been addressed in the SDS2000X HD and will be available in the next SDS2000X Plus firmware. We can now set the scale in 1 dB increments.
- Your complaint about not being able to have a look at the time domain view has aready been addressed in the SDS2000X HD and will be available in the next SDS2000X Plus firmware.
-
@Performa
This time you were faster.. :-DD
Just to add, if you watch triggering lights on Siglent at very low frequencies, you will see it takes 5 measurements and than averages that data point. Like Performa said, it uses frequency selective algorithm, and together with averaging, it will have much improved software gain and it will be resilient to outside interference. That makes it have very good dynamic range and more robust if you are not working in a Faraday cage.
-
Thanks for the replies and compliments.
The Bode Plot in the Siglent is slow, especially at low frequencies.
Like Performa said, it uses frequency selective algorithm,
I djust did some more tests and I can confirm the speed is frequency dependent indeed (and will update the future comparison document):
[attachimg=1]
That makes it have very good dynamic range and more robust if you are not working in a Faraday cage.
Great, but I would have wished that the user could choose to have such strategies in place or not. In my test case (and I think in many user's test cases) a Faraday cage neither special strategies to deal with very low signals or wide dynamic range are needed. Unless such special situations apply, I would rather like the instrument to be more responsive.
Your complaint about not being able to set fine steps for the amplitude axis has aready been addressed in the SDS2000X HD and will be available in the next SDS2000X Plus firmware. We can now set the scale in 1 dB increments.
Good to know. I don't own that HD scope, but once the firmware update for the SDS2000X Plus is out that fixes this and I have been able to test it, I'm happy to update my comparison document!
Your complaint about not being able to have a look at the time domain view has aready been addressed in the SDS2000X HD and will be available in the next SDS2000X Plus firmware.
Same as above!
-
Thanks for the replies and compliments.
The Bode Plot in the Siglent is slow, especially at low frequencies.
Like Performa said, it uses frequency selective algorithm,
I djust did some more tests and I can confirm the speed is frequency dependent indeed (and will update the future comparison document):
[attachimg=1]
That makes it have very good dynamic range and more robust if you are not working in a Faraday cage.
Great, but I would have wished that the user could choose to have such strategies in place or not. In my test case (and I think in many user's test cases) a Faraday cage neither special strategies to deal with very low signals or wide dynamic range are needed. Unless such special situations apply, I would rather like the instrument to be more responsive.
Your complaint about not being able to set fine steps for the amplitude axis has aready been addressed in the SDS2000X HD and will be available in the next SDS2000X Plus firmware. We can now set the scale in 1 dB increments.
Good to know. I don't own that HD scope, but once the firmware update for the SDS2000X Plus is out that fixes this and I have been able to test it, I'm happy to update my comparison document!
Your complaint about not being able to have a look at the time domain view has aready been addressed in the SDS2000X HD and will be available in the next SDS2000X Plus firmware.
Same as above!
In your table there is no information if Siglent was tested using automatic level control (ALC), on or Off (In Siglent "language" it is: Channel Gain: Auto or Manual)
It affect to speed some amount. Naturally because when ALC os ON, after every single frequency step it need check signal level. It is capable to adjust full dynamic range and independently for every channel in use, what is from noise level to max, around -100dBm to 42dBm // -113dBV to 29dBV. Step from minimum to maximum can happen in every single frequency step.
Naturally if use manual, then user need first find max level so that set channels V/div so that signal stay enough under clipping level.
If need test circuits where do not need high dynamic range least I use mostly Manual. Example if 50ohm system and 0dBm is max level. Just 100mV/div and there is still over 60dB dynamic range down from this 0dBm. Even more, depending how much we accept noise affect/reduce level accuracy. With 100mV/div 50ohm BodePlot noise level is somewhere below -80dBm (depending frequency)
If you put these equipments to bit more challenging tests it can tell much more. If compare just using simplest possible tests all can do these simple kind of RC filter class tests if need tell students what is BodePlot. Or just how fast it can plot.
Here some tiny and simple examples.
First one is simplest RC. There is cascaded LPF and HPF. CH3 after HPF and CH2 and 4 bit different position near final. All can do this. (except only Siglent 3 channels simultaneously. But dynamic range is still very easy)
(https://siglent.fi/pic/BodePlotYl/3ch-nodata-2k-ScreenImg%20(19).png)
Then next one is perhaps bit more challenging least to some of oscilloscopes what have BodePlot (or Freq. Response Analyzer or Control Loop Response Analyzer)
In this next image below. Playing with attenuator as DUT. Signal to DUT is 0dBm. As can see when attenuator is 0dB it is. Then attenuator down to 100dB and Result is -100dBm.
As can see frequency here was around 455kHz for look dynamic range if measure and characterize example typical 2nd or 3rd IF filters in some analog receiver. 100dB dynamic down from 0dBm is not at all bad when we talk just basic level oscilloscope.
As can see there is also one channel open for display just noise level. (also note explanations below image)
(https://siglent.fi/pic/SDS2000XPlus/test-images/bodeplot/wdr-2000Xplus-BP--455k_steps-dBm.png)
(in this image I do not remember at all what was FW version but far below today versions)
NOTE: In this time when I did this I have big troubles with attenuator control signals so it is as it is... and after then never made repeat using adjustable good HP step atten.
But, I know this attenuator steps have less than +/-0.5dB error 0 to 80dB and less than +/- 1dB >80 to 110dB.
And now if there is filter as DUT what have stop band attenuation -100dB then result is same...
This level range marked as A and B in picture contain full FRA 140dB dynamic range. But naturally with internal 50ohm can not. Then need external load. (this may happen if example DUT have also amplification. With Passive DUT and Siglent generaton, full dynamic range is of course more low because max output level)
Then this next. This is made using SDS2000X HD but it do not matter here "anything". Because resolution is resolution and it do not directly affect dynamic range itself. HD model noise level is tiny bit better than 2kX+ but if we look whole dynamic range this difference is nearly nonsense in this case. (So, afaik, SDS2kX+ can easy do this same)
Here is tested 84.050kHz high quality vacuum tube type quarz resonator. As can see even Siglent FRA frequency resolution is just borderline or better say not enough (look this fs and fp points level difference... f resolution for fp peak is clearly/barely just enough but for fs there is not enough frequency resolution so it is just one step and now it depends if this step frequency is just perfect or 0.5Hz off what may do big difference in level.
Other channels (2 and 3) are just for give imagination of noise level. And there can see also crosss talk. As can see when CH4 level is most high (resonator highest peak) also it can see over CH2 and 3 noise level (>10dB peak). Still over 120dB distance.
(https://siglent.fi/pic/SDS2000XHD/FRA/FRA-Example-84kHz-resonator.png)
I do not know how are these others but least Siglent is based fully to primary data table what it produce doing sweep. (if select data table to display this is only reduced version from primary table) Bode traces display is only graphic "window" to this primary data table. If data is outside of display window when it sweep, it do not matter anything, result go still to primary table (just move/change your "window" vertical pos and scale to see it.) Sad it can do only this in vertically, not horizontally (not pan and zoom horizontally). It is not "display plotter" is is database plotter. Then you adjust your display window how you want. (exept if you want use this "blond" method Auto adjust). Also internal data table(s) have full resolution (not truncated or rounded as in visible table). This primary table can take out example using .CSV format. (also it can read back to scope for later look again with B.)
Also, Siglent make possible to use external Siglent generators what give lot of more features. Example test circuits what convert frequency. (DUT in and out frequencies are different). In some of this kind of cases it is very important to listen and measure wanted frequency and not example mirror freq. So freq selectivity may have also other aspects than just reduce "noise" etc.. Some simplest BodeToy machines may measure even what ever... just wide band amplitude what may include all dirties and mess. Also using dual channel generator for FRA make possible to use different levels for reference channel and DUT inputs, for example reduce oscilloscope channels internal cross talk effect when DUT in level is high but DUT out level is very very low... example with high quality IF filters stop band levels or specially if filters are higher freq where cross talk may be much more problem.
But, still also I hope Siglent can later implement "fast mode" for simplest circuits Bode just for fast sweep some RC filter where do not need anything but find signal level and phase just without any more sophisticated things. Just like we old time did "Bode" with sweeper, scope and detector (or even logamp/detector because with linear scale reading from scope screen is... totally poor.).
(eta: corrected some most bad typing errs)
-
Dear RFloop,
In your table there is no information if Siglent was tested using automatic level control (ALC), on or Off (In Siglent "language" it is: Channel Gain: Auto or Manual)
Quick answer: on all three scopes, automatic level control was used during my speed tests. Will add that to the table. In fact, for the RTB and the DSOX, this mode is always on (see my overview document). On the RTB and the SDS screen, one can see the actual gain selected at any moment for the scope channels. With the DSOX, that is not visible when running the analysis.
-
Hi Rudi -- thanks for the very nice video! A couple of additional points about Bode plots on the RTB:
1) Horizontal scaling of the gain and phase is possible: you can use the horizontal rotary knobs, start and stop frequency, or "pinch" gestures to scale the results horizontally.
2) You can also use the Autoset key to scale the Bode plot automatically
3) HiRes mode is switched on during Bode plot measurements, and this provides up to 16-bit resolution
Again, many thanks! Looking forward to the next video.
-
Just watched the new episode, I would like to know how they perform when encountering a phase shift beyond +-180°. The Keysight 1102g has this thing where it can't determine if the phase is + or - 180° so you see jumps like this when it crosses either point, could you test for this on the 1204g and the others? thank you!
-
@pdenisowski
Thanks, Paul, thanks for the compliments. Just did one more test prompted by your message and I indeed do now see how the horizontal scale can be edited after the measurements are done (your point 1) - will add it to the overview table. The topic of resolution/dynamic range for Bode plots is a complex one. For each new measurement, the instrument may reconsider the appropriate channel gain for the measurement, so it is not only dependent on the resolution of the ADC or other related measures (like averaging) but also the ability to jump to the right channel gain, and the highest available channel gain (and its noise floor). So the dynamic range may be more than 8, 10 or even 16 bit would allow for, but how much, depends on other factors.
Topic of next video is not yet decided but it might well be ... FFT
-
Just watched the new episode, I would like to know how they perform when encountering a phase shift beyond +-180°. The Keysight 1102g has this thing where it can't determine if the phase is + or - 180° so you see jumps like this when it crosses either point, could you test for this on the 1204g and the others? thank you!
Thanks. I recall that the RTB allows you to set the way it 'jumps' when large phase shifts occur. Time permitting I will do the test you asked for - let me see of I have a nice DUT lying around that makes such shifts.
-
...
Topic of next video is not yet decided but it might well be ... FFT
Ooh! perhaps you might want to cover this if you do FFT next(or anyone else might know what's going on in here?). I'm not sure if this is a thing with just my unit, or if it's a thing with the model, or if it's different between the 1102 and 1204 series, but I found that when doing FFT at slower timebases for higher RBW, at certain timebases the FFT would just cut off on the right, and the resolution would show up as higher, and then if you move it to either faster or slower timebases, it would expand again and show lower resolution, all this within the 2GSa/s limit of 20µs/. So i find this very strange that if sampling rate isn't changing, the FFT is still cutting off :scared:
In the screenshots you can see how going from 18µs/ to 18.4 the FFT resolution seems to increase but it chops off the right side, and then changing from 18.4µs/ to 19.2 it comes back, but the resolution seems to go down again.
-
On request, I have decided to do the FFT episode as the next one in the series. It's quite an extensive topic to cover, resulting in a mammoth video… But I have provided extensive TOC (so you can jump to what you want to see), and I’m sure there are new insights things to be discovered by everyone, also the most seasoned users of these oscilloscopes!
Once again, the comparison document is updated (now 54 pages, 267 footnotes, quite some detail….).
Enjoy!
Rudi
https://www.youtube.com/watch?v=ss3-DVap6zA (https://www.youtube.com/watch?v=ss3-DVap6zA)
-
On request, I have decided to do the FFT episode as the next one in the series. It's quite an extensive topic to cover, resulting in a mammoth video… But I have provided extensive TOC (so you can jump to what you want to see), and I’m sure there are new insights things to be discovered by everyone, also the most seasoned users of these oscilloscopes!
Once again, the comparison document is updated (now 54 pages, 267 footnotes, quite some detail….).
Enjoy!
Rudi
Hello Rudi.
I must say that I didn't have time to watch your quite lengthy video in details..
Quite frankly, I don't really agree with some of methodology, and there are some omissions that I caught by only cursory watching..
Let's just touch on some of those, without particular order.
RBW is resolution bandwidth, not realtime bandwidth. You confused them when talking about R&S.
First, there is no RBW in FFT, really. With FFT we talk about frequency bin size (or bin width, or bin spacing). RTB doesn't have regular FFT implementation. What they have is kind of simplified version of spectrum mode from it's "bigger" brethren..
It is nor proper spectrum mode, nor propper FFT. That makes it easier to use because it speaks of RBW (while I don't know if they are really calculating proper spectrum plot with recalculated bins to RBW and amplitude and scalloping loss and frequency leakage corrections in accordance with used FFT window etc..) and other parlance like you are using SA.. I presume R&S did it right ( because they should know how it's done) but I don't understand how it is implemented.
FFT is more basic mathematical transformation than full SA implementation. R&S implementation gets you quicker something on the screen, but if you are doing something where FFT needs to be set exactly in some way, R&S is not good for that.
It depends on usage, I guess.
Fact that FFT in RTB2000 takes over control of the scope is annoying as hell to me, personally..
On SDS2000X+, sort peaks (frequency/amplitude) is applied to TABLE view. Peaks markers are always enumerated from left to right in increasing number order.
Noise floor comparisons are valid only if you have exactly same number of data points, time interval bins, averaging and same windowing. Otherwise they will differ..
On SDG2000 (or 6000) you don't need to press amplitude for few seconds to get dBm. If you have it set for 50 Ohm, you simply start typing number 0 and press dBm like you did..
I will look at the video in more detail later.. It is kinda busy these days...
Please don't take this as offense. The topic is quite complicated and it is very involved to create representative presentation.. It is obvious a lot of work is put in it. Minor errors are understandable..
Best
Sinisa
-
Sinisa, thanks for the detailed feedback. Seems you looked at the video more than just cursory (or you’re a very efficient watcher ;-)
Let me react to a couple of things you bring up. Firstly:
Please don't take this as offense. The topic is quite complicated and it is very involved to create representative presentation.. It is obvious a lot of work is put in it. Minor errors are understandable..
Thanks for noting this. I have benefited a lot from reviews of others when choosing or using measurement instruments, and with this series, I hope to contribute myself to the community. But – needless to say – there inevitably will be mistakes, omissions, and perhaps misunderstandings. Especially on a topic as complex as FFT.
First, there is no RBW in FFT, really
Concerning the use of the term RBW, I guess it’s a bit of a matter of terminology… While there is some divergence in the use of this term, Rohde & Schwarz is certainly not the only one using the term RBW in the context of FFT/DFT. Some examples:
- National Instruments (NI) explains the term as follows: “The resolution bandwidth (RBW) determines the fast-Fourier transform (FFT) bin size, or the smallest frequency that can be resolved.” (source (https://www.ni.com/docs/en-US/bundle/ni-rfsa-21.0-help/page/nirfsa/resolution-bandwidth.html)).
- Tektronix writes: “On traditional SAs, the IF filter bandwidth determines the ability to resolve adjacent signals and is also called the resolution bandwidth (RBW). For example, in order to resolve two signals of equal amplitude and 100 kHz apart in frequency, RBW needs to be less than 100 kHz. For spectrum analyzers based on the DFT technique, the RBW is inversely proportional to the acquisition time. Given the same sampling frequency, more samples are required to achieve a smaller RBW. In addition, windowing also affects the RBW.” ( source (https://download.tek.com/document/37W_17249_5_HR_Letter.pdf)).
- I also see RBW shown on the screen of some other brands of scopes with FFT, such as the GW INSTEK MDO-2000E (screenshot here (https://www.gwinstek.com/en-global/2019_EDM/index/20190606)).
But there is divergence indeed. The SDS shows an “∆f” value, and the DSOX shows an “FFT Resolution” value on the screen... I have been under the impression that all of these basically refer to the same thing, but correct me if I’m wrong… This is what the oscilloscope manuals have to say:
- RTB: “The resolution bandwidth (RBW) determines the resolution of the spectrum, that is: the minimum distance between two distinguishable peaks. The higher the resolution (the smaller the ratio), the more peaks are detected, but the longer the measurement requires to finish.”
- SDS: “Frequency interval (△f): The frequency interval between two adjacent points in the FFT sequence, which is proportional to the frequency resolution.” (Note: I have to think about this ‘proportional….’. The same? With some factor?)
- DSOX: “The FFT resolution is the quotient of the sampling rate and the number of FFT points (fS/N). With a fixed number of FFT points (up to 65,536), the lower the sampling rate, the better the resolution.”
RBW is resolution bandwidth, not realtime bandwidth.
Indeed, during the recordings, I accidentally said ‘real-time bandwidth’ instead of ‘resolution bandwidth’; I thought I corrected that (I did so at 2:01:47, for instance), but I must have overlooked one or more. My bad.
RTB doesn't have regular FFT implementation. What they have is kind of simplified version of spectrum mode from it's "bigger" brethren..
I don't think I came across this before. Do you have any sources or further information? Trying to look this up, I came across a video (https://www.youtube.com/watch?v=xOlxuHWT1og) of how R&S implemented FFT in the RTO oscilloscopes (including downconverting and overlapping blocks), but I have no idea this is also the implementation used in the RTB. There does not seem much to find on this on the internet.
Fact that FFT in RTB2000 takes over control of the scope is annoying as hell to me, personally.
Yes, I see your view. In a FAQ (https://www.rohde-schwarz.com/hk/faq/rtb-rtm-rta-changing-the-timebase-with-active-fft-faq_78704-1185567.html), R&S writes “The timebase is adapted automatically when the frequency parameters of the FFT are changed. This is done to archieve optimized results. You can change the timebase in indirect way, if you change the span. Increase the span --> the timebase becomes faster Decrease the span --> the timebase becomes slower” But this may not be as much flexibility as you wish, as you may want to determine your span on other grounds. You do have the possibility to set the time gate (= extract of the timebase for which the FFT is calculate) on the RTB with the Width and Position parameters. Do play with that! But having that said, indeed, you cannot set time base, sample rate and memory depth yourself as in other instruments.
On SDG2000 (or 6000) you don't need to press amplitude for few seconds to get dBm. If you have it set for 50 Ohm, you simply start typing number 0 and press dBm like you did..
That is true. But I use the method shown in my video because I like to see first what the current setting in dBm is, before I change it into another dBm value… Matter of preferences, I guess.
I am not exactly sure what you mean to say. If it ‘sort on peaks’ does not sort the table, then what does it do? On my device, I see no difference whether I select “Sort to @@” or “Sort to peaks” I get the same table, same marker numbering, etc.
On SDS2000X+, sort peaks (frequency/amplitude) is applied to TABLE view. Peaks markers are always enumerated from left to right in increasing number order.
I looked at it again, and… now I see your point. The “sort by” does not sort the numbers give to the peak markers, but the order in which they are shown in the table. Not sure why I did not see that before.
But the fact the SDS manual says "Sort peaks by amplitude or frequency" instead of "Sorts the table by amplitude or frequency" does not help, though.
Noise floor comparisons are valid only if you have exactly same number of data points, time interval bins, averaging and same windowing. Otherwise they will differ..
Yes, and that is exactly why I added the section starting at 2:01:15 to the video. To point out that all these parameters do matter and affect the outcomes. Since it is impossible to set all devices to exactly the same settings, for most tests I did, I tried to take a users’ perspective and find the best settings I could achieve for each device (and when I do this best-achieved results approach, I say it in the video). For the speed test, however, I tried to test with settings that were as close as possible (and I mention this also in the video).
Again, thanks for the feedback,
Best, Rudi
-
For the FFT math, the correct term for the frequency spacing is "bin-width". For a 1 Mpts FFT at 1 GSa/s, if you have a mega (1048576) bins, each of them is 953,67 Hz wide.
The effective Resolution Bandwidth (RBW) is closely related to the bin-width, but not identical. There is a factor involved, depending on the window function in use.
In theory, that factor ranges from 0.89 (Rectangle) up to 2.94 (Flattop), yet when I last measured it, the Flattop window in some Siglent DSO required a factor of 3.8 to determine the true -3 dB bandwidth. Rectangle window is to be avoided except some very special applications like short transients, whereas Flattop is the most accurate window function that is universally used in spectrum analyzers.
-
For the FFT math, the correct term for the frequency spacing is "bin-width". For a 1 Mpts FFT at 1 GSa/s, if you have a mega (1048576) bins, each of them is 953,67 Hz wide.
The effective Resolution Bandwidth (RBW) is closely related to the bin-width, but not identical. There is a factor involved, depending on the window function in use.
In theory, that factor ranges from 0.89 (Rectangle) up to 2.94 (Flattop), yet when I last measured it, the Flattop window in some Siglent DSO required a factor of 3.8 to determine the true -3 dB bandwidth. Rectangle window is to be avoided except some very special applications like short transients, whereas Flattop is the most accurate window function that is universally used in spectrum analyzers.
Just measured 2000X HD.
Using center f ~800kHz (freq. fine adjusted to nearest bin)
Flattop window.
FFT ∆f 5.96Hz (FFT 2.5MSa/s, 2Mpts)
-3dB Bandwidth (=RBW) 21.2Hz and width at -60dBc 54Hz. (shape factor ~2.55)
(Using 200Hz span, I have measured from linear interpolated lines between bin points (just as FFT draw it))
In this case Flat top window responds RBW 3.56 x FFT ∆f
(example Tektronix tell FlatTop window factor is 3.77)
-
On request, I have decided to do the FFT episode as the next one in the series.
Hi Rudi - Very nice video! Thanks for making these.
With regards to the RTB and FFT, two small points:
1) You can change the horizontal scaling of the spectrum using the horizontal knob
2) Autoset sets both the channel parameters and the FFT parameters
Thanks again!
-
Performa-01, rf-loop,
Very valuable contributions, thank you. They help to understand the difference between the parameters the devices show.
With some visual comparison with a 800kHz sine wave as input and a Flat Top window, I indeed see when the RTB is set to 209 Hz, the width of lobe (using cursors) is approximately the same as the lobe on the SDS with FFT ∆f equal to 76 Hz. That would indeed be in line with a factor of approx. 3.5, as you both explain. The DSOX is the same as the SDS in this respect.
So, my conclusion in terms of the values these devices show on their screens, would be:
- RTB shows (and allows to set) the RBW, which, when using a Flat Top window, is approximately 3.5 times the FFT frequency spacing (a.k.a. the "bin-width").
- SDS shows (as a result of the other settings) the “Frequency interval (△f)” which is the same as the FFT frequency spacing (a.k.a. the "bin-width").
- DSOX shows (as a result of the other settings) the “FFT resolution”, which is, like the SDS, the same as the FFT frequency spacing (a.k.a. the "bin-width").
-
dear pdenisowski,
1) You can change the horizontal scaling of the spectrum using the horizontal knob
2) Autoset sets both the channel parameters and the FFT parameters
Thanks!
I think I had (1) already covered in my video.
Concerning (2), yes, that is interesting, had not realised it. It is not mentioned in the FFT chapter of the RTB manual, though, and only quite limited in the manual's general section (page 51). So this feature could be highlighted a bit more in the manual!
-
I also see RBW shown on the screen of some other brands of scopes with FFT, such as the GW INSTEK MDO-2000E (screenshot here (https://www.gwinstek.com/en-global/2019_EDM/index/20190606)).
Actually that is a spectrum analysis mode. Basically you can divide oscilloscopes in two categories:
1) ones that offer plain FFT and depending on time/div you get a certain bin width (frequency resolution)
2) ones that offer a spectrum analyser-ish interface that optimises time/div and other parameters based on a requested frequency resolution
BTW: The GW Instek 2000E series can do both; there is an FFT mode and spectrum analysis mode (the latter may need some magic using a key generator to enable it on non-MDO versions).
IMHO having a spectrum analyser style interface on top of FFT makes it easier to use. Gettting FFT to do what you want can be tedious while a spectrum analyser interface allows you to go from what you want and let the oscilloscope sort out which settings to use.
-
For my RTB, I am doing the calculations as posted above by Performa01 and rf-loop, but I’m not getting what I would expect. Probably I’m doing something wrong; I'm sure someone can help me.
If I feed the RTB with an 800kHz sine, set its FFT to 8kHz centre and 200kHz span. The RTB has 128k FFT points (RTB2004 product brochure V06.00). The scope reports it runs at 2.27MSa/s. If I get Performa01’s calculations right, that means bins of 17.7Hz (*). Using a Flat Top window, I’d expect (on the basis of Performa01 and rf-loop’s posts above) an RBW that is about 3.73 times larger, which would be 66.1Hz. And, indeed, I can set my RTB to a minimal RWB of 66.6Hz, close enough, so all seems right. So far.
Now choosing a Hanning window. The scope still reports it runs at 2.27MSa/s, so the bin size should remain unchanged 17.7Hz, but the window-specific factor for Hanning is around 1.62 (source (https://www.eevblog.com/forum/testgear/rohde-schwarz-rtb2002-vs-siglent-sds2104x-plus/msg3239832/#msg3239832)), so I’d expect an improved RWB of 17.7Hz*1.62=28.7Hz. But, to my surprise, when I try to set the RBW on the scope, the minimum I can set it to is 119Hz (so it's larger instead of smaller than in the Flat Top window scenario). I tried several other scenarios (8kHz sine, 8MHz sine, different span settings), but the results are always different by the same degree. I’m attaching the calculations.
The only possibility that comes to my mind is that the RTB FFT points is not fixed at 128k, but can go to lower values depending on the settings (the window used) and, in the above Hamming window example, would have dropped to simewhere in the range of 32k. But that is pure speculation, I guess it's more likely I am making a mistake in the above. Anyone?
(*) I did those bin size calculations as well for the SDS and they are always exactly as expected.
-
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.
-
For my RTB, I am doing the calculations as posted above by Performa01 and rf-loop, but I’m not getting what I would expect. Probably I’m doing something wrong; I'm sure someone can help me.
I have no idea what's going wrong here, but a few general remarks.
Never forget that there can be two different sample rates: the first one is the sample rate of the scope that depends on its maximum record length, the second one is the FFT sample rate, that depends on the FFT length hence might be further decimated. 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. I just mention this for completeness as this obviously isn't your problem right now.
The only other thing I can think of is the beauty of the sprectrum analyzer mode, which not only makes things easier for the inexperienced, but might also do some funny and unexpected things behind your back. Such as Keysight who prove unable to provide a valid averaging, but do some additional HiRes unexpectedly and claim it's because they think the users want to reduce noise anyway. (The truth is, that the tiny secondary buffer of just 64 kpts forces decimation and they need to use HiRes in order to avoid aliasing.) I cannot know, but since the FFT in the RTB appears to be somewhat limited in certain regards, you cannot rule out some unexpected tricks behind the scenes to overcome certain limitations.
-
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.
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...
Never forget that there can be two different dample rates:
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.
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.
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.
-
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.
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.
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.
-
Peter,
The number of FFT samples is displayed in the Acquire/Acquisition Menu under Record Length.
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.
-
... Maybe I should go even higher, to find out whether indeed FFT point size varies depending on settings...
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.
-
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....
-
"Remember, only when everyone is starting at the same time, a comparison of the times makes sense."
(J.Malmsheimer)
-
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 (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.
-
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 (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.
-
Dear Performa01,
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 ;-)
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.
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).
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.)
-
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).
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 ;)
-
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...
Video (https://www.youtube.com/watch?v=wqLEqJSq4AA)
-
Hello,
Thank you, a little help for the use of the bibliography:
https://micronix-jp.com/english/note/application/fundamentals_of_speana_2.html (https://micronix-jp.com/english/note/application/fundamentals_of_speana_2.html)
https://www.techplayon.com/spectrum-analyzer/ (https://www.techplayon.com/spectrum-analyzer/)
https://devincody.github.io/Blog/post/an_intuitive_interpretation_of_the_fourier_transform/ (https://devincody.github.io/Blog/post/an_intuitive_interpretation_of_the_fourier_transform/)
http://en.ppt-online.org/269835 (http://en.ppt-online.org/269835)
https://download.tek.com/document/37W_17249_5_HR_Letter.pdf (https://download.tek.com/document/37W_17249_5_HR_Letter.pdf)
Best regards
egonotto
-
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.
-
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...
-
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 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4312450/#msg4312450)
-
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!
-
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 ?!?
-
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;
-
Dear 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.
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)
-
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.
-
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.
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 (https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/RTB2000_bro_en_3607-4270-12_v0700.pdf) or here (https://www.testequipmenthq.com/datasheets/Rohde-Schwarz-RTB2004-Datasheet.pdf)).
[attachimg=1]
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...
-
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.
-
>> 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.
-
>> 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...
-
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.
-
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…
-
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.
-
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?
-
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%
-
Thanks, so this scope can average quite fast! But the maximum number of averages is a little limited.
-
>> The undocumented SCPI command can be used to read out the FFT window factor:
Very nice, thanks! Now we know the exact values the instruments uses and plug these into our calculations.
-
>> The undocumented SCPI command can be used to read out the FFT window factor:
Very nice, thanks! Now we know the exact values the instruments uses and plug these into our calculations.
Yes - whatever it's worth.
Maybe you want to consider my analysis presented in reply #3561 in the following thread:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4318822/#msg4318822 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4318822/#msg4318822)
One might come to the conclusion that these factors are all very nice (and different, depending on the source), but rather meaningless in practice - with one major exception...
-
All true, but I find them useful to reconstruct the RTB FFT method / settings ;-)
-
In my last video, the Rohde & Schwarz RTB2004 was still holding secrets in terms of how its FFT analysis actually work. In this video, I go into greater detail unravelling them.
Thanks to various people that contributed to this thread with useful suggestions and ideas!
https://youtu.be/D1dVqcjbWm4
-
In my last video, the Rohde & Schwarz RTB2004 was still holding secrets in terms of how its FFT analysis actually work. In this video, I go into greater detail unravelling them.
Thanks to various people that contributed to this thread with useful suggestions and ideas!
https://youtu.be/D1dVqcjbWm4
I spent the whole evening (and partly night) watching your videos, reading the thread and your comparison document, that's a huge work, so thank you @RBBVNL9.
Wondering if you plan to continue updating the document or releasing new videos? I also watched your other recent videos on Anritsu hardware (wow, that's high-end gear!), but I was wondering if you were dropping this comparison topic.
Again many thanks.
-
May I revisit this older thread? I have just started to work my way through Rudi's very helpful series of videos -- mainly with an interest in the hands-on demonstration of the SDS2104X plus, which I'm seriously considering as my next scope.
One thing that struck me in episode #4 (Measurements) is that the SDS came out last, by an order of magnitude (!), regarding the speed of collecting measurement statistics. See the attached table and the video linked below. Given how the strength of quantitative measurements and analysis is always stressed when discussing the Siglent scopes (and their LeCroy role models), I had not expected this.
I did not find any comments on this in the present thread. Is the slow measurement update rate just a reality with the SDS2000X plus? Are there some memory or acquisition settings that should be changed to get much faster measurements? Has anything been improved in recent firmware updates?
Thanks for your comments!
https://www.youtube.com/watch?v=TAoB5614hs4&t=1270s (https://www.youtube.com/watch?v=TAoB5614hs4&t=1270s)
-
May I revisit this older thread? I have just started to work my way through Rudi's very helpful series of videos -- mainly with an interest in the hands-on demonstration of the SDS2104X plus, which I'm seriously considering as my next scope.
One thing that struck me in episode #4 (Measurements) is that the SDS came out last, by an order of magnitude (!), regarding the speed of collecting measurement statistics. See the attached table and the video linked below. Given how the strength of quantitative measurements and analysis is always stressed when discussing the Siglent scopes (and their LeCroy role models), I had not expected this.
I did not find any comments on this in the present thread. Is the slow measurement update rate just a reality with the SDS2000X plus? Are there some memory or acquisition settings that should be changed to get much faster measurements? Has anything been improved in recent firmware updates?
Thanks for your comments!
https://www.youtube.com/watch?v=TAoB5614hs4&t=1270s (https://www.youtube.com/watch?v=TAoB5614hs4&t=1270s)
You have already named it – this is a MSO with main focus on analytic capabilities. Of course there is a difference between analytic scopes, which require deep measurements, and standard scopes, which prioritize speed and try to measure (estimate would be more appropriate) on heavily decimated data. To understand this, here’s a simple example:
SDS2354X_Plus_Meas_Pulse_10Mpts
This screenshot shows just a pulse train. Pulse width is 10 µs, transition times are ~1 ns and repetition rate is 4 kHz. At a time base of 500 µs/div and 2 GSa/s, this results in a record length of 10 Mpts. The key parameters of the pulse train shall be measured: period, amplitude, rise and fall times and pulse width. Everything is measured reasonably correctly. Of course, at 2 GSa/s this scope isn’t fast enough to measure a 1 ns transition time precisely, yet it’s well within reasonable expectations. For more accurate measurements on such short time intervals, we’d have to zoom in up to the point, where sin(x)/x reconstruction calculates additional data points. We cannot use a much faster timebase right from the start, because at faster time bases we lose the measurements, one by one: At < 25 µs/div we could not measure the period anymore, at <1 µs/div we lose the pulse width measurement and can only measure a single transition, I.e. either the rising or the falling edge.
Now try the same exercise with the fast Keysight, which uses 64 kpts decimated data – good luck!
It is worth to take a closer look at this screenshot. We see advanced measurements in M1 mode, where statistics and Histicons (small histogram icons) are enabled. If we look at the “count” in the measurement statistics, it becomes obvious that only the vertical (amplitude) related measurements appear to be slow. For the time measurements, the scope analyzes the entire record, hence a single acquisition yields some 20 measurements of period, rise and fall times and pulse width. It just so happened that not a single time related measurement was shown in this comparison.
Apart from that the SDS2000X Plus firmware has seen a few optimizations since this comparison. My measurements yielded at least twice the speed as the numbers found in this review. If I make the conditions a bit more equal, then the vertical measurement rate reaches >16 measurements per second if I reduce the record length to 100 kpts, thus getting into the ballpark of the measurements on decimated data of the competing instruments.
Furthermore we have these M1 and M2 measurement modes (limited to max. 12 measurements) only in the “advanced measurements” mode. But there is also a “simple” mode, which allows a lot more than just 12 measurements in parallel:
SDS2354X_Plus_Meas_Simple
You should be able to count not 6, also not 12 but no less than 52 measurements at once. The glitch, that the measurement window closes as soon as we select an item (so that we cannot read the help text and have to re-open the window if we need to add more measurements) is long fixed either.
-
Thank you, Performa01 -- carrying out measurements on the full acquired data buffer vs. a decimated subset explains a lot. I had not realized that some other scopes decimate the data. (Besides my DS1054Z, which takes this to the extreme of using the screen data only...)
So, in situations where the high resolution is not needed and I want to gather statistics quickly, I can simply reduce the number of data points to speed things up? I did notice in the video that the measurement rate went up when Rudi demonstrated the use of gated measurements, i.e. only a shorter sequence of the data was used for the measurements.
Also, thank you for pointing out that multiple measurements per capture are derived for the time-related measurements. That makes sense; one does want individual measurements per period when collecting statistics on jitter etc.
You should be able to count not 6, also not 12 but no less than 52 measurements at once.
Now you are just showing off! ;) :D
-
You have already named it – this is a MSO with main focus on analytic capabilities. Of course there is a difference between analytic scopes, which require deep measurements, and standard scopes, which prioritize speed and try to measure (estimate would be more appropriate) on heavily decimated data. To understand this, here’s a simple example:
SDS2354X_Plus_Meas_Pulse_10Mpts
This screenshot shows just a pulse train. Pulse width is 10 µs, transition times are ~1 ns and repetition rate is 4 kHz. At a time base of 500 µs/div and 2 GSa/s, this results in a record length of 10 Mpts. The key parameters of the pulse train shall be measured: period, amplitude, rise and fall times and pulse width. Everything is measured reasonably correctly. Of course, at 2 GSa/s this scope isn’t fast enough to measure a 1 ns transition time precisely, yet it’s well within reasonable expectations. For more accurate measurements on such short time intervals, we’d have to zoom in up to the point, where sin(x)/x reconstruction calculates additional data points. We cannot use a much faster timebase right from the start, because at faster time bases we lose the measurements, one by one: At < 25 µs/div we could not measure the period anymore, at <1 µs/div we lose the pulse width measurement and can only measure a single transition, I.e. either the rising or the falling edge.
Now try the same exercise with the fast Keysight, which uses 64 kpts decimated data – good luck!
It is worth to take a closer look at this screenshot. We see advanced measurements in M1 mode, where statistics and Histicons (small histogram icons) are enabled. If we look at the “count” in the measurement statistics, it becomes obvious that only the vertical (amplitude) related measurements appear to be slow. For the time measurements, the scope analyzes the entire record, hence a single acquisition yields some 20 measurements of period, rise and fall times and pulse width. It just so happened that not a single time related measurement was shown in this comparison.
Apart from that the SDS2000X Plus firmware has seen a few optimizations since this comparison. My measurements yielded at least twice the speed as the numbers found in this review. If I make the conditions a bit more equal, then the vertical measurement rate reaches >16 measurements per second if I reduce the record length to 100 kpts, thus getting into the ballpark of the measurements on decimated data of the competing instruments.
Furthermore we have these M1 and M2 measurement modes (limited to max. 12 measurements) only in the “advanced measurements” mode. But there is also a “simple” mode, which allows a lot more than just 12 measurements in parallel:
SDS2354X_Plus_Meas_Simple
You should be able to count not 6, also not 12 but no less than 52 measurements at once. The glitch, that the measurement window closes as soon as we select an item (so that we cannot read the help text and have to re-open the window if we need to add more measurements) is long fixed either.
Hi Performa01,
How to enable all the measurements at once in “simple” mode with SDS2354X Plus?
Need to upgrae the firmware to support this?
-
How to enable all the measurements at once in “simple” mode with SDS2354X Plus?
Simple. In the "MEASURE" menu, select "Type". Then choose from the three tabs (Vertical, Horizontal, Miscellaneous) all the measurements you like - for this demo (some call it "show off" :-DD) I've simply selected all of them.
Done!
EDIT: You can change the measurement source after the fact. This enables you to compile a nice set of measurements and then apply it to any possible input source you like.