Siglent SDS800X HD Review & Demonstration Thread

[Performa01]

A high-resolution scope is not meant for inspecting traces with a magnifier glass, but getting suitable data for vertical zoom and precise measurements.

I don't really agree on the "it's not meant for looking at traces" argument. It's an oscilloscope, after all.  If the user were not meant to look at the trace in detail, why bother with intensity or color grading?

Did you leave out the bold part of my message on purpose?

We do not need to look at traces at a pixel level, just to take advantage on intensity or color grading.

If ~0.5% resolution is not enough to inspect some tiny (and usually insignificant) signal details, then vertical zoom is the right tool for it.

[ebastler]

Sorry, I did not mean to mis-quote you. But I find that the slightly jagged traces in Y-T mode are quite visible on a 10" screen without magnification, and even more so the black "scan lines" in X-Y mode.

[DaneLaw]

Sorry, I did not mean to mis-quote you. But I find that the slightly jagged traces in Y-T mode are quite visible on a 10" screen without magnification, and even more so the black "scan lines" in X-Y mode.

Was unsure what you meant, but I reckon it's this stepping in the vertical axis. (pic from #90 zoomed on two graticules)

[ebastler]

Was unsure what you meant, but I reckon it's this stepping in the vertical axis. (pic from #90)

Yes, it's alway double-pixels at the same intensity in the vertical direction, both in X-Y and Y-T mode. (Unless under some conditions, as shown by 2N3055 -- hope he can shed some more light onto that.) And in X-Y mode, the fact that every other column remains black.

[2N3055]

SDS800xHD and vertical pixels......

Can those claiming this scope always renders waveform with double vertical pixels  please explain attached images:

On this capture it is clearly visible that portions of the waveform are rendered with exactly ONE vertical pixels....

Download images to your PC and zoom in....

Looks to me like there are certain lines that are 1 pixel and the rest are two? Like it is reducing from a resolution that is not a whole fraction of the screen resolution.

That is direct dump of screen from a scope with Web control.
1024x600 pixel for pixel.

[baldurn]

SDS800xHD and vertical pixels......

Can those claiming this scope always renders waveform with double vertical pixels  please explain attached images:

On this capture it is clearly visible that portions of the waveform are rendered with exactly ONE vertical pixels....

Download images to your PC and zoom in....

Looks to me like there are certain lines that are 1 pixel and the rest are two? Like it is reducing from a resolution that is not a whole fraction of the screen resolution.

That is direct dump of screen from a scope with Web control.
1024x600 pixel for pixel.

Yes what I am saying is that appears like it is upscaling from a lower resolution in a primitive way. Say the original data is 200 pixels and the screen is 300 pixels. You could do that by mapping even source pixels to two screen pixels and odd source pixels to just one screen pixel. That way 2 pixels becomes 3 on the screen. Looks to me something like that is going on. You have some horizontal lines one pixel and other horizontal lines are two pixels.

[2N3055]

SDS800xHD and vertical pixels......

Can those claiming this scope always renders waveform with double vertical pixels  please explain attached images:

On this capture it is clearly visible that portions of the waveform are rendered with exactly ONE vertical pixels....

Download images to your PC and zoom in....

Looks to me like there are certain lines that are 1 pixel and the rest are two? Like it is reducing from a resolution that is not a whole fraction of the screen resolution.

That is direct dump of screen from a scope with Web control.
1024x600 pixel for pixel.

Yes what I am saying is that appears like it is upscaling from a lower resolution in a primitive way. Say the original data is 200 pixels and the screen is 300 pixels. You could do that by mapping even source pixels to two screen pixels and odd source pixels to just one screen pixel. That way 2 pixels becomes 3 on the screen. Looks to me something like that is going on. You have some horizontal lines one pixel and other horizontal lines are two pixels.

You mean inside the scope?
Why would they do that?

You do realize that problem with the scope is that they have TOO MANY data points/values to map to one pixel.
Vertical res of ADC is 4000 points.
Even worse, internal representation is 16 bit, so 65536 vertical values.
So unless you have that much EXACTLY on the screen, you have to map..
How do you plot it when you have 600 vertical pixels?
You need to map 6.6 data values vertically to one pixel for one ADC data point.
And cca 109 from internal 16 bit value.

