Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

[Performa01]

Anyone interested in a more detailed probe comparison, I've just published one in my SDS1004X-E review thread:

https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/msg1434665/#msg1434665

[tautech]

They could have a lower input capacitance, but this could not explain the huge difference. Even the Keysight probe with only 11pF input capacitance and assuming the PP215 actually had 20pF (which I really doubt, 16pF is much more likely) could not turn 22ns into 10ns.

Little side note:
PP215 10:1 input capacitance is listed on the probe brochure and in Siglent websites as 13 or 14 pF......not 16pF

Well, then that's Siglent's fault. 

It is !

We need remember these probes are supplied by a third party and Siglent staff have made error when copying specs onto their webpage. The card in the probe pouch should always be the final and absolute reference in all cases as it comes from the probe manufacturer. I highly value the card and have them for any and all new probes I have ever bought !

But you are right: The little card that comes in the probe bag lists the input capacitance as 14pF

I've got some for PP215 that list it as 13 pF, who to believe ? 

[TheSteve]

Believe the LCR meter used to measure what the probes actually are.

[tautech]

Believe the LCR meter used to measure what the probes actually are.

At what frequency ? 

[Performa01]

We need remember these probes are supplied by a third party and Siglent staff have made error when copying specs onto their webpage. The card in the probe pouch should always be the final and absolute reference in all cases as it comes from the probe manufacturer. I highly value the card and have them for any and all new probes I have ever bought !

Well, there are obviously not so many probe manufacturers and except for Tektronix, even the big brands use third party - at least sometimes. But the probe manufacturers can make mistakes too - I don't think Siglent have reserved all possible errors in this world exclusively for themselves 

But you are right: The little card that comes in the probe bag lists the input capacitance as 14pF

I've got some for PP215 that list it as 13 pF, who to believe ? 

See? That would NOT be Siglent's fault for a change

On a more serious note, I've got one of the very first SDS1202X-E and the probe manufacturer might just have updated their specs at some point. And then, 13 or 14 pF, not a huge difference anymore, really. Up to 20 on the other hand ... would have been a bit alarming.

[TheSteve]

Believe the LCR meter used to measure what the probes actually are.

At what frequency ? 

I found my Tek and Agilent probes to measure the same up to 100 kHz(max of my LCR meter). I've measured all of my probes including active ones.

[chipss]

Pp215 probe card received today?
Input capacitance 1x85pf-120pf / 10x 18.5pf-22.5 ?
It’s what my card tells me? 

[Performa01]

Pp215 probe card received today?
Input capacitance 1x85pf-120pf / 10x 18.5pf-22.5 ?
It’s what my card tells me? 

That would be the specification for PP510 - according to the Probe Datasheet V1.5, which in turn doesn't always comply with the probe cards. 

[chipss]

The card is for a pp215, and came with the sds1202x-e , today, that is what’s printed on the card for my pp215?

[17_29bis]

Pp215 probe card received today?
Input capacitance 1x85pf-120pf / 10x 18.5pf-22.5 ?
It’s what my card tells me? 

That would be the specification for PP510 - according to the Probe Datasheet V1.5, which in turn doesn't always comply with the probe cards. 

Performa01 & tautech I don't know what kind of PP215 you have/use but this is what comes with 1204X-E:



This is comparison (PP6100). Am I the only one who sees that the declared/stated capacitance of PP6100 is even lower than PP215? 



I don't have a calibrated signal generator with knows rise/fall time, I just used a 16 MHz MCU, the output pin has a  1k  pull-up resistor.

Because otherwise we have 1k source resistance for the rising edge. You could easily prove that by looking at the falling edge – if this is much faster, than it is actually an open drain output.

Interesting assumption but the screenshots I attached for every probe clearly show that rise and fall times are the same.

[Performa01]

Okay, guys, enough guessing!

I've now measured both the PP510 and PP215 and they are pretty much identical.

Probe tip capacitance is 14.9pF for the probe alone and 15.3pF when plugged into the scope.

Of course, the probe tip capacitance depends on the compensation, as the compensation trimmer is the main capacitive coupling path to the cable (and scope input) capacitance. This is also why usually a span is specified. Consequently I've measured both probes when properly compensated for their respective scope, i.e. the PP215 on SDS1202X-E and PP510 on SDS1104X-E, as this is the only relevant use case.

[tautech]

