SDS800X HD Bug Reports + Firmware

[mawyatt]

But I also had a genius idea:  if we really need exact time, we could ask Siglent to implement NTP and synch a scope time with it... Wait.... no, that is already implemented. 

Or you could buy a scope that has RTC clock inside, if that is so important.

Why not include a GPS Disciplined RTC, or wait even better a Rubidium Cesium Atomic RTC 

Best 

[eTobey]

Devices from the last century are able to keep their time (they would even today), but not this Siglent (Yes, even if plugged in, and the powerbutton beeing illuminated). 

By coincidence, even my BLDC controller has a RTC in it...

[ebastler]

[...] RTC [...]

I think we have established long ago (and several times over) that the present thread should focus on bugs, not feature requests?

And no matter where you post them, feature requests don't justify the level of indignation and agitation you tend to express. Same for "I would have expected this to work like so and so, and am surprised to find that Siglent has implemented it in a different way" posts.

[eTobey]

Found another issue: (dont ask questions, go and try it yourself!!!)

File letter case issue

Saved a file with uppercase accidently:
- you can save 2 files with the same name (I believe it asked me to overwrite the uppercase with lower case... i dont know i got yet again confused)
- Overwriting fails (The most recent changed (overwritten) file had not the expected content)
- Sorting order is a mess (see pictures...  )

As said... dont ask questions... 

[Furna]

i dont know i got yet again confused)
As said... dont ask questions... 

Yes, we all know you are confused ... and here people don't ask you question.
They give you suggestion that you never follow.

[eTobey]

If you save a few traces/measurements, here is one thing you really should know, and always keep in mind:

Do not use the save button. Or at least beware of the following: Allthough the button has its own "save to" option, it overwrites the normal save option. So after saving traces, and then taking a screenshot, you end up saving screenshots from then on... 

[eTobey]

Fine adjust for math channels:
I was already dissapointed, as it didnt work for those (with the knob). Found out today it can be set via the menu. 

[eTobey]

Workaround for two problems i just discovered:
- Hitting stop, does not keep the current capture.
- Measurements dont work depending on trigger settings.

It is a signal that has a burst of pulses every 500ms. Trigger is edge. Depending on the trigger source, measurement (green trace) may fail to measure.

Workaround:
Set up holdoff time.

[mikes]

Well, here's a definite bug. Following the SDS Series Programming Guide (EN11G), which says that new commands include:

• COUNter:CURRent  New Command, returns the current counter value.
• :COUNter:STATistics:VALue  New Command, returns the the counter statistics.

That's supposed to be for version 1.1.3.1 (and later). I'm running the latest ( 1.1.3.8 ). Commands simply don't work:

>>COUN?
ON

>>COUN:MODE?
FREQuency

>>COUN:STAT?
ON

>>COUN:SOUR?
C1

>>SYST:ERR?
0,"No error"

>>COUN:CURR?

>>SYST:ERR?
-113,"Undefined header;COUN:CURR?"

>>*CLS

>>SYST:ERR?
0,"No error"

>>COUN:STAT:VAL?

>>SYST:ERR?
-113,"Undefined header;COUN:STAT:VAL?"

>>*CLS

>>SYST:ERR?
0,"No error"

[eTobey]

Well, here's a definite bug.

I guess some folks will immediately disagree. 


What interface are you using? Have you tried others?

[mikes]

Well, here's a definite bug.

What interface are you using? Have you tried others?

The documented SCPI interface. Have you tried it?

[eTobey]

Well, here's a definite bug.

What interface are you using? Have you tried others?

The documented SCPI interface. Have you tried it?

What is your definition of "interface"?

Where is the part, where "this particular" interface is documented?

I am not really interested in testing new things, as i am already fed up with the bugs, but i like to know which way you used the SCPI, where this bug would reside.

[mikes]

What is your definition of "interface"?

Where is the part, where "this particular" interface is documented?

I am not really interested in testing new things, as i am already fed up with the bugs, but i like to know which way you used the SCPI, where this bug would reside.

