Direct comparison aspects on Siglent SDS2000X Plus vs. SDS1000X HD

[ebastler]

The video posted by ebastler was simply showing exactly that behaviour - and proofing that the Rigol approach with the HDMI out - showing 1:1 (!) the same picture as the scope display is much better and more adult - of course just for THAT application of viewing a larger image without any loss of information !

Note that the external screen on the Rigol in that video is also showing the web interface. So it's possible to get faster updates via a web view; the limitation for the Siglent scope is not on the browser end. It would be interesting to understand what makes the difference here -- is Rigol pushing images in a more compressed format, or are there different HTML/Javascript/whatever mechanisms to render video streams which differ in achievable frame rate?

On the other hand, the frame rate on the built-in screen is noticeably higher for the Siglent scope in that video. (Assuming that the acquisition and trigger settings were the same for both contestants.)

[KungFuJosh]

For that early "discovery" phase, I want a screen with fast updates, i.e. reasonably high frame rates. That's why I would not consider the Siglent web interface as my main UI at the bench (and I don't think it was meant to be that).

I agree with this in general. I wish Siglent would have a framerate option for the web UI. However, most of the time, the web UI has been fine for me. I often setup the trigger at the scope before monitoring from the web. My desk and work bench are right next to each other, so going back and forth is probably easier for me.

[Uli Auer]

Note that the external screen on the Rigol in that video is also showing the web interface. So it's possible to get faster updates via a web view;

Ah. Good to know - did not realize that.....thought it was the "direct" HDMI.....that also explains the broad white frame around the scope image which made me wonder for a short moment why it's white instead of my black frame on my (too big) screen with the HDMI output...

[Anlefu]