And then you have fact that one pixel horizontally must map hundreds of thousand of data points to one pixel.
When your buffer has 10 Mpts and screen is 1024 pixels wide, that is 10000 sample points to single pixel, horizontally. And they will all have different values...

How do you map that to screen?
You create data cloud.
As I said, those "double" pixels are simply accurate representation of in-between values. It is nor pixel above nor pixel below, but somewhere in the middle or both...

I you were to upsample by pixel doubling (or tripling) , you would never have any combination of pixels different form integer multiplier of upsampling: for x2  it would be always 2, 4 ,6 8.. or for 3x 3, 6, 9 ...
You couldn't have 1, 2 and 3 at the same time on the screen. Ever.

[baldurn]

You mean inside the scope?
Why would they do that?

This is just speculation, but it appears they downsample the 12 bit raw data to 8 bits before processing it in the UI chain. It would halve the amount of data they need to work assuming the CPU would otherwise have to work with 12 bit stored in a 16 bit data structure. Then the final step to display the data is to upscale from 256 values to maybe 400 lines on the screen.

We may find the reason if we compare the SDS2000X HD. Does it have a slower CPU or maybe the memory bandwidth is worse? So they had to do something to make the UI quicker on the cheaper platform.

[ebastler]

As I said, those "double" pixels are simply accurate representation of in-between values. It is nor pixel above nor pixel below, but somewhere in the middle or both...

I am still puzzled by your screenshots. I have scrutinized quite a few other screenshots published here, copying them to a bitmap editor and zooming in. I always strictly saw doubled pixels in the Y dimension. It's even more striking in Performa01's recent X-Y screenshots, with the alternating black columns along the X dimension.

And Performa01's explanation made sense to me: When there is limited fast memory to create the "digital phosphor" overlay of traces in the FPGA, lumping two screen pixels together seems like a technically efficient way of getting by.

Hence I am wondering what you did differently. Is it maybe that a single capture gets rendered differently -- plotted directly from the full-resolution data buffer? Did you capture these traces in the screenshot in Single mode; or did you stop the acquisition and then shifted the displayed time window so the screen got redrawn from the buffer?

(Edit: Typos)

[2N3055]

As I said, those "double" pixels are simply accurate representation of in-between values. It is nor pixel above nor pixel below, but somewhere in the middle or both...

I am still puzzled by your screenshots. I have scrutinized quite a few other screenshots published here, copying them to a bitmap editor and zooming in. I always strictly saw doubled pixels in the Y dimension. It's even more striking in Performa01's recent X-Y screenshots, with the alternating black columns along the X dimension.

And Performa01's explanation made sense to me: When there is limited fast memory to create the "digital phosphor" overlay of traces in the FPGA, lumping two screen pixels together seems like a technically efficient way of getting by.

Hence I am wondering what you did differently. Is it maybe that a single capture gets rendered differently -- plotted directly from the full-resolution data buffer? Did you capture these traces in the screenshot in Single mode; or did you stop the acquisition and the shift the displayed time window so the screen got redrawn from the buffer?

Read my post above.
You all ignore that if you have 10000 horizontal data point to squeeze into one pixel, there are hard decisions to be made...

I made a capture with 1000 data points. So data is not crowded horizontally.

[ebastler]

You all ignore that if you have 10000 horizontal data point to squeeze into one pixel, there are hard decisions to be made...
I made a capture with 1000 data points. So data is not crowded horizontally.

I don't see how "horizontal crowding" explains the strict double-pixel patterns seen in all those other screenshots. There should be some single pixels, and many double-pixels which are vertically shifted vs. the others by 1 pixel.

I still like my hypothesis about the screen being redrawn from the full-resolution data buffer under certain cirumstances, resulting in a full-resolution display. (While it is always half-resolution when drawn from the "digital phosphor" buffer in the FPGA.) Could you comment on the questions I asked? Thanks!

Is it maybe that a single capture gets rendered differently -- plotted directly from the full-resolution data buffer? Did you capture these traces in the screenshot in Single mode; or did you stop the acquisition and then shift the displayed time window so the screen got redrawn from the buffer?

