Siglent SDS2000X Plus

[OneGeekGuy]

Thanks Martin!! I missed completely the datasheet, I was focused on online specs...

Regards!

[KungFuJosh]

Hi everyone!

Owner of SDS2000X Plus could tell me which are the dimensions of the oscilloscope?

Thinking about upgrade my current DS1054Z to this Osci....so far for the price is one of the best option you can get.

Thanks!!

Dimensions are on page 9 of the quick start guide: https://siglentna.com/wp-content/uploads/dlm_uploads/2019/12/SDS2000X-Plus_QuickStart_QS0102XP_E01A.pdf

You'll love the scope. I didn't personally like the 1054Z, so I switched from that to the SDS1104X-E before eventually upgrading to the SDS2504XP.

[tautech]

Hi everyone!

Owner of SDS2000X Plus could tell me which are the dimensions of the oscilloscope?

See P16 of the datasheet:
https://int.siglent.com/u_file/download/22_09_19/SDS2000X%20Plus_Datasheet_EN01C.pdf

[ebastler]

I've been thinking (too much... ) about my next scope to get, and the SDS2000X plus is probably the strongest contender in my price range. But I now stumbled upon a UI detail that seems quite annoying. Hence I am wondering whether that's still "state of the art" in the current firmware, and whether there are similar delays in other interactions with the scope.

Youtube user Uni-Byte shows how one can capture a full memory buffer of data at a slow timebase, and zoom in and pan around to look into details. Nice, and probably how I would intuitively look at data much of the time. (Rather than using Zoom or History mode.) But as he shifts the displayed trace section left and right, there is always a very noticeable delay before the new trace segment gets redrawn. Shown from approx. 1:30 onwards:



Is that the status quo using current firmware? Does it work more smoothly if you enable Zoom mode? Are there other situations where screen redraw becomes so noticeable?

Thanks for your observations!

[Performa01]

Is that the status quo using current firmware? Does it work more smoothly if you enable Zoom mode? Are there other situations where screen redraw becomes so noticeable?

It is the status quo and it is a property of this platform.

Up to 10 Mpts you don't see any delays. Beyond that, there is this slight delay as seen in the video, of course also in zoom mode.

The reason is some limitation of the access window to the acquisition memory and/or the size of the internal fast RAM. This means a total of at least 80 MB since the 10 Mpts are per channel and this is true for the 10 bit mode (which makes the entire acquisition memory 16 bits wide) as well, so we get 20 MB per channel.

It's not a big deal though. Most of the time, 10 Mpts will be plenty. In the situations where we need more, we need to use more efficient access techniques to the detail of interest anyway. Instead of scrolling all the way through the buffer, we use zoom mode and just drag the selection rectangle in the main window. Once you've tried that, you'll never touch the horizontal position control again

We don't have that limitation in the SDS2000X HD, hence no visible delay even at 200 Mpts.

[ebastler]

Up to 10 Mpts you don't see any delays. Beyond that, there is this slight delay as seen in the video, of course also in zoom mode.

The reason is some limitation of the access window to the acquisition memory and/or the size of the internal fast RAM. This means a total of at least 80 MB since the 10 Mpts are per channel and this is true for the 10 bit mode (which makes the entire acquisition memory 16 bits wide) as well, so we get 20 MB per channel.

Thank you for the confirmation and explanation! It reads like something they could work around by speculatively pre-fetching a screenful of data to the left and right of the current window into fast memory, to be prepared in case the user wants to look there? But I agree, not a big deal if the redraw pause only occurs at very large total buffer sizes.

There is no related delay in real-time (Run) mode, right? I.e. if I move the trace position horizontally or vertically in Run mode, the trace will follow without lag?

We don't have that limitation in the SDS2000X HD, hence no visible delay even at 200 Mpts.

Oh yes, that would be the "no compromises" choice for me... But I don't think I can justify that expense for a hobby tool/toy; the 2000X plus is already pushing the range I feel comfortable with.

[Performa01]

There is no related delay in real-time (Run) mode, right? I.e. if I move the trace position horizontally or vertically in Run mode, the trace will follow without lag?

Why would you expect it to be better in Run mode - after all Stop mode should be the easier one?

And so it is.

• We don't have any delays in the vertical direction, no matter what scope model and regardless if in Run or Stop.
• We don't have any delay moving the originally visible screen content in horizontal direction. But there opens a gap where new content has to be added - and this always happens after a short delay in Run mode, independent of the record length. There has to be some delay - after all this data has to be acquired first!
• On SDS2000X Plus we have the same behaviour also in Stop mode at record lengths >10 Mpts.
• On SDS2000X HD we get the gaps filled without visible delay in Stop mode, no matter the record length (if there is more data available, that is).
• In Zoom mode, even during Run, we have the same behavior as in Stop mode, i.e. only a delay filling the gap on the SDS2000X Plus and only for records longer than 10 Mpts.