I get a 16 channel digital  (SPL2016） manual created by an engineer in a web sales platform(taobao idlefish)， only cost ￥250≈￡40.
It works all ok.

[Anlefu]

Good news：
Geeker version will be cheap enough ，only need ￥250≈￡40。

Bad news:
totally manual created, this guy only for interest to share this sample version. need to wait for months before delivery.

But anyway, this Geeker version works as same as officer version.

[ebastler]

Good news：
Geeker version will be cheap enough ，only need ￥250≈￡40。

Bad news:
totally manual created, this guy only for interest to share this sample version. need to wait for months before delivery.

But anyway, this Geeker version works as same as officer version.

In the context of the present thread, it's worth pointing out that this probe works with the SDS2000X plus and the 2000X HD and higher. The 1000X HD uses a different, external logic analyzer module, as do the 800X HD and the earlier 8-bit SDS1000... scopes.

There is a dedicated thread on DIY alternatives to the SPL2016. Maybe post your update there: https://www.eevblog.com/forum/testgear/diy-logic-analyzer-probe-and-pods-for-siglent-scopes/

[David Hess]

There are some parameters from the data sheets I can't evaluate whether they really make an important difference or in which application,
(A = SDS2000X Plus, B = SDS1000X HD) for example:

- (analog aquisition) peak detect:      A: 1ns         B: 2ns minimum detectable pulse

This is the sample interval in the trigger signal path. Modern DSOs have a fully digital trigger engine, which not only allows for very complex triggers but also ensures sufficient trigger bandwidth. Without diving into the basics of DSO operation, it can be said that this is the shortest pulse width the scope can reliably detect (and trigger on).

What does peak detection have to do with triggering?

DSOs with digital triggering use the vertical signal path and digitizer in place of a separate trigger path, so trigger bandwidth is identical to vertical bandwidth.  The trigger pickoff is "digital", inside the logic between the digitizer and acquisition memory.  DSOs with analog triggering may have trigger bandwidth which is higher or lower than the vertical bandwidth.

Peak detection happens during decimation where the highest and lowest values are captured for a given sample interval in the acquisition record.  If no decimation takes place because the acquisition record is long enough to capture the full sample rate, then peak detection at this point is not required.  This leads to the minimum detected peak width being the same as the sample interval of the digitizer, so 500 MS/s yields 2 nanoseconds, 1 GS/s yields 1 nanoseconds, etc.

Decimation of some type also occurs to convert the acquisition record to the display record; 10s of thousands of samples cannot be entirely displayed on a screen with limited horizontal resolution.  Some DSOs take special measures here to make sure the peaks are preserved and not erased by anti-aliasing.  Very old DSOs without index graded displays do not have to worry about this, but even the first DSOs with index graded displays handled this somehow.

[Performa01]

What does peak detection have to do with triggering?

You answered this question yourself. Or didn't you?

The trigger signal path (which you think doesn't exist) has the virtue of a constant sample rate, regardless of the number of channels in use and independent of the timebase. It is also this separate path (=data stream) where trigger coupling and filtering takes place.

Have I really been so unclear? The shortest detectable pulsewidth is of coursee related to the sample rate in the triggerpath, which would usually be the same as the max. samplerate with all channels on, e.g. 1 GSa/s in a 4-channel DSO with 2x2GSa/s ADCs.

[David Hess]

The trigger signal path (which you think doesn't exist) has the virtue of a constant sample rate, regardless of the number of channels in use and independent of the timebase. It is also this separate path (=data stream) where trigger coupling and filtering takes place.

Within the context of digital triggering, I said, "The trigger pickoff is "digital", inside the logic between the digitizer and acquisition memory."  Do you not read that or did you not understand it?

Have I really been so unclear? The shortest detectable pulsewidth is of coursee related to the sample rate in the triggerpath, which would usually be the same as the max. samplerate with all channels on, e.g. 1 GSa/s in a 4-channel DSO with 2x2GSa/s ADCs.

I was being tactful and asked for clarification, instead of simply calling you wrong.

The trigger path has nothing to do with peak detection.  Presumably they share the same sample rate, but that does not have to be the case.  It would not surprise me if the trigger signal path is decimated to the sample rate used when all channels are active, for consistency.  Peak detection occurs on the vertical digital signal path as part of decimation which is after the trigger pickoff.

[Performa01]

I was being tactful and asked for clarification, instead of simply calling you wrong.

Sorry, I thought it would be very clear that I used the sample rate in the trigger path as the indicator for the maximum sample rate. And I couldn’t believe someone with good intentions would be so finicky and imply that I said peak detection is accomplished in the trigger signal path somehow.

Presumably they share the same sample rate, but that does not have to be the case.  It would not surprise me if the trigger signal path is decimated to the sample rate used when all channels are active, for consistency.

Within the context of digital triggering, I said, "The shortest detectable pulsewidth is of course related to the sample rate in the triggerpath, which would usually be the same as the max. samplerate with all channels on, e.g. 1 GSa/s in a 4-channel DSO with 2x2GSa/s ADCs"  Do you not read that or did you not understand it?

Btw: in my limited understanding of the English language, “related to” is not the same as “depends on”.

The original question was about a specific detail in the SDS2000X Plus datasheet, i.e. the minimum detectable pulse. This specification is related to the minimum undecimated acquisition sample rate, hence related to the trigger sample rate.

And for me, there’s no need to speculate about the sample rate in the trigger path, because we’re talking about Siglent DSOs specifically. And there is certainly no such thing as “decimation to the sample rate when all channels are active”.

For those wondering how it really works: the trigger signal is tapped off one single data stream of the ADC that corresponds to the channel which we want to trigger on. In full channel mode the acquisition data rate is the same as the trigger data rate. In half channel mode, the two streams of an ADC are combined (interleaved) for obtaining twice the sample rate. Yet the data rate in the trigger path remains unchanged.

Of course, it could happen that we see (detect) a pulse somewhere within a record in half channel mode, but at the same time cannot trigger on. But that’s in theory only, because the bandwidth of the frontend will limit the usable minimum pulse width so that even the full channel sample rate will always be sufficient.

[rf-loop]

First of all, I think the Perfoma01 explanation is completely correct all the time - of course. It's a little confusing that some people don't want to understand it (especially when not at all thoroughbred beginner - in which case it would be very understandable).

I don't really understand how the "peak detect" function is also mixed in here, which only works when the ADC data can only be exported to the acquisition memory as decimated (the binding of the trigger time is also now incomplete compared to the full non-decimated data sequence. However, this is not important in this mode of operation in general) .

The minimum pulse width that can be triggered and the minimum pulse width that can be visually detected must be kept in mind slightly separately when we read the Siglent data sheet. At this point, it might be good to open the device's hardware features a bit. However, we can't dive into that very deeply because it's not public information. However, one can find out quite a lot when open the data sheets of used AD converters. It is known, based on many observations, that the Trigger engine always receives the same non interleaved data stream, regardless of the possible decimation before acquiring the memory. (So in ADC chip interleaved mode only one half) Of course we already know this, but anyone can find out that knowledge themselves empirically if they want to and are able to.

Of course, it is sometimes possible to detect (detectable by eyes) narrower pulses/spikes on the screen than mentioned in the data sheet. For example, when the undecimated data flow to the memory and thereby to the screen is higher than the sample rate that the trigger engine sees. But you can't trigger them (except perhaps occasionally, if the visible pulse happens to be in the data that the trigger engine saw. Of course, the response of the analog front end also comes as a limitation here)

[David Hess]

I don't really understand how the "peak detect" function is also mixed in here, which only works when the ADC data can only be exported to the acquisition memory as decimated (the binding of the trigger time is also now incomplete compared to the full non-decimated data sequence. However, this is not important in this mode of operation in general).

DSOs with digital triggering probably use a fixed table of values of the timing relationship between the trigger and position within the acquisition record.  It is all DSP, so it should never vary.  DSOs with analog triggering usually or always measure and store this value as part of the time delay counter calibration whenever the decimated sample rate changes because the analog section may drift several sample periods over time and temperature.

Nothing requires this timing relationship to be in units of decimated sample rate of the acquisition record, or even in units of the undecimated sample rate.  In old Tektronix oscilloscopes, it has a resolution many times higher than the resolution of the acquisition record or undecimate sample rate, which makes sense because this is required to support equivalent time sampling.  Newer instruments do not provide enough operational details to know how this is handled, but the interpolation required for the trigger should provide practically arbitrary resolution.  Time delay counters using the same method of trigger measurement as a DSOs digital trigger, and comparable hardware, can provide 10s of picoseconds of resolution.

Of course, it is sometimes possible to detect (detectable by eyes) narrower pulses/spikes on the screen than mentioned in the data sheet. For example, when the undecimated data flow to the memory and thereby to the screen is higher than the sample rate that the trigger engine sees. But you can't trigger them (except perhaps occasionally, if the visible pulse happens to be in the data that the trigger engine saw. Of course, the response of the analog front end also comes as a limitation here)

Tektronix sometimes specified the certainty of capturing a pulse depending on pulse width.  For instance on a 2440 CCD based DSO at 500 MS/s and 300 MHz:

2 Nanoseconds - 50% or greater amplitude at 85% or greater confidence.
4 Nanoseconds - 50% or greater amplitude.
8 Nanoseconds - 80% or greater amplitude.

But the 2440 uses a very unusual peak detection method based on how CCD sampling works.  Their more conventional DSOs at the time simply say 10 nanoseconds at 100 MS/s or 100 nanoseconds at 10 MS/s.  I tested this using a fast pulse generator and they always captured the full pulsed height if the pulse was greater than the sample period, and intermittently captured the pulse in proportion to the pulse width with a variable pulse height depending on the rise/fall time when it was shorter than the sample period, which is exactly what one should expect of a sampling process with short aperture time.  Modern DSOs should perform no differently as they are facing the exact same limitations and do peak detection in exactly the same way.

[Performa01]

On the catchword “10 ps resolution” we can use the automatic measurements to demonstrate how even entry-level oscilloscopes can do fairly accurate time measurements down to the picoseconds, despite their moderate sample rate.

The test setup includes a stable 500 MHz sinewave, fed into channels 2 and 4 of an SDS2504X Plus (early SDS2304X Plus with 500 MHz option) via a resistive power splitter. First, we use two identical cables, each 200 mm long:


SDS2354X_Plus_skew_200+200mm

The (gate) cursors are there only because I had to use a time gate for the T@M measurements.

Even at 500 ps/div we can barely see the skew of <8 ps between the two signals. This means the total length difference of the two signal paths is less than 1.6 mm.

The distance of the first rising ede to the trigger point at 20% is -2.62 ps on average in the triggered channel and +6.17 ps in the other channel. The difference (skew) is ~7.79 ps on average.

How can we know the resolution? Well, the standard deviation of the skew measurement is 3.38 ps and the peak-to-peak variation is 22.5 ps. The mean value of the measurement statistic is stable.

Another hint is the fact, that the Channel Deskew in the channel menu can be set with 10 ps resolution. Finally, we’ve got the math function interpolate() which allows a maximum of 20. This corresponds to a sample interval of 25 ps and we have no reason to believe that this very same function would not be used internally as well.


Now that we’ve seen a channel skew close to zero, we want some defined delay. Unfortunately, I don’t have the exact same microwave cable in a slightly different length, but a similar one, which is also about 50 mm shorter. I can only assume it’s dielectric has the same velocity factor. Anyway, I’ve replaced the cable to channel 2 with the shorter one – see what we get:


SDS2354X_Plus_skew_150+200mm

50 mm difference at a velocity factor of 0.66 should result in a channel skew of 250 ps. Lo and behold, the measurement says 243,5 ps – 6.55 ps too low, that is not too far off!

If we calculate the length difference corresponding to 6.55 ps at a velocity factor of 0.66, then we get ~1.3 mm. And this seems totally correct. The 200 mm cables have a right-angle plug on one end and a straight one at the other end. The 150 mm cable has two right-angle plugs. I think this explains the 1.3 mm length difference, i.e. the 150 mm cable is a tiny bit longer than initially calculated.

This shows that a serious DSO can do very precise high resolution time measurements, even if it’s only entry level class. Even the SDS824X HD can do pretty much the same in this regard. An SDS7000A on the other hand does a ten times better job and the standard deviation of skew measurements is just ~285 femtoseconds.

[tautech]

An SDS7000A on the other hand does a ten times better job and the standard deviation of skew measurements is just ~285 femtoseconds.

Please please show/demonstrate.