Siglent SDS2000X Plus

[casterle]

Stumbling over the update list, I guess the next firmware update will come in february...

The steady flow of updates, with important feature improvements and additions, is a strong argument in favor of a Siglent 'scope. Gotta love these guys (and gals, of course)!

[maxspb69]

I made a quick comparison of  SDS2000X+ and RTB2000 for small signals view. The test signal is a 1 kHz square wave with an amplitude of 5V p-p to which a 91kHz triangular signal with an amplitude of 30 mV p-p is mixed.

To begin with, how the test signal is displayed on the screen of both scopes.




Let's see the signal in the usual scale in the zoom mode

SDS2000X+ 8bit mode


SDS2000X+ 10 bit mode


RTB2000 Simple acq. mode


The RTB2000 has an additional easily accessible HiRes mode

RTB2000 HiRes acq. mode


to be continued...

[maxspb69]

Let's increase the gain and offset to see the signal in more detail.


SDS2000X+ 8bit mode


SDS2000X+ 10bit mode


RTB2000



Finally, let's see the stretched signal in zoom mode.

SDS2000X+ 8bit mode


SDS2000X+ 10bit mode



RTB2000 Simple acq. mode


RTB2000 HiRes acq. mode



In my opinion, RTB2000 is better suited for observing small signals due to the hardware 10-bit ADC plus an additional high-resolution mode. (The downside is that HiRes mode only works up to 50μs / div).
SDS2000X+ is not very much inferior to R&H, due to the 10-bit mode, which really works fine. And it is quite possible to observe small signals (several millivolts).


