Siglent SDS2000, A Short Video Review

[Herman]

[Hydrawerk]

Thank you for the video.

[uboot]

Even if it's short, I won't call it a 'review'. More like a short 'product demo ad'. 

With such a head line, you're creating lots of expectations in us forum members - you'd better start meeting them now, doing more testing videos, or all you'll get back is disappointed ranting

[marmad]

Even if it's short, I won't call it a 'review'. More like a short 'product demo ad'. 

The DSO definitely looks like an interesting product - but, yes, I agree with uboot: please, for clarity's sake: you (and the person who made the video) clearly work for Siglent. I understand English is not your native language, but a "review" implies "To examine with an eye to criticism". This is not a review - it's a demo.

[zaoka]

Pricing info?

[marmad]

Pricing info?

Some estimated prices in Euros posted in another thread.

[BeerCannon]

Where did you buy it, and how much?

Not sure why we needed to see the SDG 5000 Series waveform generator, especially if the scope has one built-in. 

These scopes are really tall.. too tall for my workbench, but perhaps a bonus when viewing 4 traces.

[marmad]

Where did you buy it, and how much?

Really? You think the YouTube poster bought it? 

[BeerCannon]

Where did you buy it, and how much?

Really? You think the YouTube poster bought it? 

No, I don't.  But I thought I'd give him a chance to convince me otherwise.

[marmad]

No, I don't.  But I thought I'd give him a chance to convince me otherwise.

I particularly like the empty room with a bare table that is his workspace/bench. 

You can see more of it in his one other posted YouTube clip:



Edit: Ha, ha... yeah, both of us looking at YouTube simultaneously.

[BeerCannon]

The same YouTube account has a video of an SDS2304 (4-channel) version with it's external trigger connected to what looks like an SDS1102CML to count the waveform capture rate.  Much like the video someone did of the DS1000Z series scope connected to a DS1000E series scope.  There's no audio on the video right now.. perhaps waiting for an English overdub (and/or a script)?

Edit: we must have cross posted about the other video.. haha.

[marmad]

The DSO definitely maintains nice capture speeds with 2, 3, and 4 channels on simultaneously.

I've never seen any owners of a DS4000 posting wfrm/s rates with multiple channels on, but judging by the DS2000/DS1000Z rates, I doubt Rigol's DS4000 can match those percentages.

[uboot]

The video proofs nothing. It's the same with the Uni-Trend UTD2xxxCM-Series claiming 150k waveforms /s capture rate.

Even if the scope manages to trigger and capture at high speed, the captured waveform has to be processed / transferred to some persistence / dpo-like display buffer at the very same speed.

[marmad]

The video proofs nothing. It's the same with the Uni-Trend UTD2xxxCM-Series claiming 150k waveforms /s capture rate.

Well, no, it's not the same as the Uni-T.

First, it has a Trigger Out - which, by convention, are the captured Triggered Ins - so at least it can be measured (the Unit-T has no Trigger Out). Of course, this doesn't guarantee that they process every single waveform connected to those Triggers - but the same can be said for EVERY DSO that has a high waveform capture rate - including, among others, the Agilent X-3000's 1 million wfrm/s.

Second, it has a database buffer and intensity-grading - so it has a process whereby to display the high capture rate. The Uni-T does NOT have intensity grading - so no process.

So, IMO, there is no comparison between the two scopes - one is a DPO, the other is a DSO.

Also, we have yet to see a picture of the inside of a UNI-T UTD2102CM, but trust me, it will never look anything like this:

[uboot]

Trigger out proves as much as the hardware trigger frequency counter used by Uni-T I'm afraid...

And intensity grading... well... it actually needs _more_ processing than a simple persistence mode as used within low-cost scopes, so this is no indication as well.


I think we need to make a clear distinction between waveform _capture_ rate and waveform _processing_ rate.


Glitch benchmarks needed.

[marmad]

Trigger out proves as much as the hardware trigger frequency counter used by Uni-T I'm afraid...

I'm not sure what you're talking about... you mean the frequency counter on the Uni-T? This has nothing to do with triggers (only the input signal itself) and is nothing like a Trigger Output.

And intensity grading... well... it actually needs _more_ processing than a simple persistence mode as used within low-cost scopes, so this is no indication as well.

Yes!! That's the point - a oscilloscope with intensity-grading has more processing power than one without.

Did you look at the PCB of the Siglent? Do you know what DPO (and fast waveform capture) architecture looks like?

This is definitely a fast DPO - no doubt about that. I'm more curious to see how nicely the UI works - and how well things like segmented memory are implemented.