Documentation was previously referenced. Page 23 if you're lazy.

[2N3055]

Well, here's a definite bug. Following the SDS Series Programming Guide (EN11G), which says that new commands include:

• COUNter:CURRent  New Command, returns the current counter value.
• :COUNter:STATistics:VALue  New Command, returns the the counter statistics.

That's supposed to be for version 1.1.3.1 (and later). I'm running the latest ( 1.1.3.8 ). Commands simply don't work:

>>COUN?
ON

>>COUN:MODE?
FREQuency

>>COUN:STAT?
ON

>>COUN:SOUR?
C1

>>SYST:ERR?
0,"No error"

>>COUN:CURR?

>>SYST:ERR?
-113,"Undefined header;COUN:CURR?"

>>*CLS

>>SYST:ERR?
0,"No error"

>>COUN:STAT:VAL?

>>SYST:ERR?
-113,"Undefined header;COUN:STAT:VAL?"

>>*CLS

>>SYST:ERR?
0,"No error"

Without going into too much detail....
In this case documentation is a bit ahead of released FW.

[Furna]

Well, here's a definite bug. Following the SDS Series Programming Guide (EN11G), which says that new commands include:

• COUNter:CURRent  New Command, returns the current counter value.
• :COUNter:STATistics:VALue  New Command, returns the the counter statistics.

That's supposed to be for version 1.1.3.1 (and later). I'm running the latest ( 1.1.3.8 ). Commands simply don't work:

>>COUN?
ON

>>COUN:MODE?
FREQuency

>>COUN:STAT?
ON

>>COUN:SOUR?
C1

>>SYST:ERR?
0,"No error"

>>COUN:CURR?

>>SYST:ERR?
-113,"Undefined header;COUN:CURR?"

>>*CLS

>>SYST:ERR?
0,"No error"

>>COUN:STAT:VAL?

>>SYST:ERR?
-113,"Undefined header;COUN:STAT:VAL?"

>>*CLS

>>SYST:ERR?
0,"No error"

Without going into too much detail....
In this case documentation is a bit ahead of released FW.

mikes, I would say you established a "direct" connection to the scope i.e."telnet ip.of.the.scope 5025" ... is that correct?

2N3055, could we ask Siglent to have reliable documentation? Frankly speaking "the doc is ahead of the firmware" is not enough for me.
Also the documentation explicitely says the mentioned command is available for SDS800X HD in fw version 1.1.3.1 (pag. 18) of the mentioned document https://siglentna.com/wp-content/uploads/dlm_uploads/2024/09/SDS800XHD_Series_ProgrammingGuide_EN11G.pdf
IMHO it is definitely worth to mention the issue to Siglent.
I can reproduce the issue mikes described on fw 1.1.3.8

Thank you.

[2N3055]

Well, here's a definite bug. Following the SDS Series Programming Guide (EN11G), which says that new commands include:

• COUNter:CURRent  New Command, returns the current counter value.
• :COUNter:STATistics:VALue  New Command, returns the the counter statistics.

That's supposed to be for version 1.1.3.1 (and later). I'm running the latest ( 1.1.3.8 ). Commands simply don't work:

>>COUN?
ON

>>COUN:MODE?
FREQuency

>>COUN:STAT?
ON

>>COUN:SOUR?
C1

>>SYST:ERR?
0,"No error"

>>COUN:CURR?

>>SYST:ERR?
-113,"Undefined header;COUN:CURR?"

>>*CLS

>>SYST:ERR?
0,"No error"

>>COUN:STAT:VAL?

>>SYST:ERR?
-113,"Undefined header;COUN:STAT:VAL?"

>>*CLS

>>SYST:ERR?
0,"No error"

Without going into too much detail....
In this case documentation is a bit ahead of released FW.

mikes, I would say you established a "direct" connection to the scope i.e."telnet ip.of.the.scope 5025" ... is that correct?