[2N3055]

You all ignore that if you have 10000 horizontal data point to squeeze into one pixel, there are hard decisions to be made...
I made a capture with 1000 data points. So data is not crowded horizontally.

I don't see how "horizontal crowding" explains the strict double-pixel patterns seen in all those other screenshots. There should be some single pixels, and many double-pixels which are vertically shifted vs. the others by 1 pixel.

I still like my hypothesis about the screen being redrawn from the full-resolution data buffer under certain cirumstances, resulting in a full-resolution display. (While it is always half-resolution when drawn from the "digital phosphor" buffer in the FPGA.) Could you comment on the questions I asked? Thanks!

Is it maybe that a single capture gets rendered differently -- plotted directly from the full-resolution data buffer? Did you capture these traces in the screenshot in Single mode; or did you stop the acquisition and then shift the displayed time window so the screen got redrawn from the buffer?

No, sorry.

I cannot comment to all wild speculations here. I have no internal knowledge of exact algorithm used, and if I had, nobody in their right mind would tell me something like that without signing NDA, in which case I would not be able to share it....
I'm afraid that all that like to speculate here will have to be happy with that status quo.

What I can, and am saying is how I think it could have been done.
All I know that Occams razor is king, and it is probably simply done in simplest way it could be, for reasons of speed and resource size.....

[ebastler]

No, sorry.

I cannot comment to all wild speculations here. I have no internal knowledge of exact algorithm used, and if I had, nobody in their right mind would tell me something like that without signing NDA, in which case I would not be able to share it....
I'm afraid that all that like to speculate here will have to be happy with that status quo.

What I can, and am saying is how I think it could have been done.
All I know that Occams razor is king, and it is probably simply done in simplest way it could be, for reasons of speed and resource size.....

I am baffled. Why don't you want to answer two simple questions on how you acquired those two screenshots? 

Look -- I am not criticizing either you or Siglent with these questions. I just want to understand what's going on, out of technical curiosity. It's my favorite type of puzzle, where you have to deduce the internal mechanism based on observations of the external behaviour.

I have tried to explain why I don't think your assumption (horizontal crowding) explains the observed pattern. I have proposed another assumption, and those two data points on how you acquired the screenshots would help to support or falsify that. Please indulge me and tell me how you acquired them. 

[2N3055]

No, sorry.

I cannot comment to all wild speculations here. I have no internal knowledge of exact algorithm used, and if I had, nobody in their right mind would tell me something like that without signing NDA, in which case I would not be able to share it....
I'm afraid that all that like to speculate here will have to be happy with that status quo.

What I can, and am saying is how I think it could have been done.
All I know that Occams razor is king, and it is probably simply done in simplest way it could be, for reasons of speed and resource size.....

I am baffled. Why don't you want to answer two simple questions on how you acquired those two screenshots? 

Look -- I am not criticizing either you or Siglent with these questions. I just want to understand what's going on, out of technical curiosity. It's my favorite type of puzzle, where you have to deduce the internal mechanism based on observations of the external behaviour.

I have tried to explain why I don't think your assumption (horizontal crowding) explains the observed pattern. I have proposed another assumption, and those two data points on how you acquired the screenshots would help to support or falsify that. Please indulge me and tell me how you acquired them. 

What do you mean how I acquired them? What do you mean I don't want to answer?

They are acquired with a scope. By using settings in plain view on the screen (which is one of great things on this scopes, it is all there on the scope screen).
They are directly from the scope by using screenshot button in Web view.
It is as plain as it can be...

What are you implying? Some tricks or manipulations on my side? Are you questioning my integrity?

As I said, there is not only horizontal crowding (nice term for this by the way) but also vertical. If you use 2 pixels and pixel brightness you can achieve more visual states that single pixels. Think of it as using dithering instead of AA...
Combine all of that and you get this...

In the end, apart from intellectual curiosity it does not matter.
It works quite well the way it is.

[baldurn]

I have marked some lines in this cutout of a screen shot:



The numbers corresponds to the "y" line number. The line y=2 is a single line and no other lines are partial into the screen line occupied by y=2. In my opinion this fact rules out the theory that we are seeing 4096 values (12 bit) being mapped to approximately 400 screen lines. In that case it is very unlikely that we will see this set of steps where no value gets partially mapped to the line with y=2. We should see some double pixels a half step up from y=1 and we should see some double pixels a half step down from y=3. But we are not seeing that.

My theory is that we are seeing 8 bit data (256 values) mapped to 400 screen lines. Some of the values do indeed end up being in between and are rendered as two pixels. A few values do end up being close to exact and are rendered as one pixel.

I know this is supposed to be a 12 bit scope and we want to see 12 bit data. But I think we are seeing evidence that the 12 bits are downsampled to 8 bit before being processed by the UI. They can still use the full 12 bits raw data in other contexts. I assume the FPGA is working with 12 bit data but the CPU might be working with 8 bit to speed things up.

[Veteran68]

You do realize that problem with the scope is that they have TOO MANY data points/values to map to one pixel.
Vertical res of ADC is 4000 points.
Even worse, internal representation is 16 bit, so 65536 vertical values.
So unless you have that much EXACTLY on the screen, you have to map..
How do you plot it when you have 600 vertical pixels?
You need to map 6.6 data values vertically to one pixel for one ADC data point.
And cca 109 from internal 16 bit value.

I think (hope?) everyone here understands that with any scope you're going to have more data than pixels. Nobody argues that point. What does matter to those of us who care more than others about the visualization, is how that mapping is done. Saying "it does not matter" is simply dismissive of those to whom it DOES matter.

It shouldn't be necessary to point out that the criticisms/disappointments with Siglent here compared to Rigol's approach with the DHO line is the physical resolution of the display. Rigol supports MORE data at 1280x800 than the more limited 1024x600 resolution in the Siglent scope. You have 67% more pixels on the screen to work with. That's not a trivial difference. While I'd say the 1024x600 resolution is more tolerable, if not ideal, in the smaller 800 series, with the 1000 series and their 10.1" screens it's more of an egregious design decision. That's a very limited resolution which just makes display quality noticeably worse, especially on the bigger screen which just magnifies scaling artifacts.