[ebastler]

Why would you expect it to be better in Run mode - after all Stop mode should be the easier one?

I had expected Run mode to be unaffected since, in my understanding, it only acquires a screenful of data anyway -- hence I thought the "deep memory" access with its wait time would not apply.

Thank you very much for the details in any case! It's not a severe limitation, but still a bit disappointing to bump into things my measly DS1054Z does better... It may be an indication of Siglent's focus on powerful analysis, where interactive viewing and manipulation occasionally take the back seat? Like with the lack of a horizontal vernier, which also was a bit surprising to me.

[KungFuJosh]

Thank you very much for the details in any case! It's not a severe limitation, but still a bit disappointing to bump into things my measly DS1054Z does better...

That 1054Z doesn't do anything better; it's a toy by comparison. The delays that exist on the 2000XP series are only for long acquisition over 10Mpts. The 1054Z max is 24Mpts total (in Deep Memory mode) compared to the 2000XP's 200Mpts. The only reason the 1054Z might seem fast (it's not) is that it simply isn't capable of acquiring that much data.

[ebastler]

That 1054Z doesn't do anything better; it's a toy by comparison. The delays that exist on the 2000XP series are only for long acquisition over 10Mpts. The 1054Z max is 24Mpts total (in Deep Memory mode) compared to the 2000XP's 200Mpts. The only reason the 1054Z might seem fast (it's not) is that it simply isn't capable of acquiring that much data.

I did not mean to be provocative there, sorry if I touched a nerve. Yes, obviously the DS1054Z is a much more limited scope. But if I acquire a full 24 MPts of data and then zoom in, it does let me pan back and forth without redraw delays. Which is why I kind of took this behavior for granted and was a bit surprised to see the delays in the SDS2000X+. No worries, it's not a deal breaker! 

[KungFuJosh]

I did not mean to be provocative there, sorry if I touched a nerve. Yes, obviously the DS1054Z is a much more limited scope. But if I acquire a full 24 MPts of data and then zoom in, it does let me pan back and forth without redraw delays. Which is why I kind of took this behavior for granted and was a bit surprised to see the delays in the SDS2000X+. No worries, it's not a deal breaker! 

lol, it's not you. I had the 1054Z briefly and absolutely hated it. I switched to an SDS1104X-E and was much happier before switching to the SDS2504XP, which has only improved...everything. Though I'm still waiting on that firmware update to get rid of the annoying notice left on the screen after screen captures. 🤣

[Performa01]

Why would you expect it to be better in Run mode - after all Stop mode should be the easier one?

I had expected Run mode to be unaffected since, in my understanding, it only acquires a screenful of data anyway -- hence I thought the "deep memory" access with its wait time would not apply.

Like most other DSOs, the SDS2000X stops acquisition while the users move the trace around on the screen. It resumes after a short timeout and only then the gap can be filled. By contrast, in Stop mode acquisition is not running anyway, all the data is already there, hence also no delay (except for the data exceeding 10 Mpts in the SDS2000X Plus).

Thank you very much for the details in any case! It's not a severe limitation, but still a bit disappointing to bump into things my measly DS1054Z does better... It may be an indication of Siglent's focus on powerful analysis, where interactive viewing and manipulation occasionally take the back seat? Like with the lack of a horizontal vernier, which also was a bit surprising to me.

We often see such complaints.

Users that come from some old analog CRT-oscilloscope - or older digital scopes - are disappointed that with their shiny new DSO they can't just enable X-Y mode without bothering with the timebase (which is just disabled on an analog scope in X-Y mode).
And why can't they have their beloved alternate trigger (to watch two unrelated traces at the same time) and why the heck isn't there an ETS-mode available, as even the old Rigol DS1052E had?

We cannot even be surprised, because one needs to know a bit about the internals of oscilloscopes to understand the reasons why progress does not always mean just additional features but can also lead to different solutions. Sometimes it looks like a step back, but almost always a rationale can be found for it.

The most important aspect for any UI is a timely reaction on user actions. You get this on the SDS2000X Plus: as soon as you try to move the trace, no matter what direction, and no matter whether you use a touch gesture or the position knob for this, the trace will follow almost instantly. It's just the gap that needs a little time to be filled under certain circumstances.

Folks have complained that the DS1000Z cannot even move the traces vertically without delayed jumps, so it's hard to believe that it can do it smoothly in the horizontal direction. Maybe it does when you use a fixed memory length, so that no new acquisition is required. But in a setting like this, an SDS2000X HD renders smooth and gapless (and without any jumps) of course.

[ebastler]

We often see such complaints.