[uboot]

I'm just afraid that the term waveform update rate has become a new marketing buzz word for scope manufacturers, omitting the fact that the true waveform processing rate, i.e. the rate at which the scope manages to transfer samples from fast FIFO buffer to DPO buffer, is way more important.

Trigger out proves as much as the hardware trigger frequency counter used by Uni-T I'm afraid...

I'm not sure what you're talking about... you mean the frequency counter on the Uni-T? This has nothing to do with triggers (only the input signal itself) and is nothing like a Trigger Output.

According to the manual it is a hardware frequency counter that counts trigger frequency.

And intensity grading... well... it actually needs _more_ processing than a simple persistence mode as used within low-cost scopes, so this is no indication as well.

Yes!! That's the point - a oscilloscope with intensity-grading has more processing power than one without.

Did you look at the PCB of the Siglent? Do you know what DPO (and fast waveform capture) architecture looks like?

This is definitely a fast DPO - no doubt about that. I'm more curious to see how nicely the UI works - and how well things like segmented memory are implemented.

You're right, but I'd like to distinguish between processing power and processing complexity.

Intensity grading is more complex than simply persistent mode.

To achieve the same waveform processing rate with intensity grading, more processing power is needed.

But a scope featuring intensity grading does not automatically have more processing power. Of course it should, but for simple marketing purposes you can implement intensity grading which is just a software feature and keep your hardware as (cheap) as it was.


Also, you can't tell from the screen update rate, how fast waveform processing is because your eye trigger (aka shutter speed ) is almost saturated at 50 frames per second.

Just give priority to the UI, e.g. with a dedicated snappy ARM SoC, and the scope feels flashy.


We're talking about 2000....50,000....150,000 waveforms per second. No way that you can verify this by screen refresh rate.

You need some glitch generator - periodic signal + spurious glitches like Dave uses in his reviews - and then watch if the glitch becomes visible at some time or if the scope misses the glitch.

[marmad]

According to the manual it is a hardware frequency counter that counts trigger frequency.

But this is almost certainly, without a doubt, another of the MANY English and translation mistakes they make in the manual. This would make no sense - and be unlike every other DSO on the market. Virtually every DSO has a "built-in 6-bit hardware frequency measuring meter" (which is what they call it on the 11th page of the manual) for measuring the frequency of the INPUT signal - NOT the trigger.

But a scope featuring intensity grading does not automatically have more processing power. Of course it should, but for simple marketing purposes you can implement intensity grading which is just a software feature and keep your hardware as (cheap) as it was.

That would be very difficult to do. It only takes about one minute of using a DSO with intensity-grading to feel that it is WAY different (and way faster) than persistence mode. They are not alike at all - except in the fact that they can use similar shades of color. This involves significant differences in the design of the PCB and FW implementation.

We're talking about 2000....50,000....150,000 waveforms per second. No way that you can verify this by screen refresh rate.

Nobody said you could. But having used a DSO with intensity-grading for the last year, I can tell you that it's obvious via the intensities when you increase the capture rate by a factor of 10x; in other words, when you increase from 100 to 1k wfrm/s - or from 1k to 10k wfrms/s, etc - it's clear as a bell. The Siglent is clearly capturing and processing many many waveforms per second - but I couldn't say the same thing about the Uni-T.

You need some glitch generator - periodic signal + spurious glitches like Dave uses in his reviews - and then watch if the glitch becomes visible at some time or if the scope misses the glitch.

This is a cumbersome method which involves running the same test many times over to find the correct answer: it's an average (law of probabilities). In a nutshell (although this might seem identical, it isn't): you can't prove how fast a DSO is - only how slow it ISN'T.

[uboot]

According to the manual it is a hardware frequency counter that counts trigger frequency.

But this is almost certainly, without a doubt, another of the MANY English and translation mistakes they make in the manual. This would make no sense - and be unlike every other DSO on the market. Virtually every DSO has a "built-in 6-bit hardware frequency measuring meter" (which is what they call it on the 11th page of the manual) for measuring the frequency of the INPUT signal - NOT the trigger.

For me it doesn't make a difference if it's a typo / mistranslation. Don't wanna argue here. This 'typo' just gave me a hint on how they may have calculated their waveform capture rate: 1GSa/s divided by 6K sample buffer = 166,666 "waveforms per second"   

But a scope featuring intensity grading does not automatically have more processing power. Of course it should, but for simple marketing purposes you can implement intensity grading which is just a software feature and keep your hardware as (cheap) as it was.