The card is for a pp215, and came with the sds1202x-e , today, that is what’s printed on the card for my pp215?

Very interesting, thanks for your reply.

I have bought probe quality concerns to Siglent's attention before and I will again for your PP215 !
The SDS1004X-E product manager informed me that he would keep an eye on their suppliers product.

Email sent.

Performa01 & tautech I don't know what kind of PP215 you have/use but this is what comes with 1204X-E:

PP215 is also supplied as the standard probe for 200 MHz SDS1202X-E.

If there are discrepancies with this product they must be addressed. Maybe it is only the documentation ? 

[Performa01]

Performa01 & tautech I don't know what kind of PP215 you have/use but this is what comes with 1204X-E:

Well, of course I can only speak for what I have. The PP215 is about a year old and the PP510 about 6 months and both perform very similar and have the exact same probe tip capacitance.

See attachments for the PP215 (sorry for the poor image quality).

Interesting assumption but the screenshots I attached for every probe clearly show that rise and fall times are the same.

Sorry, I just forgot that – I’m doing so many things in parallel. Somehow I thought I had seen a screenshot zoomed on the rising edge and didn’t look back in the thread.

Anyway, we don’t seem to get any plausible answer to the question why your PP215 performance appears to be so poor. I’m rather confident the PP215 that I have would not go under so badly in a comparison against the other probes you’ve used. But obviously something is different at your side.

I guess we can only wait and see what tautech finds out. Maybe Siglent could test a sample of their currently shipped PP215 probes and verify their performance.

[17_29bis]

See attachments for the PP215 (sorry for the poor image quality).

I have already seen it and even compared with PP610, see my post above with 2 attached screenshots.
EDIT: and what is really funny is that your and my scans don't match.

[chipss]

My probe and card is a exact match to 17-29,bis same probe yet different specs? confusing. My cap tester is not all that great. But I may take a look at it anyway.
 I must say for an economy class scope , what would this have costed 20 years ago!

  it shall work fine for my needs, plus a few options That are overkill, mainly setting bias in mics, and mic pre amps, compressors, and eq’s.

[tautech]

I guess we can only wait and see what tautech finds out. Maybe Siglent could test a sample of their currently shipped PP215 probes and verify their performance.

Yes, maybe this what they'll do.

Initial reply from the product manager is they will look into this and update documentation if required.
He offers thanks for bringing this to their attention.

[17_29bis]

I found a bug related to displaying long IC2 decoded packets, I am running the latest X.20 firmware.
Look at the first column in the table, we cannot see the row 9:




But if I change the number of lines in the table then we see the row 9 just fine:

[TK]

Is it missing row 11 as well on picture #2?

[17_29bis]

Is it missing row 11 as well on picture #2?

This is not a missing row, this is just data corruption shown in the table.

I would like to report on the recently found problems/bugs:

1) Table corruption. This is how that can be reproduced (X.20 lastest firmware, I2C 7 bit address is used) :

a) program the i2C master to send 54 byte long payload - check the result (everything is fine):






b) program the i2C master to send 55 byte long payload - check the result (the record index has been replaced by some data):







c) program the i2C master to send 70 byte long payload - check the result (the first 3 columns in the table were overwritten by the previously decoded data):





2) I also noticed that sometimes the last saved screenshot is not saved on the USB drive. it might be a result of some caching and I am not sure how to handle properly  safe removal of USB drive since looks like 1204X-E does not provide any options for that.

3) And finally: looks like Siglent does not provide a way to inspect data payload longer than 0x15 bytes. The max number of bytes displayed in the single row of the table is 0x10 and there is no horizontal scrolling. The max number of decoded bytes shown at the bottom of the screen about ox16 without a possibility to properly scroll it. Before someone suggests to use horizontal position/scale knob he has to try  it first since it does not work. That, seemingly minor thing, upsets me the most since it might be a design flaw and therefore cannot be easily fixed without major changes.

I would appreciate if one of Siglent distributors reported these bugs to Siglent.

[tautech]

I would like to report on the recently found problems/bugs:
 
2) I also noticed that sometimes the last saved screenshot is not saved on the USB drive. it might be a result of some caching and I am not sure how to handle properly  safe removal of USB drive since looks like 1204X-E does not provide any options for that.

There has never been provision for USB 'safe removal' in Siglent equipment. Instead a saving bar graph indicator lets you see progress of the Save. A USB stick with a read/write LED can be useful to let you see the drive is not working.

