Products > Test Equipment

Siglent SDS2000X Plus

<< < (630/689) > >>

KungFuJosh:

--- Quote from: bdunham7 on January 06, 2022, 05:52:20 am ---
--- Quote from: Fiorenzo on January 06, 2022, 05:32:37 am ---Another maybe silly question: I thought that the scope was automatically capable to reconize if the probes are set to 10x or a 100x but It doesn't do It.
Is due to cheap probes they gave in bundle?

--- End quote ---

Well, yes, but I've never seen 1X/10X switchable probes that had that sensor feature.  It would be tricky to implement automatically and there's not much point to making it a manual selection.  Higher end fixed ratio probes may have readout pins, but not 1X/10X.

--- End quote ---


Lots of 1X/10X probes have that feature. I have a few probes from probemaster.com that have 1X/R/10X switching and the readout pin. Mine are from the 4900 series that I use with the SDS2KP. You can flip the switch on the probe and the scope detects the change.

Thanks,
Josh

bdunham7:

--- Quote from: KungFuJosh on January 29, 2022, 03:35:31 am ---Lots of 1X/10X probes have that feature. I have a few probes from probemaster.com that have 1X/R/10X switching and the readout pin. Mine are from the 4900 series that I use with the SDS2KP. You can flip the switch on the probe and the scope detects the change.

Thanks,
Josh

--- End quote ---

+1 for Probemaster.  I have some 4900 series probes, but didn't know they had switchable and readout in the same unit.  I'm not sure how they do that--what does the probe cable look like?

RBBVNL9:
@2N3055,


--- Quote ---Could you please elaborate more on this?
--- End quote ---

Firstly, several scope makers (R&S, Picoscope, haven’t checked others) offer a polarity setting for LIN serial decoders. So they think this makes sense, that there are uses case in which this is useful.


--- Quote ---LIN signal is active LOW. That is standard. It means it sits at positive voltage on idle and gets pulled down to ground when active (logical 1).
--- End quote ---

Yes, that is also my understanding. Unfortunately, since the LIN standard is maintained by ISO you need to pay to get access to that documentation. In the ST LIN chip documentation I read: “Two logical levels are defined on the LIN bus physical line – the recessive level and the dominant level. The recessive logical level corresponds to a high voltage level on the LIN bus line (measured against the ground potential, nominal value = 12 V). The dominant logical level corresponds to a low voltage level on the LIN bus line (nominal value = 0 V). The dominant logical level has higher priority. This means that when at least one node in the LIN cluster sends the dominant level, the resulting level on the LIN bus line is the dominant level.” In short, we seem to be in agreement.

I do reckon that the terminology used on devices, in manuals and in discussions regarding LIN polarity is somewhat confusing. Some talk of ‘Idle High” or “Idle Low”, some talk of high or low “signals”, some talk of ‘negative going LIN’.  I also read somewhere “The idle state is the recessive state and corresponds to a logic 1.” (so this source uses another definition of what logic 1 is). Also the fact that a packet starts with a relatively long break period that is opposite to the idle signal may confuse people. Sometimes I started to feel confused too. Hope I made no mistakes but will get to that.


--- Quote ---How on earth did you achieve polarity on SDS2000X+ to be wrong in a first place? All these scopes have common ground, how did you connect it the wrong way?
--- End quote ---

Two answers.

First, how did I make the signal? As I described in the previous mail, I took a Keysight DSOX1204G, powered it up, and activated the LIN training signal ;-)

Second, you seem to assume that the signal I sent into the SDS was wrong. But if you look at the screenprints in my original mail, you see that all the scope signals, including that on the SDS, are exactly like the correct LIN bus you describe above. Still, the SDS decoded bus was wrong.

I want to dig a bit deeper into what the different scopes expect as ‘default’, and, relatedly, when polarity may need to be changed. Perhaps in the testing and confusion, I made an error there. If I find some time this weekend, I will test with a much easier LIN signal (one that simply sends the same packets every time, so see always the same message on every device).


--- Quote ---I did check now and Siglent does seem to get confused (same as I am by negative going LIN signal, I guess :-). But that is a fringe case.
--- End quote ---

Seems that we then agree on my main conclusion: if the signal polarity is wrong (for whatever reason that might be), the SDS can show LIN messages as if they were correctly decoded, even if they are actually incorrect. 

blurpy:

--- Quote from: RBBVNL9 on January 28, 2022, 08:46:04 pm ---Well, the RTB, DSOX or PicoScope simply show no decoded signal when the polarity setting is wrong and decode is impossible. BUT THE SDS SHOWS A COMPLETELY WRONG DECODED SIGNAL WHEN POLARITY IS WRONG AND SHOWS IT AS IF IT’S A GOOD SIGNAL WITH NO ERRORS!

Once you are aware polarity is wrong (by instance by noticing different results on three other devices ;-), you change channel polarity, re-do the threshold, and it works properly. Now I figured that out, I am able to decode all my busses correctly. But the SDS behaviour is troublesome. When the user thinks a proper signal is decoded, it may be actually totally wrong. I consider this to be a bug. If someone wants to report to Siglent, be my guest...

--- End quote ---
I think it would be nice to see the interpreted data, but highlight (in red?) that the checksum is wrong.

There is a bug thread here where you can post your findings: https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/

RBBVNL9:

--- Quote ---I think it would be nice to see the interpreted data, but highlight (in red?) that the checksum is wrong.
--- End quote ---

Agree. As long as the decoder would show there is an error, then the user would be aware that the shown decoded info may not be trustable.

But as far as I can see now, if the decoder goes wrong (because of wrong polarity, whatever the reason of that is), no error is shown in the telegram screen nor in the table view. No header parity error, synchronisation/sync byte error, CRC checksum error... It is just displayed as if it were a good message.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version