Siglent MSO logic probe impressions?

[pcee]

I know there’s a whole DIY thread on building your own probes in place of the SPL2016 logic probe set, but I haven’t been able to find anyone talking about how well the SDS2000X Plus ultimately works as a logic analyzer?

Does Siglent’s weird memory management effectively mean that it uses segmented memory?

Basically I’m trying to figure out whether for $400 I’m better off with the 16 channels on the scope or 8 channels with a Salae logic analyzer.

[kcbrown]

I know there’s a whole DIY thread on building your own probes in place of the SPL2016 logic probe set, but I haven’t been able to find anyone talking about how well the SDS2000X Plus ultimately works as a logic analyzer?

Does Siglent’s weird memory management effectively mean that it uses segmented memory?

Basically I’m trying to figure out whether for $400 I’m better off with the 16 channels on the scope or 8 channels with a Salae logic analyzer.

It depends entirely on your use case.  I can't tell from your message above whether you already have an SDS2000X+ series scope, so the below presumes that you don't.  Please don't be offended if you already know at least some of what follows.

The Siglent's memory management does indeed mean it uses segmented memory, essentially constantly.  The nature of it is that what you see on the screen is exactly what you're getting in a single segment of memory, and how many segments you get depends on the "points width" of the screen (sample rate multiplied by the time covered by the screen).  The upper bound of the points width of the screen can be set via the memory depth setting, and if you set that to a lower value than the maximum amount of points the scope supports then the number of segments you can capture will be at least the maximum points divided by the configured memory depth.  Of course, it can be more than that if the amount of time represented by the screen is sufficiently small that the maximum sample rate of the scope can't fill the configured memory depth.

Maybe it's simpler if I give examples. 

The 2000X+ has 10 divisions across.  Suppose you're using 2 analog channels in the same bank, so your maximum samples per channel is 100M points.  Let's suppose that you set the memory depth to the full 100M points.  With that setup, the maximum sample rate is 1G S/s.

If you set your time per division to be 100 ns, the screen width time would then be 10 times that, or 1us.  At 1G S/s, 1 us worth of time is 1000 points.  In the absence of per-segment overhead, that would get you 100K segments that you could capture. In reality, it'll be less.

Now let's presume that you set your timebase to 10 ms.  The screen now represents 100 ms worth of time.  At 1G S/s, that translates to 100M samples.  That eats the entirety of sample memory, so you only get one segment.

Now you drop the memory depth to 10M samples.  Because 1G S/s would fill that number of samples in 10 ms, but your screen width represents 100 ms, the scope has to cut the sample rate to a tenth of its maximum, or 100M S/s.  But now you have 10 segments.

The SDS2000X+ series has a zoom function that works very nicely.  The size of the screen allows for this.  This means that you can configure the scope's time width to match your acquisition needs and configure the zoom parameters to match your display needs, simultaneously.

The Siglent's approach to memory management gives you two advantages.  The first is the complete absence of ambiguity.  What you see on the screen (in the top portion in zoom mode) is exactly what you're going to get.  The second is the always-on nature of segments, which means you can always go back and review previously captured segments.  If you're capturing messages on a bus, this can be quite handy because you can set up your trigger to capture the message start, set up the display width to capture an entire message, and just go.  When you stop the scope, if you captured multiple messages, you'll be able to review as many as the number of available segments allow.  And each segment will be fully decoded by the scope, on demand (you can perform the capture and then configure the decoder to show the translation, after the fact).

If you're used to other more traditional digital scopes that capture more than just what's on the screen, this approach may take a bit of getting used to.  But you may find that you prefer it after you've worked with it a while, precisely because it eliminates a lot of guesswork and ambiguity that would otherwise be present.  And just for the record, most other scopes will also capture only what you see on the screen if the timebase is set long enough.   It really depends on where your operational focus is.  With the Siglent, the focus of the capture is on time.  With other scopes, that focus is on memory depth.  Time is arguably what you work with more directly and more often, so it is arguably the more appropriate parameter to design a capture system around.  But it really is a matter of personal preference in the end.


