Siglent SDS2000X Plus

[tautech]

Hi there,

I'm having a problem with the SPI Decoder: After capturing an SPI sequence, which works well and shows the correct data (in the list view), I'd like to zoom in to see the full binary data also in the line view (where it is abbreviated). Hoewever, the full binaries only flash shortly and then vanish - I then see only two lines of MOSI and MISO, and no decoded data at all. It vanishes also from the list view. I only zoom up one additional level - and everything is gone (though signals of several bytes are on the screen). When I zoom back out, the abbreviated numbers return...

Am I just too stupid to use this correctly, or is it a bug? I'm using the latest firmware of the scope.

Cheers,
Anik

Simply, Siglent DSO's with deep memory are optimized for zoom in and the best way to use the deep memory is to capture long (slow) and zoom in for detailed inspection.
Zoom mode works well here using by the dual timebase feature and pan through the record or scroll the decode table.

Thanks, tautech, I totally had missed that! Using the zoom function/dual time base I get what I wanted and wasn't able to find   
Did I overlook all that in the documentation of the scope? I couldn't find a detailed description of the LA features and their use yet.

Cheers, Anik

No but just be sure you are referring to the latest manual version.
https://int.siglent.com/u_file/document/SDS2000X-Plus_UserManual_EN01C.pdf

TBH writing a manual that covers all usage types and user experience would fill several volumes especially if it incorporated 'we'll walk you through this while holding your hand' sections so the capabilities are only briefly explained and the rest should be learnt by doing. Having had most of their models over the years and while each has different capabilities and features I guess I find it all reasonably simple excepting some of the new and advanced features.

These Plus keep surprising the new buyer with their capability for the $ spent which also can work against them as while the spend is not great but the step up in experience required when coming from a basic DSO is.

Still, there's enough of these out there now there's quite a community willing to help those that are still finding their feet. Keep asking questions and someone will help.

[highpower]

SP2035A reduction is from $179 to $75 and is certainly very well priced now.

I don't know if that was a typo or if they have raised the price already. I'm seeing $79 (US).
Just under $100 with shipping is what I paid a few minutes ago.

[tautech]

SP2035A reduction is from $179 to $75 and is certainly very well priced now.

I don't know if that was a typo or if they have raised the price already. I'm seeing $79 (US).
Just under $100 with shipping is what I paid a few minutes ago.

Nice.
No typo but prices are a little all over the place. 
Our NZ pricelist:
SP2035A $75
10X attenuation, 12pf, 10Mohm, 350MHz,CAT Ⅱ 300Vrms, operating temperature -10 to 55 degrees. Supports probe attenuation factor detection from oscilloscope

US website: $79
https://siglentna.com/product/sp2035a-auto-sense-350-mhz-oscilloscope-probes/

[NCG]

Has anyone used the SDS2000X Plus and Sigrok Pulseview lately? The older non-plus seems to be on the list but I was unable to connect. Are there specific aspects to know?

[Anik]

Still, there's enough of these out there now there's quite a community willing to help those that are still finding their feet. Keep asking questions and someone will help.

Absolutely!!!       

I now got it working and found the data I was looking for in an SPI signal.

However, if I acquire data over a longer period, the user interface becomes so slow, that I first thought the osciloscope had crashed.
It took me several minutes to stop the decoding and shut the osciloscope down.

Anyway, I got everything working now.
And thanks for the link to the newest manual!

Cheers,
Anik

[tautech]

Anik
Screenshots help immensely to point out possible settings errors so use the blue Print button to capture them to a USB stick and upload them here in the Attachments section when you post.

[Helix70]

Some really good news for those that have purchased SDS2104X Plus, hacked it and need/want higher BW autosense probes.

It seems Siglent does want to sell probes and at really hot pricing too on the SP2000 and 3000 10x autosense range.
https://siglentna.com/products/accessories/probes/passive-probes/

Yes I may have helped them to see the obvious.   

This is good timing! Just bought my SDS2104X Plus with an SPL2016/LA bundle, and those supplied probes aren't great. Neither are my Tek TPP0201's to be fair. Both seem to -3dB at 160 Mhz.

