Author Topic: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests  (Read 144195 times)

0 Members and 2 Guests are viewing this topic.

Offline Deichgraf

  • Contributor
  • Posts: 18
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #550 on: October 28, 2021, 08:26:08 pm »
Bug report: when the scope is under significant load, it is largely unresponsive to the front panel controls, particularly the timebase and/or vertical sensitivity controls. 

To reproduce this, feed a 1 MHz signal into the scope on one channel.  Turn off all other channels.  Configure acquisition for a 200M buffer, and the trigger for rising edge and normal mode.  Set your timebase to 10 ms/div (so that the entire buffer is used -- these settings will result in a screen time coverage of 100ms).  Then enable zoom mode.

Now play with the timebase and vertical sensitivity controls on the front panel.  Notice how it will fail to recognize some of the movement of the controls when you move them even moderately quickly.

This is with the latest firmware (1.3.9R6), but seems to be the case with earlier firmware versions as well.

Hi kcbrown,

I checked the "CPU load" with your input/test setup, but this seems to be not a problem of CPU load ...

But the response on the controls is somehow linked to the screen update/buffer acquisition rate.
I have the impression, that the event input buffer is limited to the first or last event in the queue in this "slow" acquisition scenario or in general to avoid "unwanted overshot" w.r.t. changing the scope settings!?

We can see much more "CPU load" for active FFT and/or Measuring tasks ... see attached pictures.
 
The following users thanked this post: Martin72

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: us
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #551 on: October 28, 2021, 09:55:43 pm »
Hi kcbrown,

I checked the "CPU load" with your input/test setup, but this seems to be not a problem of CPU load ...

I didn't expect it would be.  CPUs are generally really fast, and human perception is glacial in comparison.  Your CPU could be 99.99% loaded and you'd never notice it in the UI.  Try running something that burns 100% CPU on all of the cores on your computer and you'll see what I mean: the computer remains perfectly responsive.

The "load" I had in mind was more with respect to resource contention (such as access to a memory buffer that's continuously being written to and which requires locking to prevent race conditions).  That is something that will slow down a UI.


Quote
But the response on the controls is somehow linked to the screen update/buffer acquisition rate.
I have the impression, that the event input buffer is limited to the first or last event in the queue in this "slow" acquisition scenario or in general to avoid "unwanted overshot" w.r.t. changing the scope settings!?

That seems like a reasonable assessment.  It should be noted that even with a faster update rate, the scope still misses events from the front panel from time to time (certainly more often than it should -- it shouldn't miss any).

Quote
We can see much more "CPU load" for active FFT and/or Measuring tasks ... see attached pictures.

Yeah, that's not a surprise.  I think you'll find that the CPU load can be high while the responsiveness to the front panel remains somewhat better than under the conditions I outlined.


Frankly, if you're playing with the controls like this, the scope should, if acquisition is what's interfering with UI responsiveness, stop acquisition immediately, and restart it a short period of time after the user stops moving the controls.  This is so because if you're playing with the timebase, vertical sensitivity, etc., the scope is going to throw away the current acquisition anyway, and will keep doing so until you stop moving the controls.  Meanwhile, with acquisition stopped, the scope can direct all of its attention to the controls and the display updates that result from their manipulation, and the end result will be a UI that is ultra-responsive.  But again, it should do so only if acquisition is interfering with UI responsiveness in the first place, something that I think may be true only to a limited degree.

How do I know?  Well, try setting up the scope as described, let it do its acquisition, and then stop the scope.  Then play with the controls.  You'll find that the responsiveness isn't much better than it was with the scope running.  But obviously it should be far better, because there's nothing that the scope is doing at that point except interacting with the user.
« Last Edit: October 29, 2021, 01:05:08 am by kcbrown »
 

Offline Frex

  • Regular Contributor
  • *
  • Posts: 116
  • Country: fr
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #552 on: November 01, 2021, 09:08:28 am »
Good afternoon gentlemen,
I didn't expect my comment to lead into a philosophical discussion.  :-)

Sure your points of concern are legitmate as an engineer's general attitude.
In this specific case, I'm having sufficently deep insight:
The discussion SMB1 compatibility vs. security has been lead time ago and the reason why current implementations should refrain from using SMB1 are convincing.
However, here it is not about disabling CIFS/SMB1-support, but enabling higher versioned dialects for those that support or rely on it (e.g. any recent  (>=1803) std. WIN10 box uninstalls SMB1-support silently, if no SMB1 traffic is detected within 14d). NT LM 0.12 & POSIX2 aka CIFS will still be available in my shell-example shown above.

This instrument currently builds upon Linux kernel 3.19.0, thus it defaults to "negotiate up to SMB1.0"-behaviour unless you allow it to offer higher versioned dialects.
From a developer's point of view and under the given situation it is all about one single additional const char* option-flag, regardless of the implementation method chosen (Linux API, shell-call).
@2N3055: Linux Programmer's Manual: MOUNT(2).
This fact was the reason for my laconic comment.

Sure, you still won't satisfy all possible client/server combinations out there, but you cover the most common combinations at the time being.
Imho, it is not desirable to limit a contempory network-client to a deprecated protocol-revision.
 
I greatly honour Siglent's effort to add features after product-release, especially as the decision to add a SMB-client to a rolled out emb. device is something many manufacturers would consider to be possibly painful and thus refrain from doing it. I clearly prefer Siglent's approach.

Just my two cts.
++umgfoin.
Hello,

As probably many others, I would like also to try using network folder with the oscilloscope.
Anyway, I must admit that network configuration is obscure for me and despite some effort
I don't have been able to do it working. :-\
Note that the scope is not directly connected to the network, but it use a LAN cable between it and a win10 computer.
This computer is itself connected to the network using WiFi.
With such configuratuin and as I understand, This is my computer that need to host the SMB server, to allow to be seen by the scope to create a
network folder where the scope will write data.

Does anybody could explain how to proceed step by step ?
Thank in advance.
Regards.

Frex
 

Offline Deichgraf

  • Contributor
  • Posts: 18
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #553 on: November 01, 2021, 02:38:49 pm »
Hi Frex,

the Ethernet cable between the scope and the Win10 computer is a good starting point ... a connection to the (internet) router/gateway (network as you wrote?), is not necessary for the scope.
To enable the communication between scope and computer, both have to be in the same logical (sub-)network in your lan ... same IP-Address range.

Example:  Win10-IP: 192.168.1.x   /  Scope-IP: 192.168.1.y    with x, y in (1..255) and x !=y

So power-up your scope and the Win10 computer and let's check your IP-configuration on the Win10 machine:

1) Open a command shell (cmd) and enter:  ipconfig
2) As a result, you will get a list of the installed network interfaces and their IP configuration
3) Depending on this list and the configuration of the interfaces, we can proceed with the next step(s) ...