That would be very difficult to do. It only takes about one minute of using a DSO with intensity-grading to feel that it is WAY different (and way faster) than persistence mode. They are not alike at all - except in the fact that they can use similar shades of color. This involves significant differences in the design of the PCB and FW implementation.

One minute of _which_ intensity-graded DSOs?

We're talking about 2000....50,000....150,000 waveforms per second. No way that you can verify this by screen refresh rate.

Nobody said you could. But having used a DSO with intensity-grading for the last year, I can tell you that it's obvious via the intensities when you increase the capture rate by a factor of 10x; in other words, when you increase from 100 to 1k wfrm/s - or from 1k to 10k wfrms/s, etc - it's clear as a bell. The Siglent is clearly capturing and processing many many waveforms per second - but I couldn't say the same thing about the Uni-T.

Sure - intensity grading was introduced first on more expensive DSOs whose trustworthy (?) manufacturers definitely (? I hope so) assured that there is enough processing power behind.

I just don't wanna get tricked by eye candy and snappy GUI - which is _very_ easy, just put a decent ARM SoC into the scope and let it do some intensity grading - this will still look fast if it is done with only 100 waveforms per second...

We need more reliable demos on real waveform processing rates / glitch visualization abilities. A simple sine wave as shown in the video isn't enough. That's why I called for a 'real-world example' aka glitch generator like the one Dave used in his review of the 200MHz hackable Tekway/Hantek.


Cumbersome? Maybe.... Alternatives? I only know of this one: https://www.eevblog.com/forum/testgear/a-simple-technique-to-measure-waveform-update-rates-on-dsos-with-no-trigger-out/

[marmad]

I just don't wanna get tricked by eye candy and snappy GUI - which is _very_ easy, just put a decent ARM SoC into the scope and let it do some intensity grading - this will still look fast if it is done with only 100 waveforms per second...

If you send a constantly changing signal (e.g. AM signal) to a DPO having 64/256 levels of grading - you can see INSTANTLY the difference between 500 wfrm/s, 5000 wfrm/s, and 50k wfrm/s (as I can see on my Rigol). Sorry, but you can't "fake" a much faster update rate with 100 wfrm/s when it has intensity grading. The Siglent, as shown in these videos and the ones at the other thread, has a fast update rate - no doubt about it.

This is the reason no one is bothering to do precise glitch tests on DSOs with intensity-grading (and just trusting the Trigger Out readings) - because it's easy to tell the difference between slow, fast, and very fast waveform update rates with these DSOs. The intensity levels * the refresh rate of the LCD = thousands of bits of information per pixel possible per second.

We need more reliable demos on real waveform processing rates / glitch visualization abilities. A simple sine wave as shown in the video isn't enough. That's why I called for a 'real-world example' aka glitch generator like the one Dave used in his review of the 200MHz hackable Tekway/Hantek.

I love Dave's videos - but glitch tests only make sense when run for long periods of time - otherwise they are worthless; it's about probabilities. A DSO that does 10 wfrm/s can capture a glitch that occurs once every 10,000 cycles in the very first second it tries; but the question is: how many times can it do it over a longer period of time?

Cumbersome? Maybe.... Alternatives? I only know of this one: https://www.eevblog.com/forum/testgear/a-simple-technique-to-measure-waveform-update-rates-on-dsos-with-no-trigger-out/

Well, thanks for posting the link to the method I developed  , but unfortunately it only works on a small subset of DSOs with an Every (as opposed to Alternate) Rising and Falling Edge trigger - and even then, it has to be done very carefully to find the very first blind-time gap (as opposed to wfrm/s frequency multiples).

[marmad]

I'm just afraid that the term waveform update rate has become a new marketing buzz word for scope manufacturers

BTW, I agree with this previous statement of yours. IMO, if you want to buy a DSO to last you for a few good years into the future (and feel satisfied with it), it's really only important that it have intensity/color grading and a reasonably high waveform capture rate at the smaller time bases; anything around ~10k wfrm/s is fine.

[uboot]

If you send a constantly changing signal (e.g. AM signal) to a DPO having 64/256 levels of grading - you can see INSTANTLY the difference between 500 wfrm/s, 5000 wfrm/s, and 50k wfrm/s (as I can see on my Rigol). Sorry, but you can't "fake" a much faster update rate with 100 wfrm/s when it has intensity grading. The Siglent, as shown in these videos and the ones at the other thread, has a fast update rate - no doubt about it.

I also thought about that, e.g. white noise should quickly turn into a red bar. But I'm still not convinced how update speed of the intensity view translates into thousands of waveforms processed per second.