I only see siglent na with the cheaper price so far, and they don't seem to ship to 'straya.

[tautech]

Some really good news for those that have purchased SDS2104X Plus, hacked it and need/want higher BW autosense probes.

It seems Siglent does want to sell probes and at really hot pricing too on the SP2000 and 3000 10x autosense range.
https://siglentna.com/products/accessories/probes/passive-probes/

Yes I may have helped them to see the obvious.   

This is good timing! Just bought my SDS2104X Plus with an SPL2016/LA bundle, and those supplied probes aren't great. Neither are my Tek TPP0201's to be fair. Both seem to -3dB at 160 Mhz.

I only see siglent na with the cheaper price so far, and they don't seem to ship to 'straya.

Our early BW checks were done with BNC cable connections and IIRC the internal 50 Ohm termination so hardly surprising a passive probe connection gives a different result. PP215 probes are certainly 200 MHz capable and are also shipped with the SDS2204X Plus which is likely to have a -3dB point nearing 250 MHz.

It will take some time for fresh stock of probes at the new pricing to filter down to resellers.

[Helix70]

I tested with a random crappy 50 ohm BNC termination on a tee-piece at the end of a 50 ohm coax, so quite likely my results aren't great.

[blurpy]

Anyone know what the -3dB bandwidth is on the SP2035A? Is it just 350MHz like it says, or is it higher than specified like with the cheaper probes?

[tautech]

Anyone know what the -3dB bandwidth is on the SP2035A? Is it just 350MHz like it says, or is it higher than specified like with the cheaper probes?

Sorry I hunted but no SP2035A here. 

Surely it will be much higher than 350 MHz if these 2 are anything to go by.
Scope SDS5104X, source SSG3021X N-BNC into 50  feedthrough into BNC to probe tip adapter for a 25 Ohms source.
LF signal and cursors set to 1V, of which -3dB =~0.707V
SP2030A (300 MHz) ~590 MHz
SP3050A (500 MHz) ~900 MHz

[2N3055]

Anyone know what the -3dB bandwidth is on the SP2035A? Is it just 350MHz like it says, or is it higher than specified like with the cheaper probes?

Just a note.
Passive probes are measured with 25 Ohm source impedance. That is very low and in real life that bandwidth will rarely be reached (or shall I say, even more confusingly, that sometime it will easily, sometimes just so, and sometimes horribly no, with high internal impedance sources.)
Therefore, most important parameter of passive probe is tip capacitance. That capacitance will throw off oscillators, filters etc.
It will form first order low pass filter with any source that is not very low impedance.

Average, less than 200MHz probe, will have 14-15pf of capacitance on tip. Some even more.

SP2035A has 12pf and SP3050A is specced at 11pf. That means that in real life you will get loading similar to SP3050A ( a bit more) and will get  similar performance. Not as good, but  in test with 25 Ohm source better than 350MHz, and more importantly, similar circuit loading that is anyways much larger problem than theoretical bandwidth.

In short, SP2035A is a good match for SDS2000X+. And with newly announced pricing good buy.

SP3050A IS a nicer probe, more premium feel, real A tier product.  But not necessary for 2000X+.
You would need it for 5000 and 6000 series, to accompany higher class instrument.

[Anik]

Anik
Screenshots help immensely to point out possible settings errors so use the blue Print button to capture them to a USB stick and upload them here in the Attachments section when you post.

I've tried to reproduce the none-responsiveness of the UI, but didn't succeed yet - strange... 

But since I'd liked to try with the print button, here is another question: the decoded data doesn't appear right under the 8 bit it comes from (see screenshot), is that normal?
The data is correct obviously, but it is harder to compare to the signal here than I'm used to.

Thanks & cheers,
Anik

[DL2XY]

...
I've tried to reproduce the none-responsiveness of the UI, but didn't succeed yet - strange... 

