Siglent SDS2000X Plus

[Peter_O]

...
Is there something wrong with the scope?

Everything is fine with you scope.

Note that your screenshots show some offsets, you might have dialed in by hand, e.g. in the first shot -1.98mV for Channel 2.
Press the lower rotary button to reset to zero for each channel.

Acc. to datasheet the vertical accuracy is +/- 0.5div, which would be exactly 250µV at 500µV/div.
My scope shows about 250µV too, same with inputs shorted by a 50 Ohm resistor.

Enjoy your scope! 

[vicki20july]

Thank you for replying. I understand the manual offset, I added that for easy viewing to show results of all 4 channels. I am more concerned about the actual DC offset which is approx. 250 - 300 microns and was wondering id the scope needs factory calibration.... The certification that came with it claim that its calibration was checked in factory in May.

[tautech]

Thank you for replying. I understand the manual offset, I added that for easy viewing to show results of all 4 channels. I am more concerned about the actual DC offset which is approx. 250 - 300 microns and was wondering id the scope needs factory calibration.... The certification that came with it claim that its calibration was checked in factory in May.

Offsets can be worse until the instrument comes to full operating temp in some 30 minutes (RTFM) when any Self Cal is performed. As we are all sold out of SDS200X Plus we don't have one to check but other instruments have a Quick Cal feature that can make corrections on the fly until the unit reaches full operating temp or if there is a sudden temp change in the lab.
Check the Utility menu for the Quick Cal feature and switch it to ON.

[vicki20july]

Offsets can be worse until the instrument comes to full operating temp in some 30 minutes (RTFM) when any Self Cal is performed. As we are all sold out of SDS200X Plus we don't have one to check but other instruments have a Quick Cal feature that can make corrections on the fly until the unit reaches full operating temp or if there is a sudden temp change in the lab.
Check the Utility menu for the Quick Cal feature and switch it to ON.

Unfortunately, the instrument does not have a Quick Cal option anywhere... Do you or anyone know it's exact location. I can't see it anywhere. The self Cal option is there. The offset does move as the instrument is warming up but for some channels can be as bad as 250 - 400 uV at 500 uV/div after 30 min of warmup. I always perform self calc at least after 30 min so that instrument is at full operating temp.

[tautech]

Offsets can be worse until the instrument comes to full operating temp in some 30 minutes (RTFM) when any Self Cal is performed. As we are all sold out of SDS200X Plus we don't have one to check but other instruments have a Quick Cal feature that can make corrections on the fly until the unit reaches full operating temp or if there is a sudden temp change in the lab.
Check the Utility menu for the Quick Cal feature and switch it to ON.

Unfortunately, the instrument does not have a Quick Cal option anywhere... Do you or anyone know it's exact location. I can't see it anywhere. The self Cal option is there. The offset does move as the instrument is warming up but for some channels can be as bad as 250 - 400 uV at 500 uV/div after 30 min of warmup. I always perform self calc at least after 30 min so that instrument is at full operating temp.

As mentioned we currently have no stock of the X Plus however the Quick Cal feature is in the X-E and X-U models and mention of it is on P181 in the User manual.
https://int.siglent.com/u_file/document/SDS1000X_E_SDS1000X_U_UserManual_EN.pdf


Beta testers watching, does Quick Cal need adding into the X Plus feature set ?

[Martin72]

Hi,

Played on our sds2k+ at work, can confirm there is no quick cal function.
Displaying all channels with 500uV/div., two got offset.
Did not make a selfcal, pic from it later when I'm at home.
Don't think it's a failure.
The model I've tested here got max 250uV pk-pk after 20...30min..

[Martin72]

Hi,

Back at home..

Ch1 got a offset of appx one division, ch3 appx a half.
2 and 4 are "flawless".
That doesn´t worry me much as our signals to be measured are rarely under 200mV.

[kcbrown]

say, 6 clicks in less than half a second, and be guaranteed to get a 100x change in timebase?

My surprise/attention lowers down to sub-zero....
Are there any serious needs for this fast acting ?
On a DSO, stopped, I got all the time in the world....

Is the need a serious one?  That depends on how much you value responsiveness in your instruments.

Have you ever typed on a computer where the computer failed to see some of your keystrokes?  You'd press a sequence of keys because you're typing a word, and only some of the letters managed to show up.  If you've ever experienced that, then you know how jarring it can be.  Why do you suppose it would be a jarring experience?