That said, for logic analysis, the Saleae might well be better.  I can't honestly say.  It depends on how you're going to use it.  The scope is useful for seeing the analog side of a digital signal, to do things like check for signal integrity and such, but the digital channels give you a lot more to work with for complex digital devices.  The Saleae's decoding might well be better or more flexible.  The Saleae's sample rate is much lower than the Siglent's digital channels, 100M S/s for the Saleae versus 500M S/s for the Siglent.  But on the other hand, the Saleae has a buffer that's probably limited by the computer you're on more than anything else, whilst the Siglent has a buffer of 50M points maximum per digital channel (this scales with the analog channel memory depth in relative terms.  If you set the analog depth to 20M points out of 200M points, the digital channels will likewise be set to 5M points out of 50M points, in order to keep the minimum number of available segments the same for both).

In any case, hopefully the above sheds some light on how this works.  The SDS2000X+ series is a pretty amazing bit of kit, but there are certainly going to be situations in which a dedicated logic analyzer is a better tool for the job.


There exist ultra-cheap Saleae logic clones out there that you might try first before making a real decision about the Saleae.  And honestly, if you're on the fence about the Siglent logic probe, I'd probably go with the DIY variety to start with, if only to see for yourself how well it can work for you, presuming it's an option for you at all.


One other thing: I don't know if the Saleae has any sort of segmented memory, but for certain use cases its absence can be a serious drawback.  That, along with the wide variety of triggering options on the Siglent (including, of course, the ability to trigger on analog events while capturing digital data), may give the Siglent approach a significant advantage.  It's something to consider, at least.

[2N3055]

I know there’s a whole DIY thread on building your own probes in place of the SPL2016 logic probe set, but I haven’t been able to find anyone talking about how well the SDS2000X Plus ultimately works as a logic analyzer?

Does Siglent’s weird memory management effectively mean that it uses segmented memory?

Basically I’m trying to figure out whether for $400 I’m better off with the 16 channels on the scope or 8 channels with a Salae logic analyzer.

In addition to excellent post by Kcbrown, I would just want to add:

When question is asked if you would be better served by MSO scope or a separate logic/protocol analyzer, first thing that have to be answered is : Do you need this primarily for hardware design on mixed domain devices, or do you primarily need it for software writing/debug and message analysis?

MSO scope is brilliant for analyzing things when data crosses physical (analog and pulse) world data and symbolic, encoded data (protocols etc.).

That means, for instance, if you're designing  multimeter, you need MSO to correlate analog part of circuit with digitally encoded message coming out of A/D converter.
Examples are many where you need this.

OTOH, if you have a system that exists of nodes that are exchanging messages, and your hardware works fine and all the trick is in software handling communications, protocol analysers are better at decoding large amount of data.

Of course lines are blurry and a deep memory scope can do a lot of decoding these days. In fact, best would be to have both, but if I had to choose, MSO scope with deep memory can do a lot of decoding and a MSO scope stuff. And protocol analyser can do only decoding. So if I had to choose, i would go with deep memory scope.
Unless of course you will solely debug complicated software protocol stacks all day long, in which case it is pure software work and protocol analyser is better fit..

[pcee]

Thank you, that was super helpful!

It sounds like the logic probes simply give me 16 more input channels on top of the 4 analog channels (but reduced to binary values only), and all the triggering and decoding is just the same as on the 4 built-in channels.  I wasn’t sure whether the probes unlocked any other unique functionality, but from your answer it sounds like not.

And each segment will be fully decoded by the scope, on demand (you can perform the capture and then configure the decoder to show the translation, after the fact).

I think this is my favorite feature of all, making exploring a lot easier!

The Saleae's sample rate is much lower than the Siglent's digital channels, 100M S/s for the Saleae versus 500M S/s for the Siglent.  … the Siglent has a buffer of 50M points maximum per digital channel (this scales with the analog channel memory depth in relative terms.  If you set the analog depth to 20M points out of 200M points, the digital channels will likewise be set to 5M points out of 50M points, in order to keep the minimum number of available segments the same for both).

Thank you, I was trying to get my head around the various limits, and you condensed it beautifully.  I’d need the $700 Salae to get 500M S/s on that platform, and then only 8 channels.

There exist ultra-cheap Saleae logic clones out there that you might try first before making a real decision about the Saleae.

That’s a great point. I can work with what I have, and then I “test drive” a Salae-like analyzer before taking the plunge.

