Products > Test Equipment

Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

<< < (115/134) > >>

Peter_O:
Maybe it's a good compromise to leave the menu short as is. And just write the user value in the channel descriptor box instead of the probe symbol.

Anyhow - and here 2n3055 is right - it's a matter of convinience only. And in case developer's time is needed to fix real malfunction, that should be priority of course.

casterle:
> Some might complain the commonly used values will be lost in the list

Those common values could be listed above the others...on the other hand, there are more urgent issues (like all those unnecessary decimal places) that I think many would agree should take priority.

Martin72:
Hi,

Wanted Feature for the for the Platform (2k+/2k hd/5k/6k) :

Like bigger lecroy scopes, we got free chooseable channel colours - very good.
But like the lecroy got, it would be a nice to have if you can also choose different colours for printing.
Example, on screen colour for ch1 is red, ch1 printed is green and so on.
This possibility got it´s advantage when printing with white background.

Martin

RBBVNL9:
I have been encountering problems with the SDS when using its serial decode function. These problems were discussed (and partly confirmed by others) in another thread on this forum. In short:

1. The SDS does not show any error messages in its telegram or bus display when LIN protocol errors occur. This makes it very hard to see whether the shown decoded data are in fact correct or not. Unlike other scopes, there is no row in the bus display view for showing such errors either (labelled "Errors" or "State" in other scopes). 


2. In several cases, the SDS indeed shows entirely wrong decoded data (wrong ID’s, wrong message length, wrong payloads) without showing errors.
* Such situations showing entirely wrong data can be reproduced by taking a ‘good’ LIN signal and reversing its polarity (in using 'invert' the channel settings). (see screenshots below). This has been confirmed by other users. 
* Completely wrong decoded data is sometimes also shown when the polarity of the LIN signal is correct and everything otherwise seems correct (see screenshot SDS.png). Yet these situations are harder to reproduce. You don’t know in advance.3.   Using the SDS serial trigger function for errors, one can indeed observe that the scope itself is aware of all these errors it is not showing in telegram or bus display.

* But this is a very cumbersome procedure, as for each decode you have to set up an entire error trigger procedure.
* Also, when wrongly decoded messages are shown, the serial trigger function do not completely behave as expected (IDs shown on the screen are not found by the serial trigger) – probably because the messages are incorrect in the first place.
* Moreover, to trigger on LIN checksum errors, one must first know and enter the message ID and the precise content of the first two bytes of the payload. This makes it virtually impossible to carry out this serial trigger check in a full way.
As a result, it is hard to know whether the SDS is decoding properly unless you have another oscilloscope(s) next to it decoding the same signal.
 
Edited: On the basis of a quick check, the above problem (1) seems to extend to CAN, I2C, UART (partially) and possible other decoders as well (have not checked all). Problem 2 may or may not exist in other protocols, have not tested that (yet).

Edit: the above observations relate to FW 1.3.9R6, which is the most recent one as of 1 February 2022.

Screenprints in attachment:

.  RTB_wrong_polarity_LIN.PNG
   SDOX_wrong_polarity_LIN.png
   SDS_wrong_polarity_LIN.png
-> These three pictures show how other scopes show error messages and the SDS does not, all displaying the same data where a LIN signal is given the wrong polarity (so idle is low whereas it should be high)

.  PicoScope.png
   RTB.PNG
   DSOX.png
   SDS.png
-> Here, four scopes are offered the same, valid LIN signal.  Three display it properly, the SDS everywhere shows wrong message IDs, wrong message lengths and wrong payloads – yet does not show any error.

Deichgraf:

--- Quote ---1. The SDS does not show any error messages in its telegram or bus display when LIN protocol errors occur. This makes it very hard to see whether the shown decoded data are in fact correct or not. Unlike other scopes, there is no row in the bus display view for showing such errors either (labelled "Errors" or "State" in other scopes).


2. In several cases, the SDS indeed shows entirely wrong decoded data (wrong ID’s, wrong message length, wrong payloads) without showing errors.

    Such situations showing entirely wrong data can be reproduced by taking a ‘good’ LIN signal and reversing its polarity (in using 'invert' the channel settings). (see screenshots below). This has been confirmed by other users.
    Completely wrong decoded data is sometimes also shown when the polarity of the LIN signal is correct and everything otherwise seems correct (see screenshot SDS.png). Yet these situations are harder to reproduce. You don’t know in advance.

3.   Using the SDS serial trigger function for errors, one can indeed observe that the scope itself is aware of all these errors it is not showing in telegram or bus display.

    But this is a very cumbersome procedure, as for each decode you have to set up an entire error trigger procedure.
    Also, when wrongly decoded messages are shown, the serial trigger function do not completely behave as expected (IDs shown on the screen are not found by the serial trigger) – probably because the messages are incorrect in the first place.
    Moreover, to trigger on LIN checksum errors, one must first know and enter the message ID and the precise content of the first two bytes of the payload. This makes it virtually impossible to carry out this serial trigger check in a full way.


As a result, it is hard to know whether the SDS is decoding properly unless you have another oscilloscope(s) next to it decoding the same signal.
 
The above problem extends to CAN decode as well. It may extend to other serial protocol decodes as well but I have not tested this (but also there, I see no specific row in the table for errors or status so I suspect it does extend there too).

--- End quote ---

Hi RBBVNL9,

thanks for reporting and your effort to trace it down!

I'm wondering if, beside LIN and CAN error detection and decoding issues, the 1553B is also affected?
Can someone check this?

Regards

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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