The answer is that your expectations are that the computer will faithfully respond to your keystrokes, and you've built your way of interacting with it around that.  If the computer always had a tendency to drop keystrokes, then you'd interact with it very differently, and instead would press a keystroke and wait for the letter to show up on the screen before moving on to the next letter.  It would demand more of your attention as a result, and you'd be slower in typing as a result.

This is similar.  The scope is dropping some of the requested actions.  If you're used to always verifying that the screen reflects the state you want, then it doesn't matter so much, but that does mean you have to pause until you've performed that verification before moving on.

These two things aren't quite comparable of course, but it does illustrate the point.  If you've got an instrument that always responds to what you command it to do, then you learn that you can depend on that, and eventually optimize your actions around that.  You pay less attention to making sure that the instrument is doing what you want and turn your attention to other things.  This results in your workflow improving and becoming more efficient, at the potential expense of errors in the event your instrument suddenly fails to respond as you expected it to.


So ... is this a serious problem here?  Probably not.  But that it exists eliminates the possibility of a workflow optimization that would otherwise be available.

[kcbrown]

With the mods you have done, can operate the encoders in any normal way and they function as expected ?

As a general rule, they function as expected.  But a lot depends here on what is "normal" and what is expected.

The more slowly you move the encoders, the greater the chance the scope will see the movement.  If I move the encoder one click, then wait for that change to be reflected on the screen, then move it again, the scope will be able to keep up with the movement and there's no issue.  It's only when I move the encoder quickly enough that it can't keep up that it'll drop encoder events.  And importantly, "quickly enough" varies with what the scope is doing.  If it's doing measurements, or especially something like an FFT, then it doesn't keep up as well as it would if it's not doing any of those things.

One major advantage of having detents in the encoder is that it allows you to feel how much you've turned it.  This should make it easy to make significant changes quickly and accurately.  For instance, it should make it easy to change the timebase by 100x (6 clicks).  The issue with Siglent's implementation is that because (apparently, and this is something that might have changed in the current firmware, which is why I asked the question I did) the encoder events aren't queued through an interrupt mechanism or through a thread that gets higher priority than, say, the display processing thread, the end result is that you lose this major advantage of having detented encoders.  You simply can't turn the encoder by some predetermined amount and reliably get the desired results from it, unless you always do it slowly enough (where "slowly enough" depends on what the scope's doing).

On my Instek scope, the encoder events are queued, with the end result being that even if the scope's engine can't keep up with the rate at which I'm making changes, it does eventually reflect the entirety of the desired changes.  So you might, for instance, turn the timebase knob by 6 clicks, and then over the course of (as an example -- it doesn't necessarily take this long) the next second it'll update the waveform display for each click it detected (so you'll see 6 changes happen over the time period).

The way the Instek behaves on this is the way the Siglent should behave, IMO.


Now, I need to make something clear here.  The way the Siglent behaves isn't terrible or anything.  It's certainly adequately usable.  But it could stand improvement.

Is your usage style weighted towards using the physical controls, touch screen or mouse or a mix of all 3 ?

I use the physical controls almost exclusively when changing the waveform's scale and positioning, or the trigger level.  I also primarily use the physical controls (the buttons) for almost every operation that is available through the physical controls.  I'll use the mouse for handling the menus and other things that are not readily available through the physical controls.  I'll occasionally use the touch screen when the mouse isn't handy or when the touch screen is more "direct", such as when using the on-screen keypad.

[trp806mo]

Before selfcal :


After selfcal (which is very very very long ...)
[ Specified attachment is not available ]

[tv84]

If you've got an instrument that always responds to what you command it to do, then you learn that you can depend on that, and eventually optimize your actions around that.

Man  machine.

How can you be sure that you tried to rotate an encoder 17 clicks at 10 clicks per sec? If you don't get 17 clicks, you blame the encoder? 

[Martin72]

Before selfcal :
After selfcal

This is how it should be, I expect the same result if I would do the self cal on next monday at work.

(which is very very very long ...)

As the three scopes arrived at work and I started the selfcal, one was remarkable faster than the other two.
It was the one with a different, newer firmware.

EDIT:

Correction, it was the slower one which got the newer firmware:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4141858/#msg4141858

[vicki20july]

Hi,

Back at home..

Ch1 got a offset of appx one division, ch3 appx a half.
2 and 4 are "flawless".
That doesn´t worry me much as our signals to be measured are rarely under 200mV.

Thank you for the confirmation. I checked the datasheet for SDS2000X+ and SDS2000X HD and for both, under the vertical system label