(Sorry for the design, I couldn't insert pictures into the text. Maybe the moderators can help fix this)

[Zlotnik]

I made a quick comparison of  SDS2000X+ and RTB2000 for small signals view. The test signal is a 1 kHz square wave with an amplitude of 5V p-p to which a 91kHz triangular signal with an amplitude of 30 mV p-p is mixed.

Wow, Max, thanks!
This is very useful and helps me a lot in my decision-making process!

In particular the last zoomed side-by-side comparisons of both scopes' normal and HiRes acquisitions are illuminating. Imho, one can see several things very clearly:

• While it's difficult to quantify the gain in ENOB from looking at a picture, the HiRes mode of the SDS2k+ seems to be very useable and effective. Of course, a similar benefit can be had on the RTB2k starting at a higher level.
• BUT: HiRes mode adds averaging and filtering: one can see how the trace becomes thinner in both the SDS2k+ as well as the RTB2k in HiRes mode. This reduction in noise should come at the expense of a reduction in bandwidth - tanstaafl. If your application is fine with this, then HiRes is very useful.
• This is an area where I think the Siglent actually is "lying" a bit compared to the R&S: in the RTB2k, the sample-rate is reported as reduced from 2.5GSa/s to 62.5MSa/s when switching to HiRes (unless you changed something else, but it doesn't seem like it). In contrast, the SDS2k+ happily reports 2.0GSa/s in both normal as well as 10bit mode. Unless 10bit mode works very different than usual HiRes mode, you cannot achieve extra vertical resolution without sacrificing effective sample rate - and the user should be informed about that.
• Both SDS2k+ and RTB2k frontends seem more or less similar in noise, the traces are about equally "fat" in both scopes, both in normal as well as HiRes modes. This matches the measurements in several review videos I've seen, so makes perfect sense. What I find interesting is that the 8bit quantisation on the SDS2k+ is so visible compared to the noise levels
• this must translate into quantisation noise being a significant noise term. In other words, the Siglent's 8bit ADC does not seem to have enough ENOB to make best use of the low-noise frontend, while the R&S' 10bit ADC does.

One more interesting unrelated observation can be gleaned from the second post with the offset applied. The RTB2k's front-end does not seem to tolerate overload from the negative clipping quite as well as the SDS2k+: one can see the signal takes some 50-60us to stabilise to the correct level on the R&S, while on the Siglent it's there right from the start.
Is the RTB's vertical control set to "offset", or to "position"?

I'd love to do a system ENOB measurement on both of the scopes, but my home lab's signal generators are by far not performant enough both in frequency as well as SINAD to attempt this. Maybe once I get one of the two scopes, I'll take it to work on a rainy weekend ;-)

BTW, I think it would make sense for you to post this test also in the RTB2000 thread - people there will not necessarily find them in the SDS2k+ thread.

[maxspb69]

Bandwidth reduction in high resolution mode is declared in both scopes.
For SDS2000X+, this is a bandwidth limitation of up to 100 MHz (from 500 MHz possible). For RTB2000, this is a time base limitation of up to 50 μs / div (with a faster sweep, the HiRes mode is automatically disabled and becomes unavailable in the menu). This is also an indirect bandwidth limitation.

It is worth remembering that for SDS2000X+ the HiRes mode is 10 bits maximum (8 bits by ADC + 2 software), and for RTB 2000 - 12 bits maximum (10 bits by ADC  + 2 more bits for software in HiRes mode).

Is the RTB's vertical control set to "offset", or to "position"?

RTB2000 in OFFSET mode, POSITION mode allow 4 div waveform offset only. But imperfectly compensated probe also can give such distortion.
But I also noticed that Siglent allows a greater offset without signal distortion than R&S.

[Performa01]

There is one disadvantage to Siglent's approach, and it can be a significant one: the mask test operates only on the full screen, and will not operate in zoom mode.  This means that mask testing cannot be applied to a subset of the capture the way it is on other scopes, and this means you can't have it stop the scope upon failure and then examine some other portion of the waveform that is off-screen.   This would be easy enough for Siglent to fix: they'd merely need to make it possible to define and operate the mask against the zoomed portion of the screen.

Have you ever tried it out?

What do you see in the attached screenshot?

[casterle]

I just picked up my new SDS2104X+ and have a question and a comment.

Has the VNC feature been removed? According to the manual, I set this via:

   Utility->System Settings->I/O Settings->VNC Port

No such setting exists. In it's place is USB ID which is not mentioned in the manual. Are there updates to the manual to keep it in sync with firmware updates? Do I need to worry that when I install an update, something might go missing?

I'm put off by the manual. I was trying to figure out how to keep the menus on-screen for more than a few seconds before they close, but could find no mention of this in the manual. Googling, I found a similar feature in the SDS1000CML+ manual so I assumed I must have it as well. I finally stumbled upon it in the display menu (where I started looking), having missed it the first time.

If this and the errors above are indicative of what I can expect from Siglent docs, I guess I'm in for a rough ride. BTW, I love what I've seen in the hardware itself but I expected more from the docs in an instrument in this price range.

[Elasia]

I saw its pid running last i looked, i don't use it so your mileage my vary

[tubularnut]

Has the VNC feature been removed? According to the manual, I set this via:

   Utility->System Settings->I/O Settings->VNC Port

[casterle]

<snipped image>

Thank you!

[kcbrown]

Well, as some of you are obviously aware by now, I gone and done it.  I got myself an SDS2104X Plus.  Saelig happened to have them in stock so they shipped immediately, and I managed to get mine right before Christmas.   I was so excited to order it after getting my wife's approval that I forgot to get the EEVblog discount code first!      Probably because I don't order test equipment often enough.   There's a clear solution to that problem ... 

I also ordered the MSO option, but that was out of stock so I'm unlikely to receive it for a couple of weeks or so.  I was a bit surprised by that.  Either it's because there's a relatively high demand for it, or there's so little demand for it that they just don't keep it in stock.  I can't tell which.

What a Christmas present!!!   Overall, this thing is awesome.

I've been playing around with it the last few days.  I managed to run into some responsiveness problems early on (so bad that the scope would only intermittently respond to the run/stop button -- the scope should always respond to that if nothing else), but I can't remember how I had things set up and I've not been able to reproduce the problem since.  I did hard boot the scope along with resetting to defaults, and that might have cleared up whatever was causing the problem.  If I run into the problem again and find a way to reproduce at will, I'll report it.  The scope UI (particularly the run/stop button) should never fail to respond to inputs.

There's a trigger bug in the slope trigger of my SDS-1204X-E.  See the discussion on that starting with https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3357852/#msg3357852.  It reproduces fairly reliably on my 1204X-E, and HendriXML has managed to reproduce it at will with his scope as well.

It does not reproduce on the 2104X+.  I was very happy to see that, obviously.

There are two major limitations arising from Siglent's general approach to capturing ("what you see is all you get") that affect the 1000X-E series and earlier, both having to do with zoom mode.  The first is that you can't use zoom mode with the digital channels.  The second is that you can't perform mask testing with zoom mode enabled.  The former is a problem if you want to monitor a particular time range within the captures on the digital channels (for instance, if you want to watch the decoded output in a particular section of the capture and manually stop the scope when you see it go wrong so that you can examine other parts of the capture).  The latter is a clear problem if you want to capture a glitch and then examine the waveform some amount of time before or after the glitch.

The 2000X+ fixes both of those limitations!  Needless to say, I'm very pleased about that. 

Coming from the 1204X-E, this thing has more capability than you can shake a stick at.  The larger display should not be underestimated in its effects on usability.  It makes the scope much more pleasant to use.  When you're used to interacting with the scope solely through buttons and knobs, being forced to use the touch screen for certain things takes a little getting used to, but it doesn't take all that long.  And once you do, you will not want to go back.  The touchscreen is clearly superior for entering numbers and letters, and makes operations such as directly setting a timebase much easier.

All is not perfection, of course (it never is). 

Movement of traces (by changing the voltage offset, or by changing the trigger time location, or by changing the volts/div or the timebase) should be buttery smooth because doing those things seems to stop the scope in its tracks, but it isn't buttery smooth.  Depending on the implementation, this might be as simple as increasing the amount of allowed "dead time" prior to the scope restarting operations once you've stopped moving the controls.  But the 1000X-E is more responsive than this scope is, and that's a bit unexpected.  The general responsiveness of this scope isn't terrible, mind you, and in fact it's certainly usable enough.  But given that it stops everything in its tracks while you're manipulating the controls, it should be smooth and instantaneous, and it's just not.

The scope seems to use any excuse at all to nuke your history.  Merely changing the voltage offset will cause the scope to throw away everything it's captured.  Hitting "single" will certainly do that.  Even hitting the button corresponding to the trigger mode you're already using will cause it to throw away the history, even though doing so would, you'd think, be the equivalent of a no-op.  You might want some means of telling the scope to toss the history (though I haven't come up with a good reason for that), but doing so should be the exception.  Seeing how the always-on history is one of the main distinguishing characteristics of this scope and is essentially the justification for the "what you see is all you get" approach to capturing, nuking the history for the slightest of reasons seems counterproductive at a minimum.

When you're using the decode list, hitting the multifunction knob button should move you to the portion of the waveform where the decoded entry is (moving the waveform itself will move your location in the list, so essentially I'm saying that this should work in reverse as well).  But it doesn't.  This isn't unique to the 2000X+ series -- it's the same with the 1000X-E series as well.

