Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[kcbrown]

By the way, I think the history handling needs to be put into some perspective.  And because this is just my perspective, others might differ (in both directions).

It's certainly a bug (whether a design bug or implementation bug) that the history gets nuked under circumstances where there's no truly good reason for it (such as when moving the cursors around).  But it's not a bad bug or anything, unless one is relying on continuous history acquisition while twiddling the knobs.  There may be some circumstances under which that will be the case.   Those circumstances will, of course, be kept to a minimum if one is aware of this behavior in the first place.

The real problem is that this behavior isn't, that I'm aware, documented anywhere.  And it most certainly violates the principle of least surprise, which is one of the cornerstones of user interface design.  It is a bug.  But it doesn't rise to the level of some bugs, e.g., when the scope shows something that is objectively incorrect.

That said, seeing how the automatic history is the justification for the "what you see is all you get" approach to acquisition in the presence of deep memory, it seems obvious that Siglent should be doing everything they can to preserve the history in as many circumstances as possible.  And right now, the opposite seems to be the case.

Even so, I would much rather see Siglent polish the UI to near-perfection first.  While the history issue is an issue, it only comes into play under certain circumstances.  But the UI experience is universal and ever-present.  Fixing that will make the scope a joy to use irrespective of some issues like the history ones described here.

[maxspb69]

I agree about the user interface. This is the most annoying thing of this scope. Perhaps, if I had the opportunity to work with the device for a couple of days (just work, not play ) - I'm not sure if I would buy it. I have to rotate the knobs constantly, and I personally use history quite rarely. Like most of us probably.

There are also complaints about the quality of rendered waveforms. Despite the rather large screen resolution (1024x600), the waveforms are rendered with the quality inherent in a 320x200 screen. Looking at the screenshots at high magnification, you can see that this is the case. There is a maximum of 16 gradations of brightness, but most likely 8. Antialiasing is very primitive. Therefore, even a pure sine wave appears to be "jagged" on the screen, as it is rendered at very low pixel and brightness resolution. In addition, Siglent for some reason, uses white color mixing with the channel colors  to "increase brightness", which makes it a "dirty color" effect and impairs the already not best visibility of the waveforms.

For comparison, the waveform rendering of Siglent SDS2000X+  and the old Rigol DS2072. Guess where who is? )))

[roberthh]

About History Buffer.
Just my "groschen":
- I can understand that the history buffer is cleared when parameters are changed which affect the acquisition. Whether or not that could be handled differently by software can only be told by Siglent. But since that only happens while NOT in history viewing mode, but in a run mode, I personally do not consider that as a real problem. When I want to use history, I set up the device properly, and then do my test series, which I then can inspect.
- I agree that is it unexpected and unnecessary (aka a bug), that the history buffer is cleared on attempts which just change who data is displayed or analyzed or triggered(cursors, measurement, zoom, single shot (!)).

[roberthh]

About Display rendering:
Yes, that leaves much room for improvement. I could understand that a 8 bit signal, if displayed in full height of the screen, uses more than one pixel per step. But a signal not using the full screen heigth could be definitely use 1 pixel per vertical step, and not always 2.
And sometimes vertical slopes look are displayed poor, such that it was not obvious whether a visible step in the slope was a display issue or a signal property. Most of the time, it was a display thing.

[maxspb69]

A signal that does not use the entire screen height does not use 8 bits. 8bit is the entire vertical visible area in best case. They can be stretched to more than the entire screen, but you cannot use all 8 bits on a limited area of ​​the screen.

The problem is that Siglent uses a very primitive anti-aliasing algorithm (smoothing oblique lines), so the signals appear so stepped. And this does not depend on the number bits of ADC, but only on the visualization algorithms. It is quite possible to fix this by software, and I am almost sure that the processor performance is sufficient for this fix. But will Siglent do this?

[kcbrown]

A signal that does not use the entire screen height does not use 8 bits. 8bit is the entire vertical visible area in best case. They can be stretched to more than the entire screen, but you cannot use all 8 bits on a limited area of ​​the screen.

