Siglent SDS3000X HD and upgraded SDS1000X HD

[2N3055]

AFAIK, SDS7000A does but SDS3000xHD does not support USB decoding at this time...

240Mhz is recovered clock frequency and pulses are square wave so in order to be able to see at least 5th harmonic (so signal at least resembles something at least similar to square), 1.2 GHz BW would be needed.

Ah that's a shame - but yeah what you say makes sense...

I was trying to find where on earth I got the idea it did USB 2.0 decoding and it seems there is a PDF on the Siglent (EU) website here that, on page 25, shows a comparison of their various 12-bit scopes. The USB 2.0 decode option is clearly noted in both the SDS3000X-HD & the SDS7000A...

However checking the manuals it definitely seems only the 7000A has anything written here...

I'm wondering is @tautech may know more? I will send an email to Siglent EU anyhow... It reminds me of looking at the SHA850A spectrum analyser recently where they added some EMI features after and the manual still has no mention of them...

Anyway, ramble aside, I'll remain an optimistic fool and will report back if they give me a clear answer!

I personally can not confirm nor deny if that is in the cards or not. I simply do not have that information.
I know it does not have it now as we speak, and same for SDS6000A that is model up the chain.
6000A has 2GHz BW and it definitely should be able to sample fast enough. But there are other considerations so BW is not only choice maker.
And, in reference to your SA story, I am not quoting datasheet, I looked into scopes on their last FW.

[2N3055]

]AFAIK, SDS7000A does but SDS3000xHD does not support USB decoding at this time...
240Mhz is recovered clock frequency and pulses are square wave so in order to be able to see at least 5th harmonic (so signal at least resembles something at least similar to square), 1.2 GHz BW would be needed.

Could just work...
That's why I was surprised in the Magnova thread that it was said there that the USB protocol would be added later... at a maximum of 350Mhz bandwidth, that's a pretty ambitious thought, or they meant USB1.0.
That would also be possible for the 3000.

Like I said, 1GHz version of 3000xHD could marginally have enough BW to be able to decode but there are other considerations in addition to just BW alone. The future will show.

For Magnova, they meant USB 1.0 (Low speed & Full speed) probably.
My 1GHz Keysight MSOX3104T supports only USB PD.   

[Martin72]

I also think that this is more of a nice-to-have, there are other more interesting things for me that I would like to see in 3000X.

[Dennis Frie]

I guess USB 2.0 decoding should work just fine, as long as you have a bandwidth around 240MHz (or better). Sure, you will not be able to validate signal integrity, but that's a completely different thing.
However, I've not seen any USB 2.0 decoding options for the SDS3000, guess they will keep that for the "pro" models.

[seajayshore]

Anyway, ramble aside, I'll remain an optimistic fool and will report back if they give me a clear answer!

Already got a reply from the Siglent EU person I've dealt with before!

And the winner is...........KungFuJosh

Exact reply from Siglent:
"It’s a copy paste error."

So R.I.P. this little feature - but at-least now we know!

[2N3055]

I guess USB 2.0 decoding should work just fine, as long as you have a bandwidth around 240MHz (or better). Sure, you will not be able to validate signal integrity, but that's a completely different thing.
However, I've not seen any USB 2.0 decoding options for the SDS3000, guess they will keep that for the "pro" models.

That is absolutely not enough BW for reliable decoding and triggering. This is not 240MHz sinewave.

Here are the scopes that have cca 270MHz, 370MHz, 650MHZ and slightly more than 1GHz BW:

With low bandwidth, eye starts to close vertically because of slow edges. Also, if BW is insufficient, DC bias starts to wonder, because not all PRBS combinations are DC balanced (exact point in testing with PRBS).

Looking at these results, I would say that in order to start decoding with any reliability, 500 MHz+ BW would be some start figure..
You could decode with less, but reliability might suffer. And even miniscule problems with probing and bus load will create all kinds of problems.