Users that come from some old analog CRT-oscilloscope - or older digital scopes - are disappointed that with their shiny new DSO they can't just enable X-Y mode without bothering with the timebase (which is just disabled on an analog scope in X-Y mode).
And why can't they have their beloved alternate trigger (to watch two unrelated traces at the same time) and why the heck isn't there an ETS-mode available, as even the old Rigol DS1052E had?

We cannot even be surprised, because one needs to know a bit about the internals of oscilloscopes to understand the reasons why progress does not always mean just additional features but can also lead to different solutions. Sometimes it looks like a step back, but almost always a rationale can be found for it.

That feels a bit unfair and like you are writing me off as "uninformed and stubborn old-timer". I am not comparing to analog scopes, but to other digital scopes which sometimes make different design choices.

I am not saying one choice is better than the other, but there still seem to be two schools of thought -- let's call them the LeCroy vs. Keysight school. While they have come closer to each other over the years, one seems to focus on "detailed and powerful analysis after careful setup and acquisition", while the other puts more weight on "moving around interactively and exploring, to figure out what's going on in the DUT".

It does not really matter to the user whether limitations in one or the other flavor of scope are due to fundamental architectural constraints, or due to the desire not to overload the UI with too many options, or simply due to limited capacity in the software development teams. In the end there are some limitations, it's good to be aware of them, and be aware of one's preferences when making a purchasing decision.

[Performa01]

That feels a bit unfair and like you are writing me off as "uninformed and stubborn old-timer".

Sorry - I absolutely didn't mean it that way. I don't know your history and have never assumed anything.

All I wanted to say is that we've seen many complaints about a new instrument, just because it is a little (or even fundamentally) different in certain regards than what we are used to, so that they might lack some beloved feature (or we need to adapt to different habits). And it happened to me too.

I just gave a few examples of perceived (or sometimes real) drawbacks in modern instruments, that come with new technologies, like real-time oscilloscopes (which require not only a high max. sample rate but also deep memory) with fully digital trigger engines (which has made ETS unavailable). And of course there are other things like alternate trigger, which died with the introduction of digital trigger engines, even though it would still be possible to implement it - just with an effort so high that it just isn't worth it.

Yes, in the end it doesn't matter for the user. The user wants certain features and doesn't care why they cannot get it in certain instruments. This will of course affect their choices.

Apart from all that I still stand by my statement that it's hard to believe that a DS1000Z of all things, where lots of people have complained about the laggy trace positioning (and I've even seen videos demonstrating that) should outperform the SDS2000X Plus. Even though - have you watched the video you've linked before any further? The humble little SDS1000X-E had no lag when filling the gap. According to the explanation I've given earlier, the max. record length of only 14 Mpts is below this mystical 20 MB/channel limit, so no surprise here.
 

[MathWizard]

If you aren't going to use the scope, or other Siglent equipment for a few days or more, is there any downside to fully unplugging them ? I thought I noticed the clock didn't change when I had it unplugged (2104x-p). I don't care about that. I think I read there's no internal battery ?

Sometimes I'll go a month or longer without using a scope or AWG. And I don't like leaving them plugged in. My SDS1204x-e is basically in storage since I got the 2104xp. Should I plug it in sometimes ? Is there any ROM or something that needs power once and a while ? (my poor old 1980's scopes, I haven't used them in 3yrs, I better use the variac when powering them up next, just to be safer)

[tautech]

If you aren't going to use the scope, or other Siglent equipment for a few days or more, is there any downside to fully unplugging them ? I thought I noticed the clock didn't change when I had it unplugged (2104x-p). I don't care about that. I think I read there's no internal battery ?

No, these have a RTC with IIRC a CR2032 coin cell.

Sometimes I'll go a month or longer without using a scope or AWG. And I don't like leaving them plugged in. My SDS1204x-e is basically in storage since I got the 2104xp. Should I plug it in sometimes ? Is there any ROM or something that needs power once and a while ? (my poor old 1980's scopes, I haven't used them in 3yrs, I better use the variac when powering them up next, just to be safer)

Nothing to worry yourself over on these, no RTC and if for some dumb reason they boot freeze we have the means to recover them.

[KungFuJosh]

If you aren't going to use the scope, or other Siglent equipment for a few days or more, is there any downside to fully unplugging them ?

My scope, bench meters, etc... are all on a power strip that gets turned on only when they're in use. I've never had any issues. I don't want to waste money powering standby modes like my LCR that likes to have a red light on the power switch and never be 100% powered off.

[MathWizard]

Ok thanks, if I cleaned up a bit, I can fit both scopes on the desk, but in general I just don't need all those channels.

OK so no clock on the 1204x-e.