But since I'd liked to try with the print button, here is another question: the decoded data doesn't appear right under the 8 bit it comes from (see screenshot), is that normal?
The data is correct obviously, but it is harder to compare to the signal here than I'm used to.

Thanks & cheers,
Anik

1. CS is missing (at least on screen period)
2. You are decoding a 16 bit word as two 8 bit values (what about endianess?)

greets Walter

[Anik]

1. CS is missing (at least on screen period)
2. You are decoding a 16 bit word as two 8 bit values (what about endianess?)

Hi Walter,

CS is not missing, it's just not on the screen. Nevertheless, the decoding is absolutely correct.
The complete data stream consists of single bytes (commands) and multiple bytes (data), so that's all ok.

The only small issue I have is the display of the data; sometimes it is perfectly displayed in line (on the x-axis) with the bits, and sometimes not, as shown.

Cheers,
Anik

[tautech]

Anik
Screenshots help immensely to point out possible settings errors so use the blue Print button to capture them to a USB stick and upload them here in the Attachments section when you post.

I've tried to reproduce the none-responsiveness of the UI, but didn't succeed yet - strange... 

But since I'd liked to try with the print button, here is another question: the decoded data doesn't appear right under the 8 bit it comes from (see screenshot), is that normal?
The data is correct obviously, but it is harder to compare to the signal here than I'm used to.

Thanks & cheers,
Anik

Very normal with the settings you have used.
Why a Pulse trigger instead of an Edge trigger ? Did you use any Trigger Holdoff ?

[Anik]

Very normal with the settings you have used.
Why a Pulse trigger instead of an Edge trigger ? Did you use any Trigger Holdoff ?

Hi Tautech,

no I didn't use any holdoff. And I'm using the pulse trigger in this case, because the before the signals I want to see there are many shorter pulses, which are ignored in this way.
I wouldn't mind using something else, but it works perfectly.

As I mentioned, the signals look as they should, the decoding is right, I'm only confused, why the decoded data is not aligned with the bits.
It's no drama, of course, just a little strange thing.

What setting especially made you write "Very normal with the settings you have used."?

Thanks & cheers,
Anik

[nctnico]

...
I've tried to reproduce the none-responsiveness of the UI, but didn't succeed yet - strange... 

But since I'd liked to try with the print button, here is another question: the decoded data doesn't appear right under the 8 bit it comes from (see screenshot), is that normal?
The data is correct obviously, but it is harder to compare to the signal here than I'm used to.

Thanks & cheers,
Anik

1. CS is missing (at least on screen period)
2. You are decoding a 16 bit word as two 8 bit values (what about endianess?)

It is entirely possible to send multiple 8 bit words back-to-back on SPI. So having the decoded result aligned with the actual data is very useful to have. With the screenshot Anik posted you still need to guess what is what and that kinda defeats the purpose of decoding.

[tautech]

Very normal with the settings you have used.
Why a Pulse trigger instead of an Edge trigger ? Did you use any Trigger Holdoff ?

Hi Tautech,

no I didn't use any holdoff. And I'm using the pulse trigger in this case, because the before the signals I want to see there are many shorter pulses, which are ignored in this way.
I wouldn't mind using something else, but it works perfectly.

As I mentioned, the signals look as they should, the decoding is right, I'm only confused, why the decoded data is not aligned with the bits.
It's no drama, of course, just a little strange thing.

What setting especially made you write "Very normal with the settings you have used."?

Thanks & cheers,
Anik

By what I see on the screenshot the scope is in Stop mode, that is not running and the reason why the decode is not aligned. When triggering is solid the decode should align with the bits while the scope runs.

Personally I would rather use analogue channels for what you have so to be able to use Zoom split screen mode and so the trigger point can still be seen.
If the bus is not too fast maybe you can make up some short extender wires to use the grabbers with the scopes probes.

[nctnico]

Very normal with the settings you have used.
Why a Pulse trigger instead of an Edge trigger ? Did you use any Trigger Holdoff ?

Hi Tautech,

no I didn't use any holdoff. And I'm using the pulse trigger in this case, because the before the signals I want to see there are many shorter pulses, which are ignored in this way.
I wouldn't mind using something else, but it works perfectly.