3) And finally: looks like Siglent does not provide a way to inspect data payload longer than 0x15 bytes. The max number of bytes displayed in the single row of the table is 0x10 and there is no horizontal scrolling. The max number of decoded bytes shown at the bottom of the screen about ox16 without a possibility to properly scroll it. Before someone suggests to use horizontal position/scale knob he has to try  it first since it does not work. That, seemingly minor thing, upsets me the most since it might be a design flaw and therefore cannot be easily fixed without major changes.

I would appreciate if one of Siglent distributors reported these bugs to Siglent.

Noted, thanks.

[tautech]

Simple Bode plot exercise/example.

1 KHz to 30 KHz passive band pass filter.
Components breadboarded from parts on hand.
Based entirely on the circuit example from here:
https://www.electronics-tutorials.ws/filter/filter_4.html





Should give us something like this:




SDS1104X-E
Sweep source SAG1021 optional AWG module
Connection HW; BNC cable and Tee, 2x BNC to croc clip leads (DUT IN, DUT OUT)

Sweep = 100 Hz - 100 KHz, 4V p-p, Low res

[rigol52]

Nice demo tautech, thanks.

Are visual differences between each curve possible in color too, or in trace light intensity only?

Curious how much more cable mess are added to desktop measurement procedure by deciding
to external (USB connected) SAG1021 instead to build in one? Personally prefer build-in one or
standalone AWG. One more reason to invest in SDG1062X (or SDG1032X) before SAG1021.

[tautech]

Nice demo tautech, thanks.

You're welcome and it's been on my mind to do it for some time.
Actually I might go back and do the same one again, this time with a plot of the first stage of the pass band.
Have to get my head around what I'm trying to show first.   
3 plotted stages are allowed with the 4 inputs.

Are visual differences between each curve possible in color too, or in trace light intensity only?

Trace colors are the same as the channel colors but you can only select from three as one is reserved for the reference signal input. There is no restriction on the channel you select for ref or DUT output (Bode plot input).
The fainter trace is phase shift and referenced from the RH graph axis.
I've cranked trace and graticule brightness to max for this screenshot to help with visibility.

Curious how much more cable mess are added to desktop measurement procedure by deciding
to external (USB connected) SAG1021 instead to build in one?

Little, in fact only the mains supply cable for a standalone AWG and that'll be behind a unit anyway.
You still need to tether it by USB when in Bode plot mode for the scope to take charge of it. But that can be done behind both units as 1004X-E's have a rear USB-A just for this purpose. Standalone's have USB-B on the rear but both these scopes and SDG's come supplied each with a A-B USB cable.
So effectively if using a Siglent standalone and all rear cabling there is one less cable on the bench than with SAG1021.

Personally prefer build-in one or standalone AWG. One more reason to invest in SDG1062X (or SDG1032X) before SAG1021.

Understood, but at least buyers can have a # of options depending on their needs.
The cheapest is to just get SAG1021 IF Bode plot functionality is all you need, then for a bit more the AWG license for it to give full (but somewhat limited) AWG capability.
Then of course any of the 2ch Siglent AWG's would be the best choice to get something that will do Bode plot and not be so easily outgrown.

[tautech]

Hi,
I've updated my SDS1104X-E with the new firmware but now I notice something strange on channel 4.
I can't see any signal with 50V/div, 5V/div, 1V/div, 200 mv/div (probe set to x10, with x1 the values are 5V, 500mV, 100mV, 20mV). To be more precise I can see the signal only for an instant after changing the V/div scale and then it disappears.
I never noticed this with the previous fimware so I think that is a firmware problem.

can someone check this? or can I try something to figure out what is going on?

Thanks

Now that the factory is back at work after Chinese new year hols and after checking they were aware of issues with v7.6.1.20, they've replied that they're trying to get a replacement firmware version out this later week.

I found a bug related to displaying long IC2 decoded packets, I am running the latest X.20 firmware.
Look at the first column in the table, we cannot see the row 9:
.............

If they can fit it in they'll try and address this too but their immediate focus is to fix the problem in v7.6.1.20

Thanks guys.

[firstcolle]

Now that the factory is back at work after Chinese new year hols and after checking they were aware of issues with v7.6.1.20, they've replied that they're trying to get a replacement firmware version out this later week.

thanks!