These are with PRBS signal that has edges risetime set at 1ns.

If we set signal to have 500ps risetime (with USB2.0 High speed you might have edges with 300ps risetimes), then 2000xHD starts getting confused with risetime being detected from 300ps to 4.7ns, very wide spread....
It is obvious is struggles, even with 650MHz BW.
But decoder might still work with this...

So I would say it is plausible that 500-600MHz scope might be able to decode USB2.0 High speed type of signal.
With caveat that this is with signal gen directly connected to scope with coax, X1 probe ratio. Spherical cow in vacuum scenario.
Any decrease in BW related to probing before scope input will contribute to decreased system BW and add noise.

For reliable signal integrity, you need 2-4GHz (110-250 ps risetime) scope because of cca 300ps edges in USB 2.0 High Speed. And matching active diff probe...

But thing is that USB is very busy protocol. Decoding it in scope would be very cumbersome. Scope is more useful here for exactly SI check and those lower BW scopes cannot do it right.  And decoding and triggering on the scope in this context is more meant for to be able to troubleshoot across electrical and software/protocol domains. Trying to figure out why specific message has problems and double checking it is not SI stuff. Or the other way around, seeing SI problem and figuring out where it will manifest itself..

But troubleshooting and debugging complex software by using scope to decode 10s of thousands USB datagrams  is not very efficient.

So manufacturers don't really press for decoding if scope can not also do proper SI...

[pasha]

Hi, I saved the sds3034x hd screen in csv format, then I recalled the saved file and it gave me the message "illegal file format".
I can open the saved csv file on the web page.
It can't load this format?
Can you save your own screen and try? Thanks.

[tautech]

Hi, I saved the sds3034x hd screen in csv format, then I recalled the saved file and it gave me the message "illegal file format".
I can open the saved csv file on the web page.
It can't load this format?

No not supported.

Can you save your own screen and try? Thanks.

Save as Ref file which can be recalled.

Edit to add
SigScopeLab Signal Analysis Software might do what your require....haven't had a real play with it. 
https://www.siglenteu.com/service-and-support/firmware-software/pc-software/#sigscopelab

[pasha]

I tried with SigScopeLab, it still gives the same message

[tautech]

I tried with SigScopeLab, it still gives the same message

Please share in detail your full requirements for a saved/captured CSV file.

[pasha]

The file size is 60MB, uploading it here may be tiring, but you can save any screenshot in csv format and try it, there is no special situation.

[tautech]

The file size is 60MB, uploading it here may be tiring, but you can save any screenshot in csv format and try it, there is no special situation.

BIN files can also be saved and have the advantage of being much smaller than CSV.

In the Save/Recall menu and in the webserver there is a BIN to CSV convertor app for install to PC for doing these conversions.

Neither BIN or CSV can be uploaded/opened with the scope as they are intended for post capture PC analysis.

[pasha]

I used Tektronix MDO4000 for a long time, you can use it by both saving and restoring.

[2N3055]

I used Tektronix MDO4000 for a long time, you can use it by both saving and restoring.

You are trying to load capture back in scope?
Why? What do you want to do with ?

[tautech]

I used Tektronix MDO4000 for a long time, you can use it by both saving and restoring.

Reference files perform this without being of excessive size for this need.

Locally you can store IIRC 10 to the DSO memory and as many as you like remotely or to USB should you need multiple reference waveforms for comparison tasks.

Utility>Save/Recall is where you can select to save or recall a Ref waveform.

[2N3055]

I used Tektronix MDO4000 for a long time, you can use it by both saving and restoring.

Reference files perform this without being of excessive size for this need.

Locally you can store IIRC 10 to the DSO memory and as many as you like remotely or to USB should you need multiple reference waveforms for comparison tasks.

Utility>Save/Recall is where you can select to save or recall a Ref waveform.