As I mentioned, the signals look as they should, the decoding is right, I'm only confused, why the decoded data is not aligned with the bits.
It's no drama, of course, just a little strange thing.

What setting especially made you write "Very normal with the settings you have used."?

Thanks & cheers,
Anik

By what I see on the screenshot the scope is in Stop mode, that is not running and the reason why the decode is not aligned. When triggering is solid the decode should align with the bits while the scope runs.

No!  The decoder software can 'see' the clock pulses and align the data with that. There is absolutely no reason for decoding to depend on a trigger! In fact, having decoding alignment depending on a trigger will mis-align the decoding in many circumstances.

[kcbrown]

By what I see on the screenshot the scope is in Stop mode, that is not running and the reason why the decode is not aligned. When triggering is solid the decode should align with the bits while the scope runs.

This doesn't make any sense to me at all.  The decoder operates on the data in the capture buffer.  Whether the buffer's contents are transitory (which is the case when the scope is running) or stable (which is the case when the scope is stopped) makes no difference whatsoever that I'm aware of.  The scope clearly knows when the trigger fired when the scope is stopped because it clearly shows that in the display.  In this case, the trigger location is off-screen.

I don't know how the decoder itself is configured here, but it appears that CS is active low and the /CS transition isn't visible on the screen, and that suggests to me that the CS configuration in the decoder is set to "CLK timeout", and that may be why the decoded portion looks misaligned.  Can't say.

Anik, what happens if you configure the decoder with a CS configuration of active low?  The decoder won't show anything unless the CS transition to active is shown on the screen, but you may get better aligned results that way.

[Martin72]

There is absolutely no reason for decoding to depend on a trigger! In fact, having decoding alignment depending on a trigger will mis-align the decoding in many circumstances.

If it´s so, for what are the special decoding trigger types good for ?

[nctnico]

There is absolutely no reason for decoding to depend on a trigger! In fact, having decoding alignment depending on a trigger will mis-align the decoding in many circumstances.

If it´s so, for what are the special decoding trigger types good for ?

That is only to provide an intelligent filter for the signal (usually in the form of a programmable pattern recognizer) to provide a trigger event. The protocol decoder is a seperate unit which does the actual protocol decoding and should provide time information (start & duration) for each piece of information that is to be displayed so the information from the decode can be aligned properly with the signal on screen. Remember that when triggering on a protocol, the trigger event occurs once the entire condition is met which could be several bytes into the packet so there is absolutely no fixed alignment in time with the trigger position and the start of the message.

[Anik]

Oh, I hadn't expected such an excited discussion on this!   

Yes, I think I had CS-time-out on. But again: the decoding is perfectly all right, so to me all boils down to only a screen/optical design issue.
The decoder had recognized the 8-bit groups just fine, evaluated them correctly, but placed the bubbles with the decoded numbers just a bit too much to the right.
--> the E7 should have been printed on the screen just 4 clock impulses to the left, where the E7 originated...

In my opinion it doesn't matter, how the signal capturing had been done, as long as the result is what I had wanted.
Only the results display isn't perfect.   

Thanks to you all, cheers,
Anik

[Martin72]

nctnico:

Interesting...

As we started to use the spi signal for "measuring" purpose, we got a rigol scope with decoding function there.
It got the trigger functions too, like the siglent.
So we tried to use this to get a stable signal - The signals were  "glitching", sometimes the scope decodes, sometimes not.
We couldn´t manage it with the spi-trigger, at the end we used pulsetrigger with defined holdoff, with more or less success.
Don´t know what we did wrong, that the "special trigger" doesn´t work as expected.
Later on, we bought some lecroy scopes with decoding functions..
They got a function called "link to trigger", when you activate it, the trigger changes to the decoding type, adjusted automatically and you get a rock stable signal/decoding also.
Much better than rigol or siglent, therefore I´d post it here some days before as a "wish":

https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3852305/#msg3852305

But to be honest, I don´t know what the lecroy "do" in this case....