for SDS2000X+
DC gain accuracy ≤ 3.0%
Offset accuracy ±(1.5%*offset+1.5%*full scale+1 mV)

for SDS2000X HD
DC gain accuracy (typical)
0.5 mV/div ~ 4.95 mV/div: ±1.5 %;
5 mV/div ~ 10 V/div: ±0.5 %;
Offset accuracy ± (0.5% of the offset setting + 0.5% of full scale + 1 mV)

They both have same offset accuracy. If I understand the formula correctly and looking at the right thing, it means that as long as the DC offset is within 1mV, it is within specs..?

[blurpy]

Siglent SDS2000X Plus V1.5.2R1 Firmware Update

4. Supported LXI (only with the new produced units)

Regarding this LXI support. What sort of functionality do you get? And why only for new units?

[trp806mo]

yes at least +/- 1mv and you can't complain

Currently what bother me the most is not the offset introduced by the scope itself but my probes when they are heating and aging ... (tek P6248, P6243). So a menu as a tek where you can adjust the position of the waveform and the offset would be nice. Currently I have to play with the math function to do it ( or I missed something)

[kcbrown]

If you've got an instrument that always responds to what you command it to do, then you learn that you can depend on that, and eventually optimize your actions around that.

Man  machine.

How can you be sure that you tried to rotate an encoder 17 clicks at 10 clicks per sec? If you don't get 17 clicks, you blame the encoder? 

Some people might be able to tell that.  Others won't.  It's going to depend on the individual.  I can pretty reliably tell that I've moved it, say, 6 clicks, because I can hear that.

What I can know is that there have been plenty of times when I've rotated it for some number of clicks, and yet get a substantially smaller amount of change out of it.  This means it clearly did drop clicks.  This is easy to reproduce when you've got the FFT going, for instance.

So let's say that the maximum number of clicks you can reliably turn the encoder is 5.  So to get 17 clicks, you turn 5 clicks, then another 5 clicks, then another 5 clicks, then another 2 clicks.

And the encoders are 20 clicks per revolution.  So if you want to get 10 clicks, just turn the encoder 180 degrees.  You can also mark the knob and thus know instantly whether you've turned it 5 clicks (1/4 turn), or even 15 clicks (3/4 turn), or 20 clicks (1 full turn).

If the scope responded properly, then you'd be able to turn the knob by however many clicks you needed all day long and it'd faithfully get you that many clicks worth of change.  The Instek will do that, at least that I've seen.  The Siglent won't, at least on the version of the firmware I'm on. 