Reference is fine but exactly because it is not original data, it is limited what you can do with it. It has it's use and merits but original data it is not.

And yes, on 3000xHD you can save full waveform data to USB and load it back to scope.
That is why I want explanation what @pasha wants to do with it and how he would use it.
So I can give explanation how to achieve that.

But only binary files are supported. CSV is not because it is large and inefficient. CSV is there to support easy export of data and loading to some software that universally will support CVS.

So short answer is, yes you can load full scope captures back to scope, but only BIN is supported (that is also better way because it is much smaller and faster to load).
Also loaded captures do not get loaded into acquisition channel (CH1 for instance). Those are exclusively dedicated acquisition channels, hardware ones. You load data to Memory channels, and use it from there.
Memory channels are similar in appearance to Ref channels, but they contain full data from capture.
You can copy from live channel or load from disk.

In use Memory channel can be used same as live channel. In math, measurements, decode.....

[pasha]

@2N3055
I will transfer the data to the PC and apply various filters.
I want to navigate through this data and make visual analysis with an oscilloscope without needing a PC. As you said, the csv format is universal.
Is the restored data original (for .bin format)?

[2N3055]

@2N3055

Is the restored data original (for .bin format)?

Thank you for the answer.

Yes if you save BIN, and load it back to Memory channel, it is full original data.

BIN data is documented. You can load it on PC too if you are making your own program

[pasha]

I have a PC program that I created by reading the CSV format line by line. I have no idea how to read bin format on PC. You can recommend the csv format for this, but this time it creates a mess of two different reference files.
anyway, I will find a way.
thanks for all.

[tautech]

I have a PC program that I created by reading the CSV format line by line. I have no idea how to read bin format on PC. You can recommend the csv format for this, but this time it creates a mess of two different reference files.
anyway, I will find a way.
thanks for all.

Because you missed this or it didn't sink in:

The file size is 60MB, uploading it here may be tiring, but you can save any screenshot in csv format and try it, there is no special situation.

BIN files can also be saved and have the advantage of being much smaller than CSV.

In the Save/Recall menu and in the webserver there is a BIN to CSV convertor app for install to PC for doing these conversions.

[egonotto]

Hello,

is it possible that the Siglent SDS3000X HD only zooms at 500 uV/div?

The images of the noise at 500 uV/div, 1 mV/div, 2 mV/div and 5 mV/div make me suspect this. The counts-peak-peak are very similar at 500 uV/div and 1 mV/div.

Best regards
egonotto

[Lexy]

Hi,

I have a SDS3034X HD with the latest firmware (V1.0.3.9). I was doing some I2C decoding of a OLED display (SSD1306) and noticed that the address was decoded as 0x78, but the address is actually 0x3C:



The trigger is set to trigger on address 0x3C and it does trigger on this, so the trigger system uses the correct number:



When we look at the binary format, we see that there actually is 8 bits in the address, instead of 7 (+R/W bit):



As a reminder of how the address is formatted in I2C:



So the SDS3034X HD inadvertedly takes the complete first 8 bits as address, instead of the first 7!


I've done the same test on a SDS802X HD and here the decoding is correct:



PS.: Is there any way to notify Siglent of this bug? Or can the Siglent people that also read this forum handle it further?

[Martin72]

Hi,

When we look at the binary format, we see that there actually is 8 bits in the address, instead of 7 (+R/W bit):

Configuration
There is only one item  Include R/W Bit  in the configuration of the I2C decode. When it is disabled,
the address is represented separately from the R/W bit, and when it is enabled, the R/W bit is
represented together with the address.
For example, the address 0x4E: Write: Ack, is displayed as "0x4E (W)" when the R/W bit is not
included and is displayed as "0x9C" when the R/W bit is included

Take a look...

[Lexy]

 , I should had RTFM... Thank Martin for clearing this up

I probably turned the 'Include R/W bit' setting on while messing around with the decoder to see what the possibilities where.