Siglent SDS2000X Plus

[blurpy]

Unlikely they set out to break their own tools. 

Let's hope so

But have you tested?

[tautech]

Unlikely they set out to break their own tools. 

Let's hope so

But have you tested?

No stock but 2 arrive next week and will have the new FW installed before they slip out the door as they're already sold.
Will test them.
Already ordered another 6 thinking the rush on these had slowed after last year's madness but now I'm not so sure another run on them is building again !
Then some businesses are also interested in the HD....there goes some more sales profits to keep them in stock too !

[blurpy]

No stock but 2 arrive next week and will have the new FW installed before they slip out the door as they're already sold.
Will test them.

Sounds good!
Can you also test if it works to select timezone on them?

[tautech]

No stock but 2 arrive next week and will have the new FW installed before they slip out the door as they're already sold.
Will test them.

Sounds good!
Can you also test if it works to select timezone on them?

Yeah of course. 
When we get them the clock is 4hrs slow, Shenzhen time vs NZ time and that gets corrected and probes assigned and compensated before we ship out. Takes but a few seconds to check any of the recent changes and actually will check this timezone thing in our SDS6204A as all I remember doing was advancing it 4 hrs......maybe I need set it to NZ also like in the NTP feature in SDS1104X-E.
Will report findings.....but for now bed calls !

[maxspb69]

General:
Vastly improved UI-response. In particular, there are hardly any dropped encoder pulses anymore. If something cannot be executed immediately, it is queued and doesn't get lost.

I would really like to see an improvement, but I can not find it - encoders also miss pulses, especially the vertical encoder. As in previous firmware. 

[Martin72]

At work we got no problems at all with the encoders and so on.
And we even didn´t have the latest firmware...

[maxspb69]

Martin, there is a problem and it is old. If you turn the encoders quickly, the oscilloscope reacts slowly. In the latest firmware, unfortunately, there are no improvements in the encoders operation.

But finally, they removed an insane amount of zeros in the grid labels. Thank you so much for this, Siglent! ))

[Martin72]

Hi,

If you turn the encoders quickly, the oscilloscope reacts slowly.

It depends what quickly in this way means, why we didn´t had problems with it so far.
As known I´ve bought three siglents and they are everyday "busy", if there was problems with them my colleagues would tell me.
But I can check this mentioned thing on monday.

[tautech]

Can you also test if it works to select timezone on them?

Dragged out SDS6204A to get a refresher course.
This is much as I remember the UI and you can access the clock settings in 2 ways, one by clicking in the clock box that also has the LAN status indicator symbol bottom right of the display or through the Utility menu.

SDS2000X Plus arriving in a couple days should have V1.3.9R12 installed and will certainly get V1.5.2R1 installed unless there's some Date/Timezone bug however we do have the beta V1.5.2 to fall back on if necessary.
Stay tuned.

[Performa01]

Version： V1.5.2R1

Although the Time Zone Setting appears on screen, I am unable to select or enter any Timezone information.

Timezone cannot be set on the SDS2000X Plus, because the drop down list is empty. It works on the SDS2000X HD though.

I have reported this to Siglent.

Apart from that, I don't think setting a timezone by selecting some capital city is the best way to do it - at least for engineers, who should know what timezone they are located at. It would be much simpler and more obvious to specify the offset in hours relative to GMT instead.

[tubularnut]

Timezone cannot be set on the SDS2000X Plus, because the drop down list is empty. It works on the SDS2000X HD though.

I have reported this to Siglent.

Thank You 

[blurpy]

Apart from that, I don't think setting a timezone by selecting some capital city is the best way to do it - at least for engineers, who should know what timezone they are located at. It would be much simpler and more obvious to specify the offset in hours relative to GMT instead.

Specifying the offset doesn't really give any advantage to just setting the time.

Time zone is how the OS handles the offset, so it also adjusts according to daylight saving time. That is a nice improvement instead of adjusting the clock (or an offset) twice a year manually.

At least as long as we have to live with the medieval time zone system we have now.

[hhappy1]

I upgraded the firmware, too.
Version： V1.5.2R1
The time zone cannot be set.

And I measured the broadband noise of the audio dac.
Of the 8-bit scope, I'm sure the noise is the best.
The sfdr is a typical 8-bit scope, about -62db.

[hhappy1]

The same setting measured by pico 4262.

[kcbrown]

General:
Vastly improved UI-response. In particular, there are hardly any dropped encoder pulses anymore. If something cannot be executed immediately, it is queued and doesn't get lost.

I would really like to see an improvement, but I can not find it - encoders also miss pulses, especially the vertical encoder. As in previous firmware. 

It's entirely possible that your encoders are noisy.  My horizontal scale encoder was, so much so that it drove me to think that the UI responsiveness in my scope was beyond horrible.

I replaced the encoders and haven't had a problem since (I took the opportunity to replace some of the free spinning encoders with detented encoders, and this made setting the trigger point and playing with the cursors, among other things, much better).  Note that the encoders that Siglent uses for the vertical and horizontal scales have their pins reversed relative to most encoders.  This made replacement a lot more annoying than it would have been otherwise.

I detailed the ordeal starting here: https://www.eevblog.com/forum/testgear/new-electricalcomputer-engineer-student-test-bench-equipment-recommendations/msg4091812/#msg4091812

And here's where I show the noise generated by the bad encoder: https://www.eevblog.com/forum/testgear/new-electricalcomputer-engineer-student-test-bench-equipment-recommendations/msg4099678/#msg4099678

[roberthh]

I just noticed that the :PRINT command from the SCPI command set does not work anymore. I used that for a small script which captures a screen, for command line use. Yes, I know that thsi is possible with the web interface as well.

[Geoff-AU]

Time zone is how the OS handles the offset, so it also adjusts according to daylight saving time. That is a nice improvement instead of adjusting the clock (or an offset) twice a year manually.

Except for when your country changes its daylight saving rules, and the scope manufacturer hasn't applied the latest timezone updates to their firmware, and then you have to adjust the clock 4 times a year.

It's entirely possible that your encoders are noisy.  My horizontal scale encoder was, so much so that it drove me to think that the UI responsiveness in my scope was beyond horrible.

Hmm I need to check my encoders.  It feels like horrible UI responsiveness to me too.

I did recently replace encoders on my Korad power supply, that was an obvious encoder problem because the setting would "bounce" back to its original value when spinning the encoder and then suddenly make a huge jump.  Like 5V->5V->5V->5V->5V->14V.  Eek.

My Siglent is just really slow.  Actually it feels like the encoder equivalent of a computer mouse with very slow "speed" and very high "acceleration".  If I turn the encoder quickly the scope moves quickly but if I turn the encoder slowly the scope moves far too slowly for my preference.

Meh.  It's OK I guess.

[tautech]

Please, please.....it sounds from recent posts there are some encoder issues however no one can know which HW revision any of you have. 

Please, give further full info about your particular unit, FW version and HW version too and not just a bitching session but a proper description of what you experience, exactly how to replicate your experience and unless you do a factory Default or post a Setup file for Siglent to load into the same HW unit so to properly assess the problem and develop a remedy.
Best advice is to do a Factory Default and then report the problem in detail in a post or in an attachment.

Siglent don't need your SN# but most of the code is of assistance...like this:
SDS2PDDD5R3***

If we want improvements we must also contribute with good quality feedback.
Thank you.

[blurpy]

Time zone is how the OS handles the offset, so it also adjusts according to daylight saving time. That is a nice improvement instead of adjusting the clock (or an offset) twice a year manually.

Except for when your country changes its daylight saving rules, and the scope manufacturer hasn't applied the latest timezone updates to their firmware, and then you have to adjust the clock 4 times a year.

It's a risk of course. If that happens,  set GMT as the time zone and change the time manually twice a year like we do today.

[kcbrown]

Hmm I need to check my encoders.  It feels like horrible UI responsiveness to me too.

For me, in hindsight, the telltale was that with only one channel active, all measurements turned off, cursors turned off, and the timebase set to something relatively fast (like 1 microsecond), it would randomly fail to detect that I'd turned the encoder even when I turned it only one click.

With the encoders replaced, it is 100% reliable at detecting that.  If I turn the encoder relatively quickly, such that I get, say, 10 clicks per second or so, then it will miss some of the clicks.  This seems to be because of the processing loop it uses.  In particular, it seems it detects the click, then performs the change, and only after the change has completed will it listen for more clicks.


So the question for the board here is: does the latest firmware change that, such that you can *reliably* move the encoder by, say, 6 clicks in less than half a second, and be guaranteed to get a 100x change in timebase?

My Siglent is just really slow.  Actually it feels like the encoder equivalent of a computer mouse with very slow "speed" and very high "acceleration".  If I turn the encoder quickly the scope moves quickly but if I turn the encoder slowly the scope moves far too slowly for my preference.

For detented encoders, the amount it should move for one click of the encoder is whatever one step is.  The timebase and vertical scale encoders are the only ones that are detented.  Those shouldn't have an acceleration curve applied to them at all.

The other encoders, e.g. the ones that shift the position of the waveform, might well have an acceleration curve applied to them in software.  That'll complicate how the scope responds.

I don't (and didn't) seem to have any issues with my non-detented encoders.  I ended up replacing the multifunction encoder and the trigger level encoder with detented encoders because those functions need the precision that detents bring to the table.