Regards
 

Offline Frex

  • Regular Contributor
  • *
  • Posts: 116
  • Country: fr
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #554 on: November 01, 2021, 05:58:36 pm »
Hello Deichgraf,

Thanks for your quick answer.
(Just note that I already have configured the network on the scope to be able to have access to it with web browser).

I have used the ipconfig command with success.
The computer IP of Ethernet link is 169.254.xxx.xxx // 255.255.0.0
The scope IP use same 169.254.xxx.xxx range.
Then, the Wifi network interface (USB dongle) use IP that use 192.168.x.xx // 255.255.255.0  address.
It is as expected ?
Thank you.

Frex
 

Offline Deichgraf

  • Contributor
  • Posts: 18
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #555 on: November 01, 2021, 07:25:10 pm »
Good evening Frex,

this looks quite good ... I was not sure whether you had IPV4 or IPV6 on your computer enabled.

So final steps - make sure that you note the scope and computer IP's, e.g. 169.254.1.1 (Win10) and 169.254.1.2 (Scope).

1) With the explorer create a folder at a convienent place ... but for simplicity in this test chose e.g.: C:\Temp\Frex
2) Open properties of folder Frex and select Share-Tab -> Extended shares -> select check box Share this folder and
3) Click on permissions -> give all permissions to Everyone (Full control, write, read) access
4) Apply all dialogs with ok

Now this folder should be writeable from the scope point of view!

5) On your scope, click Utility -> System settings -> I/O -> Net Storage
6) In this dialog, you enter your Win10 computer IP and Frex shared folder, your Win10 username and password
    -> see attachment example and the special hack (thx to umgfoin) with ,vers=3.0 after the username!!!
7) Click connect ... now the scope should have mounted your Win10 shared folder
    => press Print on the scope and the file should be stored over the network on your Win10 computer/Frex folder.

Have fun,
Deichgraf
 
The following users thanked this post: 2N3055, Peter_O, wmattias

Offline Frex

  • Regular Contributor
  • *
  • Posts: 116
  • Country: fr
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #556 on: November 02, 2021, 05:05:57 pm »
Hello Deichgraf,

Thank you very much for your write up.
 It was very clear and it work now.
 Your help was much appreciated !
Best regards and thank again.
 :-+

Frex
 
The following users thanked this post: 2N3055, Deichgraf

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: us
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #557 on: November 13, 2021, 11:00:06 pm »
Bug report:

As I noted before, there are certain conditions under which the scope will improperly clear the history buffer.  Siglent has addressed at least some of that, so kudos to them for it.

At least one specific condition remains, and really shouldn't: single-shot capture mode.

Right now, if you use that, it clears the history buffer.  But it obviously should do so only if the capture settings have changed.  If they remain the same then there is no harm at all in adding the new capture to the history, thus making it possible to review multiple sequential single-shot captures via the history.

I regard this as a bug because I can see no good reason whatsoever for clearing the history buffer just because you're capturing a single manually-triggered event rather than an automatic sequence of triggered events.
 
The following users thanked this post: nctnico, zerto, blurpy

Offline Peter_O

  • Frequent Contributor
  • **
  • Posts: 414
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #558 on: January 05, 2022, 11:37:58 am »
Just bought a nice micsig DP20003 probe for motor switch snubber design.
It's 200x and 2000x.
NP to edit the Probe setting. The V/div display works fine too.

BUT: There is only a strange line for the damping probe attenuation factor in the channel descriptor box instead of "200x" or "2000x". Testwise it's the same e.g. for "99x".

Same on device screen and remote instrument control on PC.

« Last Edit: January 05, 2022, 12:16:42 pm by Peter_O »
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6446
  • Country: hr
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #559 on: January 05, 2022, 12:03:12 pm »
Just bought a nice micsig DP20003 probe for motor switch snubber design.
It's 200x and 2000x.
NP to edit the Probe setting. The V/div display works fine too.

BUT: There is only a strange line for the damping factor in the channel descriptor box instead of "200x" or "2000x". Testwise it's the same e.g. for "99x".

Same on device screen and remote instrument control on PC.


That is not attenuation factor ("damping" as you say).. That is actual V/div scale for the channel. When you change vertical it should change to current efective V/div including probe atten factor.
 

Offline Peter_O

  • Frequent Contributor
  • **
  • Posts: 414
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #560 on: January 05, 2022, 12:31:35 pm »
That is not attenuation factor ("damping" as you say)..
OK. What's meant schould be clear from the picture.

As for the wording I checked with the Siglent User manual and changed "damping factor" into "probe attenuation factor" in my post above. That's the wording Siglent is using. And that's what I do mean.

To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.

Quote
That is actual V/div scale for the channel. When you change vertical it should change to current efective V/div including probe atten factor.
As I wrote: V/div display is fine.
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6446
  • Country: hr
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #561 on: January 05, 2022, 01:00:15 pm »
That is not attenuation factor ("damping" as you say)..
OK. What's meant schould be clear from the picture.

As for the wording I checked with the Siglent User manual and changed "damping factor" into "probe attenuation factor" in my post above. That's the wording Siglent is using. And that's what I do mean.

To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.

Quote
That is actual V/div scale for the channel. When you change vertical it should change to current efective V/div including probe atten factor.
As I wrote: V/div display is fine.

Down in channel box there is never going to be probe factor. It makes no sense. It is V/div.. except t"div" part is not spelled explicitly...
So "20V/" means 20V per  division in this case. It is quite logical to me and never even noticed it as a problem.

R&S uses same nomenclature for their scopes, so does Keysight. It is industry standard, really..

Also in probe setup, Siglent correctly specifies it as 100:1 instead 100x probe that is quite common but wrong, as a 100x probe is a probe with amplification of 100x. 
 

Offline knudch

  • Regular Contributor
  • *
  • Posts: 64
  • Country: dk
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #562 on: January 05, 2022, 01:11:01 pm »
It is the probe factor in that part of the field
But I think it has been to confusing to display all kind of values when use custom value.

There for that symbols simply indicates "Custom probe value"

That is my interpretation
 
The following users thanked this post: 2N3055

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6446
  • Country: hr
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #563 on: January 05, 2022, 01:59:37 pm »
It is the probe factor in that part of the field
But I think it has been to confusing to display all kind of values when use custom value.

There for that symbols simply indicates "Custom probe value"

That is my interpretation

Oh thank you, I didn't understand , the small probe icon instead of attn factor..
Yes, that is "custom probe" symbol.  It is deliberate , because if you take into account all combinations (including current conversions) it gets too involved really quick.
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28136
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #564 on: January 05, 2022, 02:03:13 pm »
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
The strange dash represents a sideways pen/pencil/probe signifying a user input attenuation is applied.

SDS2kX+ and 5kX models display this whenever a user attenuation has been set.
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 
The following users thanked this post: Peter_O

Offline Peter_O

  • Frequent Contributor
  • **
  • Posts: 414
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #565 on: January 05, 2022, 04:05:04 pm »
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
The strange dash represents a sideways pen/pencil/probe signifying a user input attenuation is applied.