2N3055, could we ask Siglent to have reliable documentation? Frankly speaking "the doc is ahead of the firmware" is not enough for me.
Also the documentation explicitely says the mentioned command is available for SDS800X HD in fw version 1.1.3.1 (pag. 18) of the mentioned document https://siglentna.com/wp-content/uploads/dlm_uploads/2024/09/SDS800XHD_Series_ProgrammingGuide_EN11G.pdf
IMHO it is definitely worth to mention the issue to Siglent.
I can reproduce the issue mikes described on fw 1.1.3.8

Thank you.

Note about documentation I agree with.

As for reporting to Siglent there is no need. They know.
Wait for new FW release.

[mikes]

mikes, I would say you established a "direct" connection to the scope i.e."telnet ip.of.the.scope 5025" ... is that correct?

2N3055, could we ask Siglent to have reliable documentation? Frankly speaking "the doc is ahead of the firmware" is not enough for me.
Also the documentation explicitely says the mentioned command is available for SDS800X HD in fw version 1.1.3.1 (pag. 18) of the mentioned document https://siglentna.com/wp-content/uploads/dlm_uploads/2024/09/SDS800XHD_Series_ProgrammingGuide_EN11G.pdf
IMHO it is definitely worth to mention the issue to Siglent.
I can reproduce the issue mikes described on fw 1.1.3.8

Thank you.

5024. 5025 is for raw TCP socket. And you're correct. As I already mentioned and 2N3055 chose to once again ignore, the documentation specifically says it applies to the SDS800X HD, beginning at version 1.1.3.1, several releases ago. 2N3055 seems focused on blaming the user and making rationalizations.

[mikes]

As for reporting to Siglent there is no need. They know.
Wait for new FW release.

So, now you admit it's a known bug.

Why then were you challenging me on it ("I guess some folks will immediately disagree."), bringing up interfaces (can you point to an undocumented SCPI interface I might have been using?), and then making invalid excuses ("In this case documentation is a bit ahead of released FW.")?

[Furna]

5024. 5025 is for raw TCP socket. And you're correct. As I already mentioned and 2N3055 chose to once again ignore, the documentation specifically says it applies to the SDS800X HD, beginning at version 1.1.3.1, several releases ago. 2N3055 seems focused on blaming the user and making rationalizations.

Well, "telnet" is more or less a raw TCP socket client ;-)
While I have to admit 2N3055 sometimes is harsh, I wouldn't say he deliberately "ignore".
Indeed in his last post he stated "they know".
Enough for me.

Regarding the tones used here, I think we have to accept all the limitations of human beings starting from language barriers to cultural differences.

So, now you admit it's a known bug.

Why then were you challenging me on it ("I guess some folks will immediately disagree."), bringing up interfaces (can you point to an undocumented SCPI interface I might have been using?), and then making invalid excuses ("In this case documentation is a bit ahead of released FW.")?

Wait, it was NOT 2N3055 posting that ...

[mikes]

Wait, it was NOT 2N3055 posting that ...

Apologies to 2N3055, that was eTobey.

[eTobey]

What is your definition of "interface"?

Where is the part, where "this particular" interface is documented?

I am not really interested in testing new things, as i am already fed up with the bugs, but i like to know which way you used the SCPI, where this bug would reside.

Documentation was previously referenced. Page 23 if you're lazy.

Still i dont know, if you used NI-MAX or telnet...

Wait, it was NOT 2N3055 posting that ...

Apologies to 2N3055, that was eTobey.

Say what?

[2N3055]

As for reporting to Siglent there is no need. They know.
Wait for new FW release.

So, now you admit it's a known bug.

Why then were you challenging me on it ("I guess some folks will immediately disagree."), bringing up interfaces (can you point to an undocumented SCPI interface I might have been using?), and then making invalid excuses ("In this case documentation is a bit ahead of released FW.")?