This is the reason no one is bothering to do precise glitch tests on DSOs with intensity-grading (and just trusting the Trigger Out readings) - because it's easy to tell the difference between slow, fast, and very fast waveform update rates with these DSOs. The intensity levels * the refresh rate of the LCD = thousands of bits of information per pixel possible per second.

The question for me is: at which _rate_ is intensity computed?
 
Even if intensity grading is applied only to the visible screen area and imagine we have a visible waveform of 512 8bit samples and 64 (6bit) intensity levels => we still need 512x256x6bit=96KBytes for the intensity buffer. Persistence buffer would require only 512x256bits=16KBytes.

For 50k waveforms per second, this means: 50k x 96KB = 4,5GB throughput per second.

Now, the SoC used for the GUI may read from the intensity buffer with slow speed and take ages to scale the date to the screen size, doesn't matter - all necessary info has been already captured and processed. Even 10fps screen refresh won't hurt here.


On the other hand, for 50 frames per second screen refresh rate, a mere 96KBx50 = 5MB of throughput is needed for the intensity view. Instead of using expensive memory for intensity buffer + dedicated ASIC/FPGA for intensity computation, the SoC could do intensity grading by itself by grabbing just a potion of the sample buffer every now and then (modern SoCs have dual or quad cpu cores, with a multi-threaded GUI, enough resources are left for fast response to user interaction) - with a Sine wave and rotating the frequency knob on the function generator, no-one would notice a difference.

I love Dave's videos - but glitch tests only make sense when run for long periods of time - otherwise they are worthless; it's about probabilities. A DSO that does 10 wfrm/s can capture a glitch that occurs once every 10,000 cycles in the very first second it tries; but the question is: how many times can it do it over a longer period of time?

ack

Well, thanks for posting the link to the method I developed  , but unfortunately it only works on a small subset of DSOs with an Every (as opposed to Alternate) Rising and Falling Edge trigger - and even then, it has to be done very carefully to find the very first blind-time gap (as opposed to wfrm/s frequency multiples).

You're welcome I very much like that idea and I wish there was a workaround for scopes with different triggering.

[marmad]

On the other hand, for 50 frames per second screen refresh rate, a mere 96KBx50 = 5MB of throughput is needed for the intensity view. Instead of using expensive memory for intensity buffer + dedicated ASIC/FPGA for intensity computation, the SoC could do intensity grading by itself by grabbing just a potion of the sample buffer every now and then (modern SoCs have dual or quad cpu cores, with a multi-threaded GUI, enough resources are left for fast response to user interaction) - with a Sine wave and rotating the frequency knob on the function generator, no-one would notice a difference.

Look at Dave's video review of the GW-Instek GDS-2000A series. It appears from the video (and Dave's subsequent teardown) that Instek might have used the SoC for doing the meager 16 levels of intensity - instead of a dedicated ASIC/FPGA. And what occurs is a stuttering and freezing of the display updating on occasion.

I suspect if your idea was feasible (and I'm sure it's been tested by DSO manufacturers trying to cut production costs), it would have already surfaced in a product.

[Hydrawerk]

The memory was set to 14kpoints, as seen in 0:19. And the scope has LeCroy-like rotary knobs! 

[uboot]

On the other hand, for 50 frames per second screen refresh rate, a mere 96KBx50 = 5MB of throughput is needed for the intensity view. Instead of using expensive memory for intensity buffer + dedicated ASIC/FPGA for intensity computation, the SoC could do intensity grading by itself by grabbing just a potion of the sample buffer every now and then (modern SoCs have dual or quad cpu cores, with a multi-threaded GUI, enough resources are left for fast response to user interaction) - with a Sine wave and rotating the frequency knob on the function generator, no-one would notice a difference.

Look at Dave's video review of the GW-Instek GDS-2000A series. It appears from the video (and Dave's subsequent teardown) that Instek might have used the SoC for doing the meager 16 levels of intensity - instead of a dedicated ASIC/FPGA. And what occurs is a stuttering and freezing of the display updating on occasion.

Drop in a faster multi-core SoC + multithreaded GUI and you are done in the first place.

I suspect if your idea was feasible (and I'm sure it's been tested by DSO manufacturers trying to cut production costs), it would have already surfaced in a product.

Feasibility in terms of performance or sales?

I suspect DSO manufacturers will notice that intensity grading eye candy and snappy GUI is an important selling point which can be had almost for free just by a SoC replacement and some software engineering, so sooner or later it will be introduced to their low end lines. Doing it in hardware with high throughput will still be reserved for high end.



Now, slowly getting back to the topic - the mainboard of the Siglent above indeed looks interesting