Meh.  It's OK I guess.

If you wind up opening up the scope in order to do anything about the encoders, then I recommend that you:

* Replace the multifunction encoder and the trigger encoder with detented encoders

* Perform the (very minor) modification to the plastic front panel that I described here: https://www.eevblog.com/forum/testgear/new-electricalcomputer-engineer-student-test-bench-equipment-recommendations/msg4124305/#msg4124305

The latter is linked to by Rob's instructions on how to disassemble the scope, here: https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4176037/#msg4176037

Note, too, that if you end up replacing the timebase and vertical scale encoders, then you'll almost certainly have to perform a modification to reverse the two outer pins, because the encoders Siglent uses for those has those pins reversed (I have no idea why they did that.  It beggars belief).  See https://www.eevblog.com/forum/testgear/new-electricalcomputer-engineer-student-test-bench-equipment-recommendations/msg4091812/#msg4091812

[kcbrown]

Please, please.....it sounds from recent posts there are some encoder issues however no one can know which HW revision any of you have. 

Please, give further full info about your particular unit, FW version and HW version too and not just a bitching session but a proper description of what you experience, exactly how to replicate your experience and unless you do a factory Default or post a Setup file for Siglent to load into the same HW unit so to properly assess the problem and develop a remedy.
Best advice is to do a Factory Default and then report the problem in detail in a post or in an attachment.

For mine, the firmware version is 1.3.9R6, UBoot 5.0, and the hardware version is 02-04, CPLD 03.

I don't intend to change the firmware to the latest version until I have some sort of confirmation that it's at least as stable as the version I'm on, because as I understand it, once I upgrade to the current version, there's no going back to the version I'm on.

Of course, I'm not experiencing the original hardware-induced issue anymore since I replaced my encoders.  But the scope will miss encoder events if I turn the knob relatively quickly, and now that I know that my encoders are good, I'm positive it's a firmware implementation artifact.  The scope catches all the "clicks" of the encoder if I turn it slowly enough.

Siglent don't need your SN# but most of the code is of assistance...like this:
SDS2PDDD5R3***

For mine, that's SDS2PDDD4R1***

[tautech]

For mine, the firmware version is 1.3.9R6, UBoot 5.0, and the hardware version is 02-04, CPLD 03.

I don't intend to change the firmware to the latest version until I have some sort of confirmation that it's at least as stable as the version I'm on, because as I understand it, once I upgrade to the current version, there's no going back to the version I'm on.

Of course, I'm not experiencing the original hardware-induced issue anymore since I replaced my encoders.  But the scope will miss encoder events if I turn the knob relatively quickly, and now that I know that my encoders are good, I'm positive it's a firmware implementation artifact.  The scope catches all the "clicks" of the encoder if I turn it slowly enough.

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

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

[Martin72]

Hi,

In the two yrs I´ve owned the 2k+, I never had a problem with the encoders.
In this year, as we got some 2k+ here at work, none of my colleagues got a problem with them too(or didn´t tell me).
So reading here about it for the first time surprised me.
But as I´ve read this:

say, 10 clicks per second or so,

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....

[james38]

I am also al little bit surprised and still don't established any problems with the encoder yet.
May be i am a bit to slow ;-)

When i turn the knob i don't want to win a record unless you
want to be in the guiness book of records.

What possibly can be happened is when the scope do many
measurements at the same time that he loses some signals of the encoder.

That would be the only reason for me.

Regards Chris

[vicki20july]

Hi

Just wondering if approx. 250 micro-volts of DC offset is normal for SDS2000X Plus. My oscilloscope shows approx. 250 uV DC offset noise without any probes being plugged in. See attached images for 1mv/div and 500uv/div. In the attached image, channel 1 in yellow has the highest offset and channel 2 in magenta has almost negligible offset. The DC offset amount stays the same even if I remove / reset the manual vertical offset which i added for clarity and easy viewing.

Sometimes it happens that the DC offset is not present when i turn on the oscilloscope but it develops an offset within the first 10 - 20 minutes of operation may be due to warmup. I have performed self calibration multiple times, even at different locations within my home. The self-calibration would fix the DC offset of some channels and it would mess it up by anywhere between 100 - 300 uVolts for some other channels. I have also tried AC coupling & 50 Ohm impedance mode, but nothing helps in removing offset for all channels.

I have also attached an image after one of the calibration attempts. Now, it has fixed the DC offset for Channel 1 (which was the worst before) and Channel 3 but channel 2 in magenta and channel 4 in green got a little messed up. Please advise if this is normal behaviour? Does your SDS2000X Plus behaves in similar manner? How can I fix this DC offset issue for all channels? Is there something wrong with the scope?

Thank you