I never said you are wrong.
I did not respond immediately because I wanted to test it myself.
I confirmed your finding on your FW.
I agreed documentation and FW should be in synch. Not that Keysight or R&S never had errors in documentation.
It happens when you have common platform where there are scopes with different options based on model.
Discrepancy will be fixed as new FW gets released.

[newbrain]

I don't think this ha been already reported, and I can't find the PEBCAO.

It's a minor display issue, but quite visible.
I got into the situation where an FFT, with horizontal span selected as Linear, is displayed with the right frequency labels, but a logaritmic (Decade) graticule.
Changing from/to Decade and Linear, or any other parameters, including turning off the Math channel and altering the formula did not solve the issue.

See below:

I had previously switched to Decade and then reverted to Linear, but that is not -in general- enough to trigger the problem.

The only way out I found was resetting the configuration to defaults, and starting over (in fact, reloading an older, similar, configuration).


I've saved (and attached) the problematic configuration, and reloading it shows the faulty display again.

[eTobey]

It's a minor display issue, but quite visible.
I got into the situation where an FFT, with horizontal span selected as Linear, is displayed with the right frequency labels, but a logaritmic (Decade) graticule.

So much bugs, that we could actually make sections to sort them. 

In normal mode the graticule is not aligned vertically if moved quite a bit offset, and sometimes when using mask mode, the scale gets messed up, that even sometimes a restart is needed.

Does it happen too after restart???

[mikes]

Here's another bug (or at least sloppy/lazy programming). SDS800X HD basically ignores DHCP lease times. Below is with the lease time set to 8 hours. Instead of renewing every 4 hours (1/2 lease time) as is normal, it's doing it every minute or so. Although technically allowed by the DHCP spec, I've never seen another client do this, and it is unnecessarily abusive. Ugggh.

Code: [Select]

Feb  8 14:13:04 dnsmasq-dhcp[710342]: DHCPDISCOVER(br0) 74:5b:c5:23:68:83
Feb  8 14:13:04 dnsmasq-dhcp[710342]: DHCPOFFER(br0) 192.168.168.71 74:5b:c5:23:68:83
Feb  8 14:13:04 dnsmasq-dhcp[710342]: DHCPREQUEST(br0) 192.168.168.71 74:5b:c5:23:68:83
Feb  8 14:13:04 dnsmasq-dhcp[710342]: DHCPACK(br0) 192.168.168.71 74:5b:c5:23:68:83 scope
Feb  8 14:14:23 dnsmasq-dhcp[710342]: DHCPREQUEST(br0) 192.168.168.71 74:5b:c5:23:68:83
Feb  8 14:14:23 dnsmasq-dhcp[710342]: DHCPACK(br0) 192.168.168.71 74:5b:c5:23:68:83 scope
Feb  8 14:15:37 dnsmasq-dhcp[710342]: DHCPREQUEST(br0) 192.168.168.71 74:5b:c5:23:68:83
Feb  8 14:15:37 dnsmasq-dhcp[710342]: DHCPACK(br0) 192.168.168.71 74:5b:c5:23:68:83 scope
Feb  8 14:16:52 dnsmasq-dhcp[710342]: DHCPREQUEST(br0) 192.168.168.71 74:5b:c5:23:68:83
Feb  8 14:16:52 dnsmasq-dhcp[710342]: DHCPACK(br0) 192.168.168.71 74:5b:c5:23:68:83 scope
Feb  8 14:18:06 dnsmasq-dhcp[710342]: DHCPREQUEST(br0) 192.168.168.71 74:5b:c5:23:68:83
Feb  8 14:18:06 dnsmasq-dhcp[710342]: DHCPACK(br0) 192.168.168.71 74:5b:c5:23:68:83 scope
Feb  8 14:19:21 dnsmasq-dhcp[711671]: DHCPREQUEST(br0) 192.168.168.71 74:5b:c5:23:68:83
Feb  8 14:19:21 dnsmasq-dhcp[711671]: DHCPACK(br0) 192.168.168.71 74:5b:c5:23:68:83 scope
...continues ad infinitum.