(including, of course, the ability to trigger on analog events while capturing digital data), may give the Siglent approach a significant advantage.

And of course I can use the Siglent’s trigger out to trigger a Salae if I need more ambitious protocol decoding.

Thank you again for such a thorough explanation!

[kcbrown]

Thank you, that was super helpful!

It sounds like the logic probes simply give me 16 more input channels on top of the 4 analog channels (but reduced to binary values only), and all the triggering and decoding is just the same as on the 4 built-in channels.  I wasn’t sure whether the probes unlocked any other unique functionality, but from your answer it sounds like not.

I looked to see if you could trigger off of values seen by a "bus", i.e. a combination of multiple digital (and perhaps analog as well -- I haven't looked to see if you can put analog channels into a bus definition) inputs.  The closest thing I could find is the pattern trigger, which extends to both digital and analog channels.  I didn't find anything that actually makes use of your "bus" definitions.  That seems to be for display purposes only.

But yeah, the digital channels are basically a digital extension of the analog ones.  I haven't been able to find any significant functionality that is truly unique to the digital channels.

Thank you, I was trying to get my head around the various limits, and you condensed it beautifully.  I’d need the $700 Salae to get 500M S/s on that platform, and then only 8 channels.

Note that in the end, the digital channels are also analog in nature, in that they ultimately read an analog voltage from whatever they're connected to. So bandwidth limitations also factor into the maximum frequency that you can see with them.

The Siglent's minimum detectable pulse width is 3.3 ns (see https://siglentna.com/wp-content/uploads/2021/05/Digital-Probe-Datasheet-V20E201912.pdf).  That suggests to me a minimum period of 6.6 ns, which yields a frequency of 150 MHz.   The $700 Saleae unit has a maximum of 100 MHz.  So the Siglent seems to win even against the Saleae with the same sample rate, with respect to the maximum digital signal frequency that can be captured by the digital channels.

That’s a great point. I can work with what I have, and then I “test drive” a Salae-like analyzer before taking the plunge.

And you may find that the cheap clone is enough for your purposes, too, with respect to the use case you'd have for such a device.

And of course I can use the Siglent’s trigger out to trigger a Salae if I need more ambitious protocol decoding.

Presuming the Saleae can handle input triggers in the first place, yes.  I honestly don't know what it's capable of in that department.  And, of course, the triggering mechanism would have to allow you to see some amount of data that precedes the trigger point, because there will be a delay between the time of the actual trigger event itself and the time the Saleae receives the trigger signal from the scope.

A cheap clone should make it possible for you to experiment with these things.

Thank you again for such a thorough explanation!

My pleasure!

[Performa01]

The bus definition includes digital channels only and it’s used for parallel bus decoding. Yes, it can be said it’s just a display option (like any decoder). We can have up to two individual parallel buses.

Triggers that can also use digital channels are: Edge, Pulse, Interval, Dropout, Serial and Pattern.
Pattern trigger can include analog and digital at the same time, so it’s the most suitable for mixed signal work.

Users should be aware that there is a significant difference between analog and digital channels: analog timing is accurate to the picoseconds (because of sin(x)/x reconstruction in the trigger engine), whereas digital channels provide no data for such mathematical tricks and use a lower sample rate on top of that.

In practice this means that the digital edge detection has an uncertainty of 2 ns by nature because of the 500 MSa/s sample rate – if we’re using a digital channel as the trigger source. In practical terms this means that the first edge as well as the pulse width will jitter by the discrete value of 2 ns. Any related analog waveform will also show a jitter of some 2 ns peak to peak.

The trigger point of any triggered analog waveform (as it is visible on the screen and used by measurements) has a position relative to the sample clock edge that will vary by +/-0.5 sample clock periods randomly. That’s the reason why we still get a nearly contiguous trace without the need of interpolation in dots mode.

All together we should be prepared for higher jitter for both the displayed pulse position and pulse width with regard to the true pulse, whenever we use an analog signal as the trigger source.

Of course the digital edge jitter of 1 sample clock is nothing new and applies to every logic analyzer that has not been synchronized to the clock of the system under test (which is usually done for state analysis, but not timing analysis). Yet the trigger from analog channels (not available on logic analyzers) introduces some additional jitter – which becomes obvious especially on the MSO, because the stable analog waveforms can be used as a reference, also visually.