The intensity grading just isn't as smooth as it is on the 1000X-E series.  I have a suspicion this is the result of the grading code not having been adjusted properly for the higher resolution display or something like that, but it may be that making such an adjustment would negatively impact the performance, so this is a tradeoff I'm willing to live with.  The grading isn't terrible or anything, but it's not quite as good as the 1000X-E, either.


There are likely to be other good and bad things that I'll discover about the scope as I continue to use it.  But thus far, I'm overall very impressed.  It somehow has a very professional feel to it, despite its somewhat mediocre responsiveness for some things (I've generally found that the scope is very responsive to manipulation of the menus).  Those things I've tried (which isn't a lot just yet) seem to work without issues.  It remains to be seen if the UI is more stable than that of the 1000X-E series (seems the 1000X-E UI will eventually lock up if given enough time, but most people won't see that because most people probably don't leave their scopes running 24x7 like I do).  But so far, this thing is a real humdinger from the point of view of this neophyte user.


One last thing: keep in mind that especially when it comes to the usability angle, it's much easier to notice things that are done wrong than things that are done right.   Done right, a UI more or less "disappears" into the background, becoming completely unobtrusive because it just stays out of your way when you're using it.  So if you don't see me praising the UI for something it gets particularly right, that's why.

[drwho9437]

I'm late to the party here but I am very thankful they have added configurable colors to this scope for the colorblind like me!

Thank you. Seriously! Everyone needs to do this, it isn't that hard. There are lot of colorblind people in the world.

[kahuna0k]

Trying to gather more information on the dynamic range (or handling of overload), I did a test similar to what maxspb69 did. A 1Khz square 5V p-p added to a 97Khz triangular 5mV p-p. I was able to measure it and display with some level of accuracy in the Rigol but wasn't able to properly zoom in the Siglent. If I tried to go under 200mV per division in the Siglent it wouldn't trigger, so the best I could do was to capture in 10bits and then apply zoom on a captured signal. In the attached images there is the signal at 200mV in the Siglent and then the digital zoom on the captured wave, also a display of what I get if once I've done the recentering I go to Run mode. The triggering point wouldn't make any difference, and in fact I would ocassionally get strange artifacts on the screen. In the Rigol images you can see at normal and hi-res, both in single-shot and run modes, working with no problem.

[maxspb69]

I checked my RTB2000 and SDS2000+ with a 5V / 5mV signal. Both oscilloscopes handled this signal poorly.
These are very difficult conditions. In this case, MCO5074 wins, albeit very slightly.

The screenshots show the best signal image I could get. Better these two devices cannot display.


But everything changes if we little simplify the task. Let's take a 4V / 5mV signal. Here SDS2000X+ is allowed to set 5mv / div and set the big offset. The signal is distorted, but you can examine it in detail.

This is probably due to the features of the frontend  circuitry and the switching threshold of the relay controlled  attenuator.

[2N3055]

Congrats on upgrade!
It is nice to see balanced, concrete examples of what you found by using the scope..
Those are very helpful to users and Siglent to make better products.

Happy holidays!

[kahuna0k]

I set the offset in the AWG, as the MSO5074 has the same problem with maximum offset at a given voltage per division. I've attached a capture with the MSO5074 of the most extreme conditions I was able to generate with my "improved" SDG2042X, 10V (0-10V) square with a 2mV triangle (didn't try on the SDS2104X as it was already failing at 5V/5mV).

[kcbrown]

Congrats on upgrade!
It is nice to see balanced, concrete examples of what you found by using the scope..
Those are very helpful to users and Siglent to make better products.

Thanks!  It's quite a scope, I gotta say.  This feels like the sort of scope that is so capable that it will never need to be replaced as long as it survives.   The 1204X-E is very capable in its own right, but there's something about this scope that feels like it's so good and so complete that most users will not really be wanting for anything, particularly after Siglent fixes what bugs exist in the scope.

Happy holidays!

Merry Christmas, Happy New Year, and Happy Holidays!  And may this next year be even more awesome than this year was.

[casterle]

I got myself an SDS2104X Plus...right before Christmas.

Merry Christmas to me as well; got my SDS2104+ on the day after. My initial impression (with apologies to Oscar Hammerstein II): I'm in love, I'm in love, I'm in love, I'm in love, I'm in love with my wonderful 'scope. Youngsters may need to Google "South Pacific."

I also ordered the MSO option

Having already overspent on the 'scope, I bought an used HP/Agilent/Keysight/FutureNameHere logic pod converted for the Siglent for $50 delivered, from a seller here on eevblog.  He has created an adapter that plugs into the scope, the downside being the lack of a housing for the plug end. It seems to stay in place without the added support, but if that becomes a problem I'll 3D print something.

I haven't had a chance to try it yet, but since everything but the adapter assembly is HP quality I expect it will work well. The used pod and flywires look to be in good condition. The woven cable is about a meter long.

The adapter looks to be very well designed to my inexperienced eyes: squiggles in apparently appropriate places, ground plane all the way into the 'scope and a 2nd board the size of the 'scope's plug opening, with a slit in the middle through which the adaptor's fingers slide at a 90 degree angle such that it extends the ground plane to cover the 'scope's plug opening. Almost forgot, he sends two of each board so I have a spare for each as well.

I managed to run into some responsiveness problems early on

I haven't seen anything similar. When I received the 'scope I installed the latest firmware (thinking it would only install if it were newer - not the case as it turns out); no harmful effects at least. If you see the problem again you might give this a try.

The scope seems to use any excuse at all to nuke your history.

Say it ain't so! I'd read something that hinted at this but thought I'd misunderstood. Memory management was my main concern going with Siglent. I started out with a negative attitude due to a video from someone I've come to greatly respect, who savaged the Siglent approach. I'm looking at you, Dave!

Weeks of reading the Siglent threads lead me to believe I understood the advantage of the Siglent Way, and learning to think and work using the 'what you see is all you get' approach was worth the sacrifice. Now it sounds like that advantage was mostly smoke.

Siglent: Please tell me this is a bug that will be fixed in the next update. Or tell me that you've decided to discontinue swimming upstream on this front and will provide me an option to use my buffers conventionally. This sounds like the best solution for everyone including you - is this a religious issue in the Siglent universe?

When you're using the decode list...

That would be nice; I'd be surprised if we didn't see such an easy fix soon. But what I find a more glaring and surprising omission is the inability to search on decodes. I only bought the 'scope after I found that I can easily export my captured data for analysis on my PC (sigrok to the rescue).

I've gotten push-back on this feature as unnecessary or not useful, and while that may be true for the commenters, it isn't in my case. Sure, a real (USB-based) unit would allow far more powerful decoding and analysis that I can do on any 'scope. But if needed I can do that now using sigrok. A flexible and well-implemented search would cover the middle ground, which is where I anticipate spending much of my time.

But thus far, I'm overall very impressed.  I've generally found that the scope is very responsive to manipulation of the menus.

I couldn't agree more. Other than dragging waveforms and such, the UI screams; even its slower operations are not frustrating.

Moreover, IMO it's UI is beautiful and well thought out. I guess many don't care, but the aesthetics of an instrument makes a difference in the usability of an instrument for me. I couldn't ask for more; in my limited experience they've wisely chosen which soft buttons to implement physically and have arranged the controls well.

I'm increasingly colorblind as I age and being able to set trace colors makes a real difference; as the 'scope arrived I could see little difference between the default colors on channels 3 & 4. Without the option to set trace colors my 'scope would be been practically reduced to 3 channels. That the trace buttons change colors to match the trace is a Rolls-Royce touch I didn't expect (if only they could get the probe's chicken-rings to do the same!).

One presumably easy change that would make the buttons better indicate channel state is to use a lower brightness for a button that is active but not selected, reserving full intensity for the selected channel and disabling the LEDs on inactive channels.

My biggest gripe has nothing to do with the 'scope: the docs are substandard beyond my expectation. No only is much omitted, but some information is flat wrong (look up setting the VNC port number, as one example). I hope there are many application notes I've yet to find.

I've spent several hours trying to get VNC working; years ago I used it often to control remote PC's and it's always just worked (this is my first attempt under Win10). I've found many VNC tutorials for Win10, not a single one of which helped, using either the default Windows app or UltraVNC. The manual is silent on this feature other than incorrect instructions for setting the port number. Come on, if a feature doesn't work with the default OS app, tell me how to use the damn thing.

I know Siglent adds and improves features routinely, but my version-free, undated manual doesn't tell me about them and provides no way of knowing when it was last updated so I know if I have the latest version. No need to take this as far as some do, with change logs and all, but a date and version number don't seem too much to expect.

This is perhaps more important to me than to others. I'm old and don't have much time left to waste - every hour is more precious than the last and it pisses me off then I have to waste even one hunting down information that should have been provided.

When I buy a no-name Chinese gadget, I factor that I will get no documentation or support into the purchase decision. Had I paid $140 rather than $1400 for the 'scope your documentation would have exceeded my wildest expectations. Please put some effort into this, what I see as your greatest weakness.

One last thing: keep in mind that especially when it comes to the usability angle, it's much easier to notice things that are done wrong than things that are done right.

You make an important point.

Part of any frustration about the SDS2K+ line may be the result of the generally wonderful job they've done on this instrument. X was done better than it is on some $10K scopes, but how could they have managed to screw up Y so badly? The better the good, the worse the bad looks in comparison.

Bottom line, bitching aside (and anticipating a history fix), I'm still singing. Thank you, Siglent!

[maxspb69]

There are indeed some problems with knobs (not keys!) responsiveness and it is serious. Those who worked with Keysight, Rohde&Schwartz and Tektronix scopes and tried SDS2000X+ know what this is about. Hopefully this will be fixed in the future, because this is the most annoying moment when working with a scope.

[Martin72]

There are indeed some problems with knobs (not keys!) responsiveness and it is serious.

Hm?
Did I miss something ?
I got no problems with the knobs 

[maxspb69]

The problems are not with the knobs and encoders, but with the slow reaction of the scope to their rotation. Try to quickly turn the vertical gain or timebase knob for 5-6 clicks. You will see that the timebase or gain has changed by 2-3 points at best case. And they should be 5-6, as you turn. If you turn the knobs no faster than 2 clicks per second - no problem. But this is not normal, in my opinion.
The situation when you need to quickly change the timebase or gain within a large range (100ms - 50ns for example). And slowly turning the handle for a long time so that the device has time to react is annoying. Most oscilloscopes don't have this problem, even much cheaper ones.

[Martin72]

Ah, now I know what you mean.
"Unfortunately", I´m still having holidays, so I couldn´t check this on other scopes at work.
For me it´s no problem at all (got this scope since february this year and did not notice it until you wrote it.).

[thinkfat]

The problems are not with the knobs and encoders, but with the slow reaction of the scope to their rotation. Try to quickly turn the vertical gain or timebase knob for 5-6 clicks. You will see that the timebase or gain has changed by 2-3 points at best case. And they should be 5-6, as you turn. If you turn the knobs no faster than 2 clicks per second - no problem. But this is not normal, in my opinion.
The situation when you need to quickly change the timebase or gain within a large range (100ms - 50ns for example). And slowly turning the handle for a long time so that the device has time to react is annoying. Most oscilloscopes don't have this problem, even much cheaper ones.

Indeed, this is a really annoying bug. How can that even happen? A quadrature decoder is a built-in block nowadays in any micro controller. How can software "miss" events there? It should not be possible.

[tv84]

I don't think it's a bug.

IMHO that is a feature, due to timing constraints, and users will have to live with it.

[kcbrown]

I don't think it's a bug.

IMHO that is a feature, due to timing constraints, and users will have to live with it.

I disagree.

You'd have a valid point if moving the knobs didn't stop all other processing.  But it does stop all other processing.  It stops triggering, it stops display update (except for the necessary things to show the changes you're making), everything.  This means that when you're twiddling the knobs, there is absolutely no excuse at all for the responsiveness to be anything other than instantaneous.   I mean, even just moving the cursors will stop all processing and nuke your history.  And while it may appear that the scope is continuing to operate while you move the cursors, careful observation will show that it's stopping operation in between updates of the cursors.  But the proof that it's stopping operations is in the fact that it's clearing the history.

In fact, I'm beginning to believe that perhaps the reason for the relatively slow responsiveness may be in part that it nukes the history buffer every time it processes an update as a result of movement of these knobs, and it may be that nuking the history is a relatively expensive operation.  If that's the case, then Siglent should simply be recording, in a flag, that the history needs to be cleared once the scope resumes normal operation (and they should clearly be using a long enough delay prior to resumption that the probability of interfering with interaction with the knobs is kept low).

EDIT: It doesn't nuke the history every time it processes an update.  It nukes it upon the first acquisition after any change to the cursor state (which includes position, etc., as well as whether or not the cursors are enabled -- just enabling the cursors is enough to cause it to kill the history buffer upon the next acquisition), the timebase, the volts/div, the trigger position, or the voltage offset.  There may be additional things that qualify, but that's the minimum.