I get that some people care more about the data than the visualization of it, but to ebastler's earlier points, at the end of the day an oscilloscope is all about displaying a waveform. Expecting it to be displayed as cleanly and accurately as possible is not a baseless "nitpick," it's a legitimate concern. Especially given the relatively low cost of a higher resolution LCD panel (or else Rigol wouldn't have done it at their lower pricepoint). While it may not sway everyone away from the other clear benefits of the Siglent design, dismissing these concerns out of hand is not productive to the discussion either. Those of us on the fence due to the downgrade in visual quality want to be convinced of the reasons to buy something that -- in this specific technical case -- is inferior to what we have. So please, indulge our concerns and help us understand what Siglent was thinking, and what might be done to improve things that we may not be aware of.

I really want another Siglent scope as I prefer the brand, but I'm not yet to the point of giving up my DHO for one, even if it is inferior in other ways.

[ebastler]

What are you implying? Some tricks or manipulations on my side? Are you questioning my integrity?

No second thoughts, and no cause to get defensive -- just the two questions mentioned earlier. Please take them at face value.

As I tried to explain before, it would make sense to me that the scope can draw traces on the screen at full resolution (only) if it gets the data to be plotted directly from the 12-bit capture buffer, under the circumstances described in my questions. So I would like to understand whether that is the reason for the different appearance of your screenshots vs. others I have seen.

I can obviously try this myself once I have an SDS HD scope. But the thing is that my decision whether to get an 800 or 1000 series scope will depend on what I can expect to see on the screen. So I would much prefer to understand this upfront, rather than create extra hassle for myself and Batronix by buying one model, then potentially having to exchange it.

I don't think the answer to those questions can be gleaned from the screenshots themselves. And unless I overlooked something, I don't think you have answered them yet. Pretty please?

Is it maybe that a single capture gets rendered differently -- plotted directly from the full-resolution data buffer? Did you capture these traces in the screenshot in Single mode; or did you stop the acquisition and then shift the displayed time window so the screen got redrawn from the buffer?

[2N3055]

You do realize that problem with the scope is that they have TOO MANY data points/values to map to one pixel.
Vertical res of ADC is 4000 points.
Even worse, internal representation is 16 bit, so 65536 vertical values.
So unless you have that much EXACTLY on the screen, you have to map..
How do you plot it when you have 600 vertical pixels?
You need to map 6.6 data values vertically to one pixel for one ADC data point.
And cca 109 from internal 16 bit value.

I think (hope?) everyone here understands that with any scope you're going to have more data than pixels. Nobody argues that point. What does matter to those of us who care more than others about the visualization, is how that mapping is done. Saying "it does not matter" is simply dismissive of those to whom it DOES matter.

It shouldn't be necessary to point out that the criticisms/disappointments with Siglent here compared to Rigol's approach with the DHO line is the physical resolution of the display. Rigol supports MORE data at 1280x800 than the more limited 1024x600 resolution in the Siglent scope. You have 67% more pixels on the screen to work with. That's not a trivial difference. While I'd say the 1024x600 resolution is more tolerable, if not ideal, in the smaller 800 series, with the 1000 series and their 10.1" screens it's more of an egregious design decision. That's a very limited resolution which just makes display quality noticeably worse, especially on the bigger screen which just magnifies scaling artifacts.

I get that some people care more about the data than the visualization of it, but to ebastler's earlier points, at the end of the day an oscilloscope is all about displaying a waveform. Expecting it to be displayed as cleanly and accurately as possible is not a baseless "nitpick," it's a legitimate concern. Especially given the relatively low cost of a higher resolution LCD panel (or else Rigol wouldn't have done it at their lower pricepoint). While it may not sway everyone away from the other clear benefits of the Siglent design, dismissing these concerns out of hand is not productive to the discussion either. Those of us on the fence due to the downgrade in visual quality want to be convinced of the reasons to buy something that -- in this specific technical case -- is inferior to what we have. So please, indulge our concerns and help us understand what Siglent was thinking, and what might be done to improve things that we may not be aware of.

I really want another Siglent scope as I prefer the brand, but I'm not yet to the point of giving up my DHO for one, even if it is inferior in other ways.

I'm not being dismissive of anybody. If such a detail is important to you that is your prerogative.
You do realize that in image Baldurn is showing up here pixels are being artificially magnified almost 10 times from their physical size on the screen?
That nobody even noticed that and did even understand what are they talking about until they started (they, few people that complained about it) showing these highly magnified images?

In real life I literally had to pick up a magnifying glass to be able to see it.
This is how big deal it is in real life.

If you object to it on principle, that is fine with me.
I don't deny effect is there.
I simply state it is pretty much invisible  for all practical purposes.

You alone decide what are your priorities.

Take care.

[KungFuJosh]

Here's an idea. Grab a CSV file from the scope and plot it out in Excel and see how it looks.

[2N3055]

What are you implying? Some tricks or manipulations on my side? Are you questioning my integrity?

No second thoughts, and no cause to get defensive -- just the two questions mentioned earlier. Please take them at face value.

As I tried to explain before, it would make sense to me that the scope can draw traces on the screen at full resolution (only) if it gets the data to be plotted directly from the 12-bit capture buffer, under the circumstances described in my questions. So I would like to understand whether that is the reason for the different appearance of your screenshots vs. others I have seen.

I can obviously try this myself once I have an SDS HD scope. But the thing is that my decision whether to get an 800 or 1000 series scope will depend on what I can expect to see on the screen. So I would much prefer to understand this upfront, rather than create extra hassle for myself and Batronix by buying one model, then potentially having to exchange it.

I don't think the answer to those questions can be gleaned from the screenshots themselves. And unless I overlooked something, I don't think you have answered them yet. Pretty please?

Is it maybe that a single capture gets rendered differently -- plotted directly from the full-resolution data buffer? Did you capture these traces in the screenshot in Single mode; or did you stop the acquisition and then shift the displayed time window so the screen got redrawn from the buffer?

I'm not being defensive but wanted a clarification. We are both conversing in what is, to us, a second language. Better verify than presume...

All I did was start the scope, attached 1MHz squarewave into it, chose that timebase at random and you see results.
Plain as that.
I tried in both Stopped and Single. Made no difference.

I do not know why their images are different. Maybe they (them) cherry picked images to illustrate point they wanted to prove?
Or maybe simply, as I did, chose some random settings that resulted in those images. I don't know what they did.
You will have to ask them. I didn't answer that question , because it is not addressed to me.
I told you what I did, which is all I can answer. Sorry.

I'm not disputing their images.
I simply wanted to investigate statement that kept being repeated that 1000xHD draws 2 vertical pixels ALWAYS, and that 800xHD will probably too.
Well, now we know 800xHD for sure does not draw 2 vertical pixels ALWAYS.
That is all.

That is my data point. I leave further speculations about rendering implementations to others.

I personally didn't notice it until this discussion broke out. I had to use loupe to actually see it. That is how "big" problem this is in real life (pun intended).
I find implementation fine in normal work and will prefer not to waste more time on it.
There are many more interesting things (for me..) on the scope to investigate.

You guys have fun with this, if you like.

Best,

[ebastler]

I do not know why their images are different. Maybe they (them) cherry picked images to illustrate point they wanted to prove?
Or maybe simply, as I did, chose some random settings that resulted in those images. I don't know what they did.

You can look at any of Performa01's screenshots in this thread, typically captured in "Run" mode. I don't think he hand-picked them to make the scope look bad.   It's all consistent with the assumption that traces rendered from the FPGA "digital phosphor" buffer show the coarser pixilation, due to size constraints of that buffer.

I personally didn't notice it until this discussion broke out. I had to use loupe to actually see it. That is how "big" problem this is in real life (pun intended).

I agree that it is not obvious at all on the smaller SDS800X HD screen, which is why I am leaning towards an 824. I have said several times, in this and other threads, that I find it a disappointing design choice in the SDS1000X HD in particular, given its larger screen and the markup you pay for that.

As stated and shown in the other thread, I do find that traces look noticeably more jagged on the SDS1000X HD than on the DHO1000; no magnifying glass required. But -- as witnessed by the fact that I have returned my DHO1074 -- I fully agree that there are more important aspects to a DSO.

[Anthocyanina]

do these scopes have fine timebase adjustment? i've been wondering about this feature in modern scopes for a while. so far the only one i know for sure has this is the keysight 1000 series.

No. What would be the use case for this?

All contemporary Siglent DSOs have huge secondary buffers for measurements and math, and support gated measurements with separate gating cursors.

I find this feature to be useful all the time. Sometimes a waveform of interest won't fit nicely on the screen with the 1-2-5 steps, it either fits more than one period, or less, or the portion of interest either is too visually narrow on the horizontal axis, or goes beyond the screen at the next step.

For example, look at these waveforms of the switching node of a flyback converter:

using a timebase between 200 and 500ns/ let me fill more of the screen with the relevant portion of the waveform. using 500ns/ would have scrunched the high frequency ringing enough that you wouldn't distinguish it well enough, and using 200ns/ would have cut out the moment when the MOSFET turns on again.

[KungFuJosh]

It's a little weird that we can't do it since there's the manual entry option. It automatically rounds to either 200 or 500 in that space. I would think this feature could be implemented at any point if enough people want it.

[ebastler]

It's a little weird that we can't do it since there's the manual entry option. It automatically rounds to either 200 or 500 in that space. I would think this feature could be implemented at any point if enough people want it.

How does the scope handle "pinch and zoom" gestures on the touch screen? Does the horizontal scale also snap to the 10-20-50 grid, or is a continouos vernier control available in that way?

[ebastler]

Oh, one more question: Has anyone explored the maximum waveform update rates, for the 824 and/or its smaller siblings? There are some data in the recent post on X-Y mode; but I think Performa01 did not aim to hit the maximum rates there, but rather looked for a good balance of speed and data points per frame.

The datasheet specifies a higher update rate in normal mode for the 824. So this would also be a good check to see whether an "upgraded" 804 or 814 performs at the full 824 spec, or whether there is different hardware in the 824 which enables the higher waveform rate. I'm asking for a friend...