Obviously there are going to be some understandable limitations of this, but the plain fact of the matter is that these scopes are computers and modern computers (even ones with ARM processors) are fast.  Blindingly fast.  So fast that they execute millions of instructions in a matter of milliseconds.  So fast that they can be doing all sorts of other things in the background and you'd never know by looking.  So fast that if the UI isn't instantly responsive, it means either that the amount of computation necessary to properly respond to the UI is astonishingly huge (far more than is justified for what we're talking about here), or the architecture of the UI is wrong.


So my question to the board is: does the latest firmware queue up the clicks such that it will reliably change the scales as commanded?  The version I'm on won't.

[tomud]

Obviously there are going to be some understandable limitations of this, but the plain fact of the matter is that these scopes are computers and modern computers (even ones with ARM processors) are fast.  Blindingly fast.  So fast that they execute millions of instructions in a matter of milliseconds.  So fast that they can be doing all sorts of other things in the background and you'd never know by looking.  So fast that if the UI isn't instantly responsive, it means either that the amount of computation necessary to properly respond to the UI is astonishingly huge (far more than is justified for what we're talking about here), or the architecture of the UI is wrong.

While in arbitrary generators, be it Rigol or Siglent, I have to admit that encoders are a tragedy. It is in oscilloscopes that it seems to me that this is a user's problem. Who spin the encoders left and right so fast that they don't seem to see for themselves what exactly they want to set

I even recorded a video with a comparison of Rigol's oscilloscopes once, because on a certain Polish forum there were similar accusations about slow operation. Personally, I try to take my time with measurements as this often leads to very costly errors... With this approach to measurements, the problem is not felt. On the other hand, I can recommend equipment that is many times more expensive than well-known brands, which may also have some slowdowns when turning the encoders (when we spin quickly)

[kcbrown]

While in arbitrary generators, be it Rigol or Siglent, I have to admit that encoders are a tragedy. It is in oscilloscopes that it seems to me that this is a user's problem. Who spin the encoders left and right so fast that they don't seem to see for themselves what exactly they want to set

Certainly not people who are using scopes that can't keep up with their commands! 

Just like with typing text into the computer, the way you give command sequences to a device will depend on your experience with that device.  If it tends to drop commands on the floor then you're going to take your time to be certain that it lands in the state you want it to.  You won't trust the device to do the right thing.  Similarly, if your computer tends to drop letters that you type on the floor, you're going to be very careful with typing to make sure that what you've typed shows up properly.  If, on the other hand, your experience is that it reliably obeys your command sequences then you'll learn to relax your oversight of it.

That may or may not be a good thing, depending on the likelihood of error on its part and the importance of exactly the right settings.

Either way, the point here is that these devices are so incredibly fast compared to humans that there's really no good reason for them to not be able to keep up with human inputs.  Our inputs are glacial to them.  That means that failure of the device to keep up with human commands to it is an architectural defect, plain and simple.

I even recorded a video with a comparison of Rigol's oscilloscopes once, because on a certain Polish forum there were similar accusations about slow operation. Personally, I try to take my time with measurements as this often leads to very costly errors... With this approach to measurements, the problem is not felt

Of course.  But then at the same time, you're forced to spend more time on setting up the instrument than you might otherwise.  Not an enormous amount of difference, mind you, but an instrument that reliably obeys your commands is one that allows you to turn your attention to higher level things.


For the Siglent, how usable the scope is with respect to making changes to the settings depends on what it's doing.  Turning on the FFT will seriously compromise its responsiveness when you operate the controls, for instance.  It's not the end of the world or anything, of course.

Those here who are skeptical of the value of a highly responsive user interface in a scope should try using an Instek scope or, especially, a Keysight scope.  The Instek is very fast.  The Keysight is instantaneous.  It's only when you go back to a slower scope that you realize just how unresponsive the slower scope really is.

We tend to be very capable of adapting to the demands of different equipment.  That works in our favor, but does not diminish the value of a fast UI.

If you want to really see the value of a fast UI, I have a suggestion: keep your computer on 24x7, install and use Firefox, and keep Firefox open for as long as you can stand.  You'll find that it tends to get slower over time, perhaps to the point of frustration.  That frustration is proof that you value a fast UI.  And if you value a fast UI in a computer, why don't you similarly value one in a scope, or anything else that you interact with?

[tomud]

@kcbrown

Let me say this ... I am dealing with relatively cheap equipment at home (Rigol, Siglent or lower models of well-known brands). They all have some shortcomings, which unfortunately are compensated by their price (although in the case of lower models of well-known brands it hurts more because for their price I could buy more equipment, eg Siglent).

Professionally, I have access to equipment that often costs hundreds of thousands of dollars, and I can see the difference - but I am aware that I cannot demand the same from equipment that costs a fraction of the cost of professional equipment.

You can always spend money on some Tektronix instead of cheap Siglent and be "satisfied"...
...but I'm not entirely sure about this satisfaction, for example, looking at this film.

[tautech]

Thank you KC as I always enjoy your well reasoned and knowledgeable responses based on some real experience. 

For the Siglent, how usable the scope is with respect to making changes to the settings depends on what it's doing.  Turning on the FFT will seriously compromise its responsiveness when you operate the controls, for instance.  It's not the end of the world or anything, of course.

However with the FFT have you tried changing default settings to something that better matches competitors capabilities and notice how snappy FFT becomes ?
Maybe it's well overdue you do. 

Certainly FFT speed with default settings isn't a racehorse however offering some of the best spec in this class why does it need to be as choices are precision or speed.

[kcbrown]

However with the FFT have you tried changing default settings to something that better matches competitors capabilities and notice how snappy FFT becomes ?
Maybe it's well overdue you do. 

Certainly FFT speed with default settings isn't a racehorse however offering some of the best spec in this class why does it need to be as choices are precision or speed.

It's not the FFT speed that's the issue.  That part is very good, actually.  My point is that turning on the FFT compromises the responsiveness of the controls.  It causes the UI to drop a lot more of the encoder events.

And that's with very modest FFT settings.  32k points, Hanning window, and a starting timebase such that there are 400 points in the capture.  With this, a single click of the timebase encoder causes the scope to take about a third of a second to change the timebase.  Turn the timebase knob at more than 2 clicks per second and it'll miss events.

[kcbrown]

Let me say this ... I am dealing with relatively cheap equipment at home (Rigol, Siglent or lower models of well-known brands). They all have some shortcomings, which unfortunately are compensated by their price (although in the case of lower models of well-known brands it hurts more because for their price I could buy more equipment, eg Siglent).

Professionally, I have access to equipment that often costs hundreds of thousands of dollars, and I can see the difference - but I am aware that I cannot demand the same from equipment that costs a fraction of the cost of professional equipment.

That's certainly true.  But keep in mind that any sane manufacturer, which Siglent is, will use the same base code across their range and over time as well.

This means that changes to the base code, which includes changes to the UI processing architecture, will be applicable across all their models both now and in the future.


The way I see it, this is a question of design.  Perhaps Siglent hasn't hired someone who really knows what he's doing when it comes to architecting the UI processing code.  Or maybe the issue is even deeper than that, and has to do with how thread execution is prioritized.  Since Siglent is using a Linux kernel as their base, fixing the latter should be relatively straightforward, since they can instruct the scheduler about the relative priority of threads as well as the scheduling algorithm the kernel should use.

Fast, efficient UIs are something that the computing field at large has known how to implement for decades now.  Scopes today are executing on hardware that is equivalent in speed to state-of-the-art computers of perhaps a decade ago, if not less.  So it's not like the necessary horsepower isn't there.

[tomud]

It is a trend that program code is now written to be programmer readable and easy to develop. Unfortunately, this often translates into the fact that the code is not optimal. In the case of PC programs, this is not a problem because the customer will buy a new, faster computer. For embedded hardware, this is more complicated as a faster processor is a cost. Even one dollar saved in a device can save a million dollars in series production.

Such a thing can be noticed not only when buying Siglent, but also cheaper models of well-known companies (where you can also see the savings) - even though they often cost a lot more than Siglent. For more expensive hardware that is not produced in large quantities, adding a faster processor to make up for suboptimal code is less of a problem.

To sum up, you now want to have a nice fast measuring equipment with a small number of flaws, you have to spend a lot of money - that's the sad truth. In the past, companies cared more about the customer, now corporations only look at how much money can be pulled from the customer and we have such an effect.

[tv84]

Fast, efficient UIs are something that the computing field at large has known how to implement for decades now.  Scopes today are executing on hardware that is equivalent in speed to state-of-the-art computers of perhaps a decade ago, if not less.  So it's not like the necessary horsepower isn't there.

All true but one cannot forget that scopes are realtime devices that have timing constraints all around.

So, it's not only a matter of doing all things a lot faster. It's all about fulfilling the preemptive multitasking within a certain timeframe, be it at 1 MHz or 1 THz.

Assigning a high priority to the manual encoder just so that it doesn't loose a click may be a nightmare when we have tens/hundreds of other more important tasks. Of course we can buffer the encoder BUT, in my book, I also don't like to see all the buffered movements appear in rapid sequence just because they had been accumulating in the buffer, and now they got their turn. Since I had no way of knowing how the buffering was working, the most probable thing that would happen is that I would over turn the encoder just because I didn't have any type of visual feedback.

Providing a lossy feedback, where we loose some clicks, is sometimes the best compromise between the gamers that became TEA and the retirees who have all the time in the world to rotate an encoder at 1-click/sec.

[2N3055]

..
With this, a single click of the timebase encoder causes the scope to take about a third of a second to change the timebase.  Turn the timebase knob at more than 2 clicks per second and it'll miss events.

I have no idea how it behaves on SDS2000X+ because I don't have one.

But I can tell you those two things you mention are not necessarily connected. On my SDS6000 and SDS2000 X HD it works same as keyboard on your PC: it will capture knob clicks even if it doesn't update screen immediately. Actually, if you start moving knobs too fast it will stop screen updates and wait for you to stop moving target and decide what do you want  before it starts updating scope settings and screen. What is practical purpose for a scope to change timebase 72 times a second while you're twiddling the knob frantically...?  Any intermediate acquisitions are null and void, and user obviously doesn't want them...

In a nutshell, if I change timebase 5 steps very quickly (that is how much I can turn quickly and still know what it was, i can hear quintuples, musically) scope will pause for few 100 of ms and then it goes there. Nothing gets lost. intermediate steps (2,3 and for 4) are not being used. Vertical control too..

I'm also curious how people can turn buttons at 240 RPM equivalent speed and be certain that it was exactly 11 steps..

Funny number from a Bourns good quality equivalent encoder... MAX rotation speed 60 RPM........
Up to that max speed they guarantee bounce time 3-4ms.. That is sloow rotation, one rotation per second.