8 bits is 256 discrete values.  As long as you have more than 256 pixels vertically on your screen, you'll be able to display 256 values on even a subset of it.  The resolution of the 2000X+ is 1024x600.  You can fully display two signals vertically at full 8 bit resolution with pixels to spare.

10 bits, on the other hand, is a different matter ...

The problem is that Siglent uses a very primitive anti-aliasing algorithm (smoothing oblique lines), so the signals appear so stepped. And this does not depend on the number bits of ADC, but only on the visualization algorithms. It is quite possible to fix this by software, and I am almost sure that the processor performance is sufficient for this fix. But will Siglent do this?

I'm actually rather a bit surprised that there isn't a super-cheap LCD controller that has the equivalent of a built-in GPU.  The GPU doesn't have to be amazingly fast or anything.  Even something with the kind of power that the very first NVidia 3D GPUs had would be more than sufficient for the purposes of these displays.

[maxspb69]

But digital scopes work differently. If your signal is not stretched to full screen, it does not use all 8 bits, but less. For example, if the signal has a span of 4 div. out of 8, then it uses only 7 bits. If 2 divisions - 6 bits. Etc.

[roberthh]

About rendering:
What I mean: Even when a sine or ramp signal that has a acquiring span (max - min) of 200 is displayed at a height of let's say 50 Pixels, the vertical steps are always 2 pixels. Different to that, the rendering of text in the menus is much better.

[rf-loop]

I agree about the user interface. This is the most annoying thing of this scope. Perhaps, if I had the opportunity to work with the device for a couple of days (just work, not play ) - I'm not sure if I would buy it. I have to rotate the knobs constantly, and I personally use history quite rarely. Like most of us probably.

There are also complaints about the quality of rendered waveforms. Despite the rather large screen resolution (1024x600), the waveforms are rendered with the quality inherent in a 320x200 screen. Looking at the screenshots at high magnification, you can see that this is the case. There is a maximum of 16 gradations of brightness, but most likely 8. Antialiasing is very primitive. Therefore, even a pure sine wave appears to be "jagged" on the screen, as it is rendered at very low pixel and brightness resolution. In addition, Siglent for some reason, uses white color mixing with the channel colors  to "increase brightness", which makes it a "dirty color" effect and impairs the already not best visibility of the waveforms.

For comparison, the waveform rendering of Siglent SDS2000X+  and the old Rigol DS2072. Guess where who is? )))

About these images.
It can see that Rigol have more artists and Siglent have more engineers.
One ADC data value is 8 bit. One step on screen is exactly 2 pixels If there is data value 9F there is data value 9F and not data value between 9F and 9E.  Siglent is test and measurement image, not picture artists camera or movie display. Even if it is bit rough for eyes but truth must not hide. Siglent is mapping every sample to display and every sample need be exatly visible. So that do npty need guess if there is true data byte or if it is image rendering artist produced or hided because it is not nice to look.

Sorry but  if data is rough it need also show it is rough and not hide truth.