I read on the 2104x-p you can change trace colors. When in FFT, can you change either the trace color or the dB and Hz overlay ? Right now both are white or near white, and overlap too easily. I'd change the axis numbers to something darker.


Yeah I do the same sometimes. We don't get much lightning, but it's safer, and then the PSU isn't wasting away either.

[ebastler]

Following up on the discussion of waveform update rates which has started in the 2000X HD thread, but should really be here (to the extent it refers to the 2000X+).

I've identified several bugs:

• In Dots display mode, the selection of x versus sin(x)/x should be irrelevant. Other scopes based on the same platform show a correct behavior in this regard.
• Waveform update rate generally is a bit on the slow side, and there is a huge difference between x interpolation and sin(x)/x reconstruction. This problem does not exist in an  e.g. SDS6000A.
• Auto Trigger does not work as expected. it is slow and erratic if there's no signal present, e.g. for noise measurements.
• Mains Line Trigger does not work as expected. it only provides about 9 triggers per second on a 50 Hz grid.

All the above bug reports have been accepted by Siglent, entered into their bug-database and will be corrected with the next firmware.

Have these indeed been corrected? I looked through the firmware release notes, and could not find any relevant changes mentioned in the 2022 and 2023 releases.

[Martin72]

Siglent (and not only Siglent) is known for not listing all improvements.
The only thing that helps is to try it out, I might be able to do it tomorrow at work, but I can't promise.

[Martin72]

I kept getting distracted by it today, so I took one with me now, over the weekend. 

[Performa01]

All the above bug reports have been accepted by Siglent, entered into their bug-database and will be corrected with the next firmware.

Have these indeed been corrected? I looked through the firmware release notes, and could not find any relevant changes mentioned in the 2022 and 2023 releases.

Well, as Martin says, Siglent does not always list all changes, bug fixes and even new features in the history. As a volunteer I cannot know the exact strategy, but I think that only bug reports and feature requests from customers are listed, whereas internal reported bug reports / change requests are omitted. And it seems that they sometimes treat my reports as “intern”, even when I’ve published the fact that these reports exist.

On the other hand, I’ve never got a confirmation that anything has been fixed in this regard. Instead of asking, I thought I’d better find out by myself. The most important conclusion first: it turns out that the old tables published by rf-loop are still valid and I get quite similar results.

The original complaint was that there shouldn’t be any difference between x-interpolation and Sinc-reconstruction in dots display mode. Back then, this was true for the SDS2000X HD and the SDS6000. But in the meantime, quite unexpectedly things have turned the other way round: now at least the SDS2000X HD behaves the same as the SDS2000X Plus.

So there is a difference – where does it come from?

Here’s my educated guess: I’ve stated before, that we still need Sinc reconstruction for the digital trigger path. Back when I reported this bug, I’ve already suspected that the folks at Siglent have experimented with variable trigger handling, where they let the users decide whether they want (or need) a full Sinc reconstruction or can make do with a simple x-interpolation. If we make that choice for the display mode, everything seems clear: if we can live with the coarse and often incorrect result of an x-interpolation on the screen, then we shouldn’t need Sinc for the exact trigger point either. X-interpolation would have little performance advantage, if Sinc is always used in parallel for the trigger path. Furthermore, if we place the trigger at the vertical center of a sine, there will be no difference anyway. The same goes for most other standard waveforms.

[Martin72]

now at least the SDS2000X HD behaves the same as the SDS2000X Plus.

Beautyful...

[Martin72]

Acclimating the SDS2104X+, maybe tomorrow when time allows I could measure the wfms/s.

[rf-loop]

The original complaint was that there shouldn’t be any difference between x-interpolation and Sinc-reconstruction in dots display mode. Back then, this was true for the SDS2000X HD and the SDS6000. But in the meantime, quite unexpectedly things have turned the other way round: now at least the SDS2000X HD behaves the same as the SDS2000X Plus.

Here (tiny) example about SDS2000X HD

[Image removed]

Revised new image is added to SDS2000X HD thread

https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg5176800/#msg5176800


(this is tiny "sample" from big table about wfm/s what include also Sequence mode and include also some different memory settings and also channels in use (other than just one alone).
But I can not publish this table where is more things yet because I have not revised it after some FW changes and this is very time consuming work specially with Sequence mode for find not average speed but very importantly maximum guaranteed speed because also it have or may have some small speed variations during Sequence)
Only this tiny part of table is revised. (now also in right place: SDS2000X HD thread)
And yes, also using display mode dots, speed have some differeces if Sinc is on or off. (and of course Sinc do not manipulate sample dots vertical values and do not add interpolated dots between true dots.)

But as we know also in dots mode trigger position need interpolate between true samples but I do not want speculate details...

ETA: removed image and better image added to SDS2000X HD thread.