REVIEW - Siglent SDS2000 series - A Comparison of Features with Rigol DS2000

[Siglent]

marmad, nctnico, don, can we summarize the required fixes?

IMO, the most immediate necessary additions/changes for the DSO portion (aside from obvious bug fixes) would be:

1) Get the main Acquisition modes working properly (i.e. High Res mode and Peak Detect BEFORE downsampling).
2) Add some functions to make Sequence mode usable as a tool: adjustable speeds for playback, 'Overlay All', etc.
3) Remove the code which disables the selected item for the Universal knob when the Trigger knob is turned (or bumped). This would immediately stop the very annoying behavior of 'losing' what you're adjusting when turning the Universal knob by accidentally nudging the too-close Trigger Level knob (which happens to me regularly).

On a more fundamental level, I don't like Siglent's implementation of slower timebases in Y-T mode (at least, when combined with the way the DSO behaves while waiting for triggers). What this means is that when you're working at a slow timebase, the DSO draws nothing on the display until the entire acquisition is finished (regardless of trigger position - e.g. 7 seconds at 500ms/div) - during which, changing certain settings (e.g. trigger position, channel scale, etc) keeps resetting the trigger (so, of course, re-starting the acquisition), but doesn't change the display of the last captured waveform on the screen.

So you can be adjusting settings for a long time at slower timebases - with no visual feedback of either the last acquired waveform moving onscreen - or seeing a newly acquired waveform appearing past the trigger point. It makes working at slower timebases in Y-T mode quite frustrating.

Later:
1) I think Siglent needs to think of a more elegant solution for doing intensity grading at lower wfrm/s.
2) Add measurements for Math waveforms.

All the questions you mentioned have been reported to the R&D department,  thank you for helping us to improve the product.

[marmad]

All the questions you mentioned have been reported to the R&D department,  thank you for helping us to improve the product.

Thanks for the response.

[marmad]

BTW, I forgot to mention another nice little feature I appreciated that the Siglent has (that's lacking on the Rigol DS2000) and that's the settings for the Trigger Holdoff.  You can set a Holdoff time, (which will be saved), and then just turn Holdoff ON / OFF, without losing or changing that time - while the Rigol requires you setting the time back to the minimum (100ns) to disable the Holdoff.

[marmad]

Here are some images illustrating one of the SDS2000's problems with it's Peak Detect acquisition mode.

A pair of 10ns pulses are sent to both scopes @ 50ms/div while in zoom mode. Both DSOs are triggered by the pulses, but only the Rigol displays the pulses correctly - even at the magnified view of 200ns/div.

[tautech]

Strange.
Mark, can I make some observations that will lead to a question?

Both scopes have trigger set for a rising edge.
The images indicate differing vertical attenuation in DSO settings.
Both scopes show the Trig level outside the amplitude of the pulse.

If these details are corrected, is there any difference in the displayed result?

[marmad]

Both scopes show the Trig level outside the amplitude of the pulse.

No, the trigger level is within the amplitude of the actual pulse, as seen on the Rigol. Although you can't see the orange trigger indicator (hidden because of the side menu), you can see the trigger line in the upper window on the Rigol.

If these details are corrected, is there any difference in the displayed result?

The Rigol always displays the pulses virtually the same - but it varies on the Siglent, sometimes showing it as it appears on the Rigol - sometimes displaying it as seen in the image - and other variations in-between. But the trigger level doesn't affect the display.

[tautech]

Thanks Mark, just wanted to expand on your demonstration of the bug for Siglent to see.

[marmad]

Some thoughts on the EasyScopeX control software / SCPI implementation on the Siglent SDS2000 series:

I quite liked the EasyScopeX software - simple and effective - it did what it was supposed to do, and was a reasonably fast and bug-free control interface. Thumbs up - and kudos to Siglent for providing some simple control software which is sorely lacking on the Rigol UltraVision scopes.

Using SCPI commands was a different story. From reading the programming manual, I have to say that their SCPI implementation seems more powerful (and likely faster) than Rigol's. For example, when setting up a waveform transfer, they allow you to specify the relative address of the frame (segment) number to transfer - whereas on the Rigol, you have to command the DSO to move to each frame before transferring the memory. And there are other features which are accessible via SCPI commands which are completely inaccessible on the Rigol DS2000.

But in practice, when testing out various commands, I found it very easy to either lock-up the DSO, requiring a re-boot - or screw-up the SCPI link, requiring re-starting the SCPI software. The Rigol implementation, although less powerful (and still lacking some features / having some bugs as late as in FW v.#3), is much more robust and difficult to hang - even when sending incorrect / inappropriate commands.

So I commend Siglent on their commitment to a broad and powerful SCPI set - but they need to do more debugging and testing to insure a graceful recovery from errors and SCPI command/typing mistakes.

[AlfBaz]

For example, when setting up a waveform transfer, they allow specifying the frame (segment) number to transfer - whereas on the Rigol, you have to command the DSO to move to each frame before transferring the memory. And there are other features which are accessible via SCPI commands which are completely inaccessible on the Rigol DS2000.

Curious if they use what's known as definite length command protocol where as part of the parameters you get or send a number represienting the length of the number describing the number of data bytes, followed by the data

But in practice, when testing out various commands, I found it very easy to either lock-up the DSO, requiring a re-boot - or screw-up the SCPI link, requiring re-starting the SCPI software.

If it is the type of command i described, they easily stuff things up if the data block is not exactly the same size as set in the params, due mainly to the text parser kicking in and trying to translate random data, which if you are really unlucky can do some damage

[marmad]

Curious if they use what's known as definite length command protocol where as part of the parameters you get or send a number represienting the length of the number describing the number of data bytes, followed by the data

Well, the programming manual is not officially published yet, but I was lent a copy from a friendly source. I can't release it, but perhaps I can post a small bit here. The parameters for waveform transfer setup for are as follows:

Sparsing (SP): The sparsing parameter defines the interval between data points. For example: SP = 0 sends all data points SP = 1 sends all data points SP = 4 sends every 4th data point

Number of points (NP): The number of points parameter indicates how many points should be transmitted. For example: NP = 0 sends all data points NP = 1 sends 1 data point NP = 50 sends a maximum of 50 data points NP = 1001 sends a maximum of 1001 data points

First point (FP): The first point parameter specifies the address of the first data point to be sent. For waveforms acquired in sequence mode, this refers to the relative address in the given segment. For example: FP = 0 corresponds to the first data point FP = 1 corresponds to the second data point FP = 5000 corresponds to data point 5001

If it is the type of command i described, they easily stuff things up if the data block is not exactly the same size as set in the params, due mainly to the text parser kicking in and trying to translate random data, which if you are really unlucky can do some damage

Well, I was able to cause problems without trying any complicated parameter settings / data transfers. Just sending a simple command at the wrong moment - or making a typo - could sometimes gum up the works.

[AlfBaz]

Well, the programming manual is not officially published yet, but I was lent a copy from a friendly source. I can't release it, but perhaps I can post a small bit here. The parameters for waveform transfer setup for are as follows:

Sparsing (SP): The sparsing parameter defines the interval between data points. For example: SP = 0 sends all data points SP = 1 sends all data points SP = 4 sends every 4th data point

Number of points (NP): The number of points parameter indicates how many points should be transmitted. For example: NP = 0 sends all data points NP = 1 sends 1 data point NP = 50 sends a maximum of 50 data points NP = 1001 sends a maximum of 1001 data points

First point (FP): The first point parameter specifies the address of the first data point to be sent. For waveforms acquired in sequence mode, this refers to the relative address in the given segment. For example: FP = 0 corresponds to the first data point FP = 1 corresponds to the second data point FP = 5000 corresponds to data point 5001

It's not entirely clear from that text wether SP, NP and FP are single commands or arguments to one. If it's the former it's a fairly typical way to set up the data prior to sending or receiving it, usually followed by another command that executes the transfer

Well, I was able to cause problems without trying any complicated parameter settings / data transfers. Just sending a simple command at the wrong moment - or making a typo - could sometimes gum up the works.

This may or may not be the problem. When you start receiving the data (assuming some sort of IEEE-488 compliance) there is usually a preamble of info that defines the data block length. Here's a quote from a tek scope manual. The format is the same on a lecroy scope

<BLOCK> is the waveform data in binary format. The waveform is
formatted as: #<x><yyy><data> where <x> is the number of
characters in <yyy>. For example, if <yyy> = 500, then <x> = 3,
where <yyy> is the number of bytes to transfer. See Block Arguments
on page 2–12.
If width is 1, then all bytes on the bus are single data points. If width
is 2, then all bytes on the bus are 2-byte pairs.

So if you only read 100 bytes but the <yyy> field equalled 200 then the scope is still in data send mode until all 200 bytes are read by the PC. What the scope does with commands whilst in this "data mode" is most likely undefined. Worst still, if you are sending the scope data and for some reason it's only expecting 100 bytes but you have attempted to send it 200, after the initial 100 bytes are read in as data the scope's command parser would kick in and try to "understand" the data as commands potentially causing havoc

[marmad]

It's not entirely clear from that text wether SP, NP and FP are single commands or arguments to one. If it's the former it's a fairly typical way to set up the data prior to sending or receiving it, usually followed by another command that executes the transfer

They are arguments to the waveform setup command (or setup query).

When you start receiving the data (assuming some sort of IEEE-488 compliance) there is usually a preamble of info that defines the data block length.

Yes, I know how to use SCPI commands for control of DSOs fairly well. I've posted a few pieces of software in this forum written specifically for that purpose - such as this one.

But the problems I was seeing were not things which you would expect to screw things up - like me botching a data transfer (either intentionally or not) - they were things like the DSO all of a sudden refusing to respond to further commands for no apparent reason - or locking-up due to a typo on a simple query. The SCPI implementation in the current FW version of the Siglent feels not quite stable yet and prone to some problems.

[AlfBaz]

Yes, I know how to use SCPI commands for control of DSOs fairly well.

My apologies Mark and thanks for this detailed thread, it has peaked my interest in this scope and patiently await to see how and what siglent address in upcoming firmware updates. Cheers

[marmad]

Yes, I know how to use SCPI commands for control of DSOs fairly well.

My apologies Mark and thanks for this detailed thread, it has peaked my interest in this scope and patiently await to see how and what siglent address in upcoming firmware updates. Cheers

No apologies necessary; I just wanted to let you know that I've had some experience with SCPI    Unfortunately, I didn't have enough time to really test the SCPI commands in-depth and make a detailed bug list. As with the rest of Siglent's firmware, there is a lot of potential in their implementation - it just seems to need more work at the moment.

[Hydrawerk]

Any news?

[nctnico]

Nope. Still waiting for Siglent to get the firmware sorted.

[tautech]

Nope. Still waiting for Siglent to get the firmware sorted.

Just been to Siglent China while abroad and expressed the urgency of this update to get the SDS2000 to an acceptable level of functionality.
A date that had been indicated has now passed and I like others await this eagerly for my own unit plus if sorted properly should re-awaken interest in a well spec'ed DSO.

[Mark_O]

Nope. Still waiting for Siglent to get the firmware sorted.

Just been to Siglent China while abroad and expressed the urgency of this update to get the SDS2000 to an acceptable level of functionality.
A date that had been indicated has now passed and I like others await this eagerly for my own unit plus if sorted properly should re-awaken interest in a well spec'ed DSO.

How did they respond to that?  Did they provide any explanation for the lack of progress, on critical updates to a shipping product?  Any realistic time-frame to expect this functionality to eventually be delivered?  Do they understand how neglecting a basically solid product, that has real advantages over the competition, is shooting themselves in the foot?   

Have all their top engineers been busy getting the new SDS2500 prototype (or whatever they're calling it) ready for the Trade Show?  Seriously, I know how Development works, and you don't stall all work/progress on an existing product unless someone decided to temporarily reallocate and reprioritize limited resources elsewhere.

[tautech]

How did they respond to that?  Did they provide any explanation for the lack of progress, on critical updates to a shipping product?  Any realistic time-frame to expect this functionality to eventually be delivered?  Do they understand how neglecting a basically solid product, that has real advantages over the competition, is shooting themselves in the foot?   

Have all their top engineers been busy getting the new SDS2500 prototype (or whatever they're calling it) ready for the Trade Show?  Seriously, I know how Development works, and you don't stall all work/progress on an existing product unless someone decided to temporarily reallocate and reprioritize limited resources elsewhere.

Mark, I agree wholeheartedly with you comments, it is a frustrating delay waiting for the new firmware particulary as I have a deal or two that might progress should it be completed.
It seems only continued posting on these threads for Siglent to see our frustration and the ongoing emails from we dealers is needed for progress to occur. 
There was a good number of problems to rectify and this as I understand has taken time.
However I believe its release is imminent and not before time IMO.

If other Siglent agents have further news on this matter....please share.

[AlfBaz]

I have been waiting patiently to see what the new firmware version brings to this unit. Others may not be so patient, taking into account the considerable competition there is at this price point.

Further, the more time I wait the more expectation I have that the firmware update is more comprehensive. Should the next update a minor or insignificant update I will most likely buy something else as this would indicate to me, a lack of commitment to their products

[nctnico]

I'm at the point where I check for a new firmware version every day   

It would be nice if Siglent releases a new version soon. Lots of companies and people buy equipment in December.

[marmad]

I'm at the point where I check for a new firmware version every day   

It would be nice if Siglent releases a new version soon. Lots of companies and people buy equipment in December.

I've learned that expecting companies to eventually fix bugs or add features is a mistake. If the product you're buying doesn't do what you need it to do right from the start, it's better to look elsewhere.

[nctnico]

True but I'm willing to give Siglent some slack because the SDS2000 is clearly in it's infancy stage. If they abandon it now they can close their company. My original plan was to buy an SDS2000 around Christmas this year so I hope they get the firmware sorted in the next couple of weeks. Besides that Siglent still adds new features to the SDG1000 firmware.

[gms]

I've learned that expecting companies to eventually fix bugs or add features is a mistake. If the product you're buying doesn't do what you need it to do right from the start, it's better to look elsewhere.

Hello! I am very bad understand English and use Google Translate. Google translated so that I nothing do not understand :-). Please explain what you mean by writing this message?

The fact that I paid for the SDS2202 and i hope that soon he will come to me ...
You claim that the firmware update will not? And Siglent will not fix bugs?

[Mark_O]

I've learned that expecting companies to eventually fix bugs or add features is a mistake. If the product you're buying doesn't do what you need it to do right from the start, it's better to look elsewhere.

Hello! I am very bad understand English and use Google Translate. Google translated so that I nothing do not understand :-). Please explain what you mean by writing this message?

The fact that I paid for the SDS2202 and i hope that soon he will come to me ...
You claim that the firmware update will not? And Siglent will not fix bugs?

Siglent will of course fix some bugs.  It may be soon, or it may be late.  Some bugs you may be waiting a long time for fixes, and a few may never get fixed, if they're not deemed important enough to affect sales.  Or a new model comes out that supercedes your model.

So Marmad meant what he said:  if you will be unhappy that some bug that may be important to you may never get fixed, don't pay your money ahead of time.  The only thing you're guaranteed to get is whatever happens to be implemented in the unit when you get it.  Anything beyond that is nice, but may never happen.

Ask Siglent (or, Rigol, etc. for that matter), if they will sign an official document guaranteeing that bugs important to you will be fixed.  Or that important features or usability fixes that are critical to you will eventually be implemented.  They won't do it.  Ask them if they will sell it to you for a part of the cost... with the rest to be paid after they eventually get all their claimed features working.  They won't do that either.

Marmad was warning folks not to buy based on what they hope it will some day do... but instead only on what it does now (bugs and all).  Otherwise you may wind up learning the hard way (as some of us old-timers already have).

None of the products are perfect, and all have at least some minor issues that owners have to get used to.  That's a fact of life.  But not all have the SAME bugs and limitations.  If the bugs/limitations of a specific unit are things you CAN accept, and use the instrument in spite of, then you won't have a major problem.  But if not, you could be very unhappy indeed, when something you were so sure would get fixed, never does.  After you had patiently waited for it for a year or more.