From Siglent images I can tell exactlly what values there sure exists in image and what not. Rigol image leave lot of room for guessing (just made detail looking changing contrast and other things and impossile to say what pixels there is data and what are "artists" made. 
I do not accept at all this Rigol result. But I am not artist. If this is done with art phtotographs, entertainment movies etc.. there I can accept, even hope many methods for make image better looking..  but now we are talking test and measurement instruments what need display data as it have captured. Data must not bend!

How much they hide because they have started this "nice looking image is more important than real data", how much they bend data for show all more nice. I can recommend, they can put these image artist for cleaning noise from signal image because it is not so nice to look.

8 bit data is rough on display and this truth must not hide, there is not "perhaps" or intermediate and not "more nice or wanted" values (except in IPCC data). What other things they do for "cleaning" data for more "nice". Display only "pleasant looking data". But yes, they have been famous in this area.  Instruments for engineers and instruments for artists.

[Martin72]

It can see that Rigol have more artists and Siglent have more engineers.

MMD! 

[tv84]

And the degree of artistry becomes greater because we are not talking about 8-bit! In reality we are talking about sub-8bits world as many of you have described recently. And the lower you are, the more creative you need to be.

[maxspb69]

Ok, I haven't posted zoomed screenshots from RTB2000 and MDO3054. Or only artists also work in R&S and Keysight?
If you draw a straight line from point A to point B by a pencil on paper, it will be very smooth. If we build it with Lego elements, it will be very jagged and rough. But this does not mean that it is more accurate. We have only 2 refer points, everything in between  -  approximate. You can connect the points with rough stepped lines or smooth them using graphical algorithms. Accuracy will not degrade. And the visual experience will be greatly improved.

[2N3055]

Forgive me all but all this is useless wankery.

What is shown here is called pixel anti aliasing, and is purely visual eye candy. It just makes 1 pixel  5 pixels wide and blends the edges so they are not visually obvious.
It is popular in gaming to remove pixelation and replace it with blur.

While it might seem more pleasant it doesn't make scoping (is that a word?) better, and makes any visual and cursor measurement less accurate. It is also part of reason why Rigol renders such a noisy and thick waveforms...

Also who says Keysight does it ?

[kcbrown]

But digital scopes work differently. If your signal is not stretched to full screen, it does not use all 8 bits, but less. For example, if the signal has a span of 4 div. out of 8, then it uses only 7 bits. If 2 divisions - 6 bits. Etc.

You're quite right.  I had forgotten about that, and was clearly thinking only of what the display was capable of relative to an 8 bit value.   

[kcbrown]

About these images.
It can see that Rigol have more artists and Siglent have more engineers.
One ADC data value is 8 bit. One step on screen is exactly 2 pixels If there is data value 9F there is data value 9F and not data value between 9F and 9E.  Siglent is test and measurement image, not picture artists camera or movie display. Even if it is bit rough for eyes but truth must not hide. Siglent is mapping every sample to display and every sample need be exatly visible. So that do npty need guess if there is true data byte or if it is image rendering artist produced or hided because it is not nice to look.

Sorry but  if data is rough it need also show it is rough and not hide truth.

I have to disagree here, rf-loop -- this is what dot mode is for.  If you want to see the raw data in that manner then dot mode is what you need to be using.

For interpolated data the results should be as smooth as the display will allow, as long as the resulting smoothing is not itself incorrect relative to the selected interpolation method.

In fact, done right, the resulting smoothed curve could even give you a visual representation of the uncertainty in the data, since smoothing (antialiasing) of a curve generally will also use lower intensity pixels as part of the process.  After all, scaling the actual value in order to place it on the screen is not guaranteed to land it at an exact (non-fractional) location on the screen, and save for specific circumstances, it's incorrect to claim that each point in the waveform will always land squarely on a corresponding location on the screen.

[2N3055]

About these images.
It can see that Rigol have more artists and Siglent have more engineers.
One ADC data value is 8 bit. One step on screen is exactly 2 pixels If there is data value 9F there is data value 9F and not data value between 9F and 9E.  Siglent is test and measurement image, not picture artists camera or movie display. Even if it is bit rough for eyes but truth must not hide. Siglent is mapping every sample to display and every sample need be exatly visible. So that do npty need guess if there is true data byte or if it is image rendering artist produced or hided because it is not nice to look.

Sorry but  if data is rough it need also show it is rough and not hide truth.

I have to disagree here, rf-loop -- this is what dot mode is for.  If you want to see the raw data in that manner then dot mode is what you need to be using.

For interpolated data the results should be as smooth as the display will allow, as long as the resulting smoothing is not itself incorrect relative to the selected interpolation method.

In fact, done right, the resulting smoothed curve could even give you a visual representation of the uncertainty in the data, since smoothing (antialiasing) of a curve generally will also use lower intensity pixels as part of the process.  After all, scaling the actual value in order to place it on the screen is not guaranteed to land it at an exact (non-fractional) location on the screen, and save for specific circumstances, it's incorrect to claim that each point in the waveform will always land squarely on a corresponding location on the screen.

And we disagree with you.
Pixel anti aliasing would serve no purpose except eye candy and would yield visually much higher displayed noise (thick trace).
Also, when display is running, you get exactly that pixel anti aliasing effect, by virtue of display intensity gradation in persistence. Only stopped it shows only last (single) capture that is single pixel wide.
When running trace looks smooth... Check it out.. It also works same way in dot mode, in which it creates effect of RIS sampling, making effective sample rate higher that spec.. Hence better impulse response (within limits of front end of course)

[kcbrown]

And we disagree with you.
Pixel anti aliasing would serve no purpose except eye candy and would yield visually much higher displayed noise (thick trace).

Let's say that you want to show a 1.3V value on the display at t = 0, the trigger location is at the center, and you have the display set for 1V/div with a 0V vertical offset, the vertical resolution of your display is 480 pixels, and it shows 10 divisions vertically.  This gives you 48 pixels per division.  1.3V up from center would be 62.4 pixels up from center.  How will you most accurately represent that?  With a single pixel at 62 pixels up?

No.  I argue that the most accurate representation of that value is with two vertical pixels, one at 62 and one at 63, where the pixel intensity of the one at 63 is 66% that of the one at 62 (62.4 means that 60% of the value is at 62 and 40% of it is at 63).

Also, when display is running, you get exactly that pixel anti aliasing effect, by virtue of display intensity gradation in persistence. Only stopped it shows only last (single) capture that is single pixel wide.

Right.  But why is it a single pixel wide (or high) when the display is a discrete grid that, except under very specific circumstances, does not map 1:1 onto the values it's being asked to display?  The very problem here is that the display is an inexact representation of the values it's being asked to display, precisely because of the scaling operations that have to take place prior to display.  The use of multiple pixels at different intensity makes it possible to more accurately represent recorded values.

Of course, complicating this is the fact that the values themselves are the result of conversion from analog to digital, so that would have to factor into this to the degree possible.

And then there's the fact that the conversion itself is limited in resolution and, thus, carries with it uncertainty.  Wouldn't it be most accurate to represent that uncertainty in the display as well?

Put another way, it is, generally, misleading in at least a couple of ways to represent the recorded value as a single pixel in the display, no?

--

If your argument is that the nature of displaying a single capture is such that you don't need to go to the trouble of antialiasing, then I can agree with that.  You have cursors at your disposal if you want to see the actual value at any given point.  But that is a very different argument from the one that says that "antialiasing" cannot serve a useful purpose.  Done right, it can.

[roberthh]

With all methods of applying a certain range of values to a range to display pixels, it seems unnecessary for me that the step size in the display is always 2 pixels. If for instance a signal with 256 discrete values is mapped onto a range 64 pixels, I see only 32 discrete values. I do not see a need to do it that way, even if the trace uses 2 pixels height for better visibility.

[maxspb69]

Signal with 256 discrete values is never displayed in 64 pixels height in normal (fullscreen) mode. It's impossible in digital scopes. Typically, 256 discrete values are stretched to the number of pixels in the output area vertically , which more than 256 pixels in modern oscilloscopes.

But even with 256 discrete levels for 512 pixels, you can draw lines in different ways. Siglent does not bother and draws as in the left picture. It doesn't look very good even on the oscilloscope screen, especially in the screenshots taken. Anti-aliasing does not thicken the line in any way. But it makes it smoother.

[BreakingOhmsLaw]

Not sure if this applies to the SDS 2XXX series as well, but the SDS12XX is missing a feature for alternate triggering across the channels.
e.g.: I want to trigger from CH1, sample and draw, the trigger from CH2 (or 3,4), sample and draw.
This is very useful when you want to compare signals that are related but not time synced. Think delay lines, phase shifts, that kind of stuff.
Hell, my old PM3070 CRO can do that, and you can even select a different timebase for CH2. A dual time base/trigger should be relatively easy to implement in a digital scope.

[roberthh]

Signal with 256 discrete values is never displayed in 64 pixels height in normal (fullscreen) mode.

My concern was not full screen mode, but showing signals ar smaller height, which may happen if oyu have for instance 4 traces which should not overlap on the screen, and all the other information.
Besides that, your example for smoothing a display is right. And that technique seems to be used by Siglent for text.

Edit: Interestingly, the math trace display shows single pixel vertical steps.

[2N3055]

Not sure if this applies to the SDS 2XXX series as well, but the SDS12XX is missing a feature for alternate triggering across the channels.
e.g.: I want to trigger from CH1, sample and draw, the trigger from CH2 (or 3,4), sample and draw.
This is very useful when you want to compare signals that are related but not time synced. Think delay lines, phase shifts, that kind of stuff.
Hell, my old PM3070 CRO can do that, and you can even select a different timebase for CH2. A dual time base/trigger should be relatively easy to implement in a digital scope.

Pretty much there is no modern digital scope from major brands that implements Alt triggering mode, except few exceptions.
You can sometimes achieve similar with logic trigger on some scopes.

[Martin72]

After spreading it on several threads, I´m try to make a summary of what "our" two new siglent owners here concerns and their  "issues" with the scope, because they aren´t bugs.
But it turns out do as if the scope has serious quirks, which is definitely not true.
So we should use this thread here only for wanting nice to haves....

Wanted features (because it´s no bug):

- Faster response of the knobs in general.
- Doing whatever you want with the scope settings without nuking the history.

Am I right ? What else perhaps ?
Because it´s confusing to read a piece here, a piece there....

The aliasing thing is no bug also, we shouldn´t use magnifying glasses for looking at the scope screen..

Martin

[kcbrown]

After spreading it on several threads, I´m try to make a summary of what "our" two new siglent owners here concerns and their  "issues" with the scope, because they aren´t bugs.
But it turns out do as if the scope has serious quirks, which is definitely not true.
So we should use this thread here only for wanting nice to haves....

Wanted features (because it´s no bug):

- Faster response of the knobs in general.

Yep, that's a feature request.  It would rise to the level of a bug if the UI went completely (or almost completely) unresponsive, but it hasn't done that to me except once, and restarting the scope seems to have cleared it.  As it is, the UI is highly responsive to the touch screen menu operation.

I'd say the UI for moving traces around and things like that is responsive enough, even if it could be substantially improved.  I've seen worse.

- Doing whatever you want with the scope settings without nuking the history.

That I think over-trivializes the problem.

It seems like doing just about anything with the scope while it's performing acquisitions will nuke the history.  Moving the cursors does that.  Merely highlighting a different digital channel (without making any changes to it, or changing its ordering, or anything else like that) will do that.  Entering or exiting zoom mode will do that.  Moving around within zoom mode will do that.  These are things that don't change any settings.

That is a bug for sure.  Whether a design bug or an implementation bug, it's a bug all the same, because it's doing something that it shouldn't do.


That doesn't mean there aren't any operations for which it's valid for it to clear the history -- a case can clearly be made that there are, and some here have made that case.  But there are certainly operations for which there is no good reason to clear the history as a side effect.

The aliasing thing is no bug also, we shouldn´t use magnifying glasses for looking at the scope screen..

I'd agree that the aliasing thing is a feature request.  It's not strictly incorrect for it to be displaying things as it is.  It may not be terribly pleasing to look at, but that doesn't make it rise to the level of a bug.

[Tom45]

Not sure if this applies to the SDS 2XXX series as well, but the SDS12XX is missing a feature for alternate triggering across the channels.
e.g.: I want to trigger from CH1, sample and draw, the trigger from CH2 (or 3,4), sample and draw.
This is very useful when you want to compare signals that are related but not time synced. Think delay lines, phase shifts, that kind of stuff.
Hell, my old PM3070 CRO can do that, and you can even select a different timebase for CH2. A dual time base/trigger should be relatively easy to implement in a digital scope.

For whatever reason, the features that you mention were ubiquitous in analog scopes and pretty much nonexistent in digital scopes.

See: https://www.eevblog.com/forum/blog/eevblog-1235-alternate-trigger-trickery-on-dsos/