SDS2kX+ and 5kX models display this whenever a user attenuation has been set.
Thx for claryfying. That explaines the symbol.  :-+
Would be great to have the value of the user attenuation in that field.  :)
I understand, that it might be some work in case Siglent is mapping static bitmaps for the predefined values now.
« Last Edit: January 05, 2022, 04:08:18 pm by Peter_O »
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28136
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #566 on: January 05, 2022, 04:16:30 pm »
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
The strange dash represents a sideways pen/pencil/probe signifying a user input attenuation is applied.

SDS2kX+ and 5kX models display this whenever a user attenuation has been set.
Thx for claryfying. That explaines the symbol.  :-+
Would be great to have the value of the user attenuation in that field.  :)
I understand, that in might be some work in case Siglent is mapping static bitmaps for the predefined values now.
Certainly there's potential to add a # more predefined attenuations like as there is in X-E models however the practical need for more than the 3 currently available is debatable. Once set and the vertical units/div are correct for whatever probe is used we already have enough visible channel tab info for documentation and correct use.

But bounce this around owners here and if good support comes for a common solution you can be sure the beta testers here will take it to Siglent to consider.
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6446
  • Country: hr
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #567 on: January 05, 2022, 04:38:25 pm »
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
The strange dash represents a sideways pen/pencil/probe signifying a user input attenuation is applied.

SDS2kX+ and 5kX models display this whenever a user attenuation has been set.
Thx for claryfying. That explaines the symbol.  :-+
Would be great to have the value of the user attenuation in that field.  :)
I understand, that it might be some work in case Siglent is mapping static bitmaps for the predefined values now.

There is no place there to show all the combinations. For instance you would need to show 1234,5A/1mv for a current probe. And that would make no sense because you are looking at current values on a screen and don't care for voltage at all at that moment.
And as I said, ultimately it is not necessary. Who cares. This whole probe definition business is there to properly scale V/div A/div settings so measurements, graticule and all notations show proper value. After you set the probe you don't care what it is..
Theoretically it wouldn't hurt, but meh, who cares..
 

Offline Peter_O

  • Frequent Contributor
  • **
  • Posts: 414
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #568 on: January 05, 2022, 05:54:24 pm »
When returning to the desk from lunch etc. I like to check the settings, e.g. if the probe attenuation factor is still matching the switch position at the differential amp or switchable probe to ensure the diplayed V/div setting is correct. Would be nice to have it on screen at first glance without having to enter the menu. The scope shows values of 1X, 10X and 100X already. I can see no disadvantage of showing a user value in that place too.

I think I made my point.
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28136
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #569 on: January 06, 2022, 11:18:04 am »
When returning to the desk from lunch etc. I like to check the settings, e.g. if the probe attenuation factor is still matching the switch position at the differential amp or switchable probe to ensure the diplayed V/div setting is correct. Would be nice to have it on screen at first glance without having to enter the menu. The scope shows values of 1X, 10X and 100X already. I can see no disadvantage of showing a user value in that place too.

I think I made my point.
You have and there's certainly room in the probe attenuation menu for many more preset values to be available especially if the scroll bar is added like in some other menus.

Certainly 1000x should be added along with common differential probe values like 50x, 200x and 500x....in fact if real user convenience was properly considered a list matching the X-E range should be added.
Some might complain the commonly used values will be lost in the list yet probes with autosense capability which are more commonly used by professionals will set themselves up automatically without even need to select them from a list.
The User menu should be also moved to the top so it's always visible.
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline Peter_O

  • Frequent Contributor
  • **
  • Posts: 414
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #570 on: January 06, 2022, 07:05:38 pm »
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.
« Last Edit: January 06, 2022, 07:09:19 pm by Peter_O »
 

Offline casterle

  • Regular Contributor
  • *
  • Posts: 129
  • Country: us
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #571 on: January 21, 2022, 12:00:43 am »
> 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.
« Last Edit: January 21, 2022, 12:03:36 am by casterle »
 

Online Martin72

  • Super Contributor
  • ***
  • Posts: 5670
  • Country: de
  • Testfield Technician
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #572 on: January 23, 2022, 11:11:43 am »
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


Offline RBBVNL9

  • Frequent Contributor
  • **
  • Posts: 326
  • Country: nl
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #573 on: January 30, 2022, 09:09:25 am »
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.
« Last Edit: February 01, 2022, 07:11:17 am by RBBVNL9 »
 
The following users thanked this post: Martin72, Deichgraf

Offline Deichgraf

  • Contributor
  • Posts: 18
  • Country: de
Re: Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
« Reply #574 on: January 30, 2022, 11:07:42 am »
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).

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
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf