Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

[Calambres]

I quote myself:

.../...
BUT, while fiddling with all these configurations I suspected from that very USB extender cable and, know what?... it is also not shielded, as it was the cable from the hub!... again the chinesium curse strikes me back! it is quite possible that buying a good quality USB extender cable will solve the noise problems I'm having 

Well, I got a better quality and shielded USB extension cable and yes, the WLAN now connects with no issues albeit I still got some noise induced by the crappy USB huh. Less noise than before but still there. I need to address this problem but nowadays is not easy to get a good quality USB2 hub and we all know the problems with USB3 hubs and WLAN connections!

But stilll there's a possible bug with the NTP implementation in the scope! 

Yes, this is definitely a bug!

[2N3055]

But stilll there's a possible bug with the NTP implementation in the scope! 

Yes, this is definitely a bug!

Not really, IMO.  You cannot call anything you don't like a bug.

NTP is separate service from basic TCP/IP stack. NTP will refresh when it's time interval is due.
It uses TCP/IP routing and connectivity to server is transparent to it.
It does not know anything changed on TCP/IP level and don't care.

Would it be nice it would do that. Maybe. Maybe not.

What is real purpose of that?
You have a scope that is connected to LAN, and it got it's time from NTP.
Time is correct now.

You switch to WLAN.
It won't requery NTP server because it is already set and time interval for next update is not due.
It has nothing to do with how networks are being connected-disconnected. Clock in device (soft clock) is actually keeping time in meantime.

Did I understand correctly?

[tautech]

As member mwb1100 suggests:
whenever the scope goes from a disconnected to connected state (whether LAN or Wifi), it should automatically Sync NTP if "Power On Sync" or "Periodic Sync" is on

Is proposed for Siglent to consider.

[2N3055]

As member mwb1100 suggests:
whenever the scope goes from a disconnected to connected state (whether LAN or Wifi), it should automatically Sync NTP if "Power On Sync" or "Periodic Sync" is on

Is proposed for Siglent to consider.

I'm not against it.
But it is not a bug. No NTP service does that. I'm not even defending Siglent scope here. It's just no NTP is supposed to do that. On any device.
It is not a bug.
NTP does not care about network. After initial synch (on boot) because it has not battery backed up clock, next refresh is when built in software clock accuracy is questionable because it has been running too long, and then we recheck with NTP server if there are corrections needed.

Actually, if device clock is any good, it is recommended not to synch NTP too often, because it introduces timing jitter...
Updates are not correlated to network config, but only to clock needs..

If you boot with network connected it will work normally. If you boot with network not connected, it will timeout on initial synch. Until next scheduled update, when it will update if network was connected in meantime. Were you can use manual update to speed up things.
If you need reliable NTP, provide reliable network.

There is no built in "option to enable" or "bug to fix".
What can be done is to make separate monitor service that will be aware that time is not set (NTP client connect failed, or synch failed), and would keep that status and be mindful of network connectivity.
But you can have Ethernet port or WIFI connection UP and still have no connectivity to Internet.
What to do then? How do we detect NTP servers are available for synch then?
Gets complicated quickly...

What I think could be useful would be a marker (clock background painted red or something) to user that NTP is set to synch and failed last time. So they know they have network problems and that clock might be in in "uncal" state of a sort..

[tautech]

As member mwb1100 suggests:
whenever the scope goes from a disconnected to connected state (whether LAN or Wifi), it should automatically Sync NTP if "Power On Sync" or "Periodic Sync" is on

Is proposed for Siglent to consider.

I'm not against it.
But it is not a bug. No NTP service does that. I'm not even defending Siglent scope here. It's just no NTP is supposed to do that. On any device.
It is not a bug.
NTP does not care about network. After initial synch (on boot) because it has not battery backed up clock, next refresh is when built in software clock accuracy is questionable because it has been running too long, and then we recheck with NTP server if there are corrections needed.

Actually, if device clock is any good, it is recommended not to synch NTP too often, because it introduces timing jitter...
Updates are not correlated to network config, but only to clock needs..

Correct, not a bug but could be improved.
X-E do not have RTC so when we need it, we need it and it's reliable operation should be linked/latched to network connectivity status.
That is, when when we connect we have a network indicator which shows the OS is monitoring connectivity when NTP refresh could be linked to the network indication rather than need to rely on a NTP sync.

An NTP autosync tied to network connectivity indication will solve this issue automatically and almost instantly.
Those that have these know this issue. 

[sylvandb]

As member mwb1100 suggests:
whenever the scope goes from a disconnected to connected state (whether LAN or Wifi), it should automatically Sync NTP if "Power On Sync" or "Periodic Sync" is on

Is proposed for Siglent to consider.

I'm not against it.
But it is not a bug. No NTP service does that. I'm not even defending Siglent scope here. It's just no NTP is supposed to do that. On any device.

Actually, that is incorrect.  The scope is using a variant of NTP known as Simple NTP or SNTP.  (The key difference is polling and directly setting time instead of the full NTP approach of synchronized, adaptive feedback loop keeping time in sync potentially as both a client and a server.)  Many network devices which obtain time using SNTP do indeed poll the NTP server when the network connection is started, and start their polling interval from that event. In those devices if the network disconnects then the NTP service will poll again immediately on reconnect whether or not the polling interval has lapsed.

A full NTP implementation actually creates a lot more network traffic than SNTP as the poll intervals for SNTP are typically multiple orders of magnitude longer than that for a full NTP implementation (often 1024 seconds max compared to hours or even a daily poll for SNTP).  This means that it is more important for a SNTP implementation to poll on connect since it might be a very long time before the interval expires compared to a few seconds for a full NTP implementation.  One of the primary reasons this has become best practice is the only time you know the network is available is when it connects.  In a few hours?  Maybe, maybe not.

How do I know this?  I have over 30 years of directly applicable standard definition and implementation experience, and currently work as a senior principal firmware engineer in this field.  All of the devices running firmware produced by my current employer poll immediately on connect, and so do the vast majority of network devices I've worked with from all the "smart" gadgets in my house to devices costing hundreds of thousands of dollars, at least when using SNTP.

[2N3055]

As member mwb1100 suggests:
whenever the scope goes from a disconnected to connected state (whether LAN or Wifi), it should automatically Sync NTP if "Power On Sync" or "Periodic Sync" is on

Is proposed for Siglent to consider.

I'm not against it.
But it is not a bug. No NTP service does that. I'm not even defending Siglent scope here. It's just no NTP is supposed to do that. On any device.

Actually, that is incorrect.  The scope is using a variant of NTP known as Simple NTP or SNTP.  (The key difference is polling and directly setting time instead of the full NTP approach of synchronized, adaptive feedback loop keeping time in sync potentially as both a client and a server.)  Many network devices which obtain time using SNTP do indeed poll the NTP server when the network connection is started, and start their polling interval from that event. In those devices if the network disconnects then the NTP service will poll again immediately on reconnect whether or not the polling interval has lapsed.

A full NTP implementation actually creates a lot more network traffic than SNTP as the poll intervals for SNTP are typically multiple orders of magnitude longer than that for a full NTP implementation (often 1024 seconds max compared to hours or even a daily poll for SNTP).  This means that it is more important for a SNTP implementation to poll on connect since it might be a very long time before the interval expires compared to a few seconds for a full NTP implementation.  One of the primary reasons this has become best practice is the only time you know the network is available is when it connects.  In a few hours?  Maybe, maybe not.

How do I know this?  I have over 30 years of directly applicable standard definition and implementation experience, and currently work as a senior principal firmware engineer in this field.  All of the devices running firmware produced by my current employer poll immediately on connect, and so do the vast majority of network devices I've worked with from all the "smart" gadgets in my house to devices costing hundreds of thousands of dollars, at least when using SNTP.

Thank you for detailed explanation and a refresher course.
That was absolutely an error on my side. I meant to say SNTP. Which is by default what even desktop Linux will use (SNTP) when set as client, unless you install NTP.

SNTP is default time client on most devices out there AFAIK.

Full NTP implementation is used, as you said, when you need really accurate time, down to milliseconds.
Scope just uses time to timestamp files and screen captures. It is not in any way needed for scope function at all.
It was added to scope because it does not have a battery backed up RTC, so users don't have to set up clock manually.
On DHO800 Rigol solved that problem by removing clock completely...
Full NTP protocol is unnecessary in this case and a solution to a problem that does not exist.

In most networks I've seen people created a number of time servers running full NTP in whatever topology by stratas they did and all other devices were pretty much just SNTP clients  to keep servers/devices showing same file timestamps. Mostly for logging/auditing correlation purposes.
Mostly, whatever built in time synch is built in they enable it and job done. It is just not critical 99% of the time.
Rarely I've seen full NTP where they were processing things they wanted to be timestamped to better than second.

Again, thanks for the correction and all the best,

[tautech]

It was added to scope because it does not have a battery backed up RTC, so users don't have to set up clock manually.

FYI
X-E models never had any clock until the Logging feature was added in a recent FW.
The addition of NTP gave timestamps for the logging and gave us a OSD clock and timestamps for file captures.
We can choose to not show the OSD and still have the benefits of timestamps for all other needs.

[Willem2018]

Hello I am looking for an measurement tool on my Siglent SDS1104X-E  to automatically count edges for a time interval between a specified start-point and end-point.
I can't find such an option. Is this possible or can it be implemented by Siglent?

Many thanks.

[Gridstop]

Can anyone explain the weird jumps in channel skew (like hundreds of uS) when changing vertical gain on one channel on my SDS1104XE?

I was testing with a micsig differential probe and a regular passive probe (both 10X), monitoring a zero-crossing detector. At most vertical settings, the two line up perfectly (and as expected), since it's a bidirectional optoisolator, the off pulse is neatly centered around the zero crossing. But when I was zooming in on the AC signal to get a nice vertical line to measure from, I noticed in the range from 100mV to 1V per division, the zero crossing jumps outside of the pulse (pulse width is about 500uS, so the error is >250uS, so it's not normal channel skew). Above 1V/div on the AC signal and below 100mV/div on the AC signal, they line up perfectly. At the 1V<->2V transition there is a relay click that coincides with the error jump but nothing audible happens at 50mV<->100mV where it jumps back to centered.

Is this just some weird group delay thing in the frontend of the channel? How on earth am I supposed to know when this is happening? It doesn't appear correctable since the channel skew tops out way below this error, at least at the time bases of interest when measuring.

EDIT: I removed the micsig from the equation and took some screenshots. Schematic is as simple as it gets. The screenshots show what's seen at 2V/div and 1V/div (nothing else changes, taken seconds apart) on channel 2, which is directly showing the AC from the transformer going to the opto. The last pic shows what happens if you move the Ch 2 probe directly across the diodes (other side of the 1K resistor), the weird shift is totally gone, and it's consistent across all voltage ranges.
 

[Performa01]

Hello I am looking for an measurement tool on my Siglent SDS1104X-E  to automatically count edges for a time interval between a specified start-point and end-point.
I can't find such an option. Is this possible or can it be implemented by Siglent?

Unfortunately, the SDS1000X-E series DSOs are somewhat limited when it comes to math and measurements. They support gated measurements, but cannot count edges. SDS2000X Plus and above offer more in this regard and count edges and pulses. The same goes for the upcoming SDS800X HD and SDS1000X HD.

I'm not sure Siglent will be putting much effort to add new features to a six year old product, yet it never hurts to place a wish, which I've done right now...

[Performa01]

Can anyone explain the weird jumps in channel skew (like hundreds of uS) when changing vertical gain on one channel on my SDS1104XE?

Yes. It's just input stage overloading.

Other than ancient low bandwidth oscilloscopes, most modern instruments utilize a split path input buffer. When overloaded, the LF path will cleanly clip, but the HF path differentiates and generates a DC component, which causes weird signal distortions and level shifts.

It's a basic rule for DSOs that you cannot trust any results as soon as the amplitude of a signal exceeds the screen borders.
As long as the input signal never exceeds +/-1 V (taking the vertical offset into account!), there shouldn't be too much of a problem, even when you view it at 1 mV/div vertical gain. But any input signal outside that window will definitely cause problems (as long as you don't view it at a proper vertical setting where no part of the signal is outside the visible screen area).

Solution: use a probe with more attenuation, e.g. 100x instead of 10x, to keep the input signal within that magical +/-1 V range.

[Gridstop]

Thanks! You're right of course. I was thinking just in terms of gain/scaling, not the absolute input limit when it shifts to the lower voltage range. Switching the micsig to 100x fixed the problem right away and I can still turn up the gain to get a nice vertical line to measure off of.

[Performa01]

Hello I am looking for an measurement tool on my Siglent SDS1104X-E  to automatically count edges for a time interval between a specified start-point and end-point.
I can't find such an option. Is this possible or can it be implemented by Siglent?

Yes ... we'll very likely get that with the next firmware update.

Even though the SDS1000X-E series will soon be obsolete because of the new SDS800X HD (which of course has the much more complete set of measurements inherited from its bigger siblings, including pulse and edge count), we will still get some maintainance for the X-E series.

[pope]

we will still get some maintainance for the X-E series.

That will be great considering how many of these scopes exist out there. A kind of win-win situation. After-sales support it's a big plus for both the user and the brand.

[CodeToInsanity]

Hello!

I have SDS1104X-E. SW: 6.1.37R10 and I want to measure audio (voltage) signal from a speaker and I have a differential probe for this. I also have working access over Ethernet, so for example 'lxi-tools' are working and I am able to send and receive SCPI commands. The main problem is that I want to log the signal and analyze the value later and I need to control recording remotely with a code. The recording maximum length would be three hours.

I have tried the sample-logger function which saves the values to the USB-device, but I haven't yet found a way to start sample-logger with SCPI commands. Is this possible?
I also have made a script "for-loop" that triggers the "C1:WF? DAT" command, but I have problems getting the timing correct here so I would not lose data, data overlapping would not a be a problem. I tried the "roll mode" and I manually trigger the command each 14*tdiv(0.5s for example, 14 is the number of squares in time-axle) and this seems to give me pretty good results.

How should I proceed with this problem? Sample rate does not need to be very high because audio signal is mostly 1000 Hz sine wave. Basically the ideal solution is where I don't need to touch the oscilloscope other than turn it on.

[orzel]

I have this vague feeling it probably has been answered somewhere already, but i can't find the information : how does my sds1104x-e reports "Uboot-OS Version: 8.1", while the official siglent updates page mentions "SDS1xx4X-E Operating System -V3 (Only For 4-Channel models) (Release Date 01.05.23 )" ? The only "8.1" mentionned on the page are related to the sla1016 (which i don't own neither care).

I have a recent firmware (6.1.37r6) even if not the latest, and the other informations on the "about" page are unrelated to the OS.

Does "8.1" mean i have the "V1" ? Does "V1" even exist ?

The pdf included in the previously mentioned download (see attachment) mentions versions "1" "2" "3" without the "V". I'm not even sure what i have.

Bonus question: my hardware is old ("01-03"), and i understand i dont "need" version 3, but i can still install it ? I kinda guess 'yes', but I of course don't want to brick my scope because it's only intended for newer hardware revisions.

[tautech]

I have this vague feeling it probably has been answered somewhere already, but i can't find the information : how does my sds1104x-e reports "Uboot-OS Version: 8.1", while the official siglent updates page mentions "SDS1xx4X-E Operating System -V3 (Only For 4-Channel models) (Release Date 01.05.23 )" ? The only "8.1" mentionned on the page are related to the sla1016 (which i don't own neither care).

I have a recent firmware (6.1.37r6) even if not the latest, and the other informations on the "about" page are unrelated to the OS.

Does "8.1" mean i have the "V1" ? Does "V1" even exist ?

The pdf included in the previously mentioned download (see attachment) mentions versions "1" "2" "3" without the "V". I'm not even sure what i have.

Bonus question: my hardware is old ("01-03"), and i understand i dont "need" version 3, but i can still install it ? I kinda guess 'yes', but I of course don't want to brick my scope because it's only intended for newer hardware revisions.

V1 was the very first OS now updated to V3 to support the later added featureset.
You can download V3 OS here:
https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS1xx4X-E_EN.zip

To have/support all the latest features the latest R10 FW should be installed also:
https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS1xx4X-E_V6.1.37R10_EN.zip

They are each different install processes, the OS update needs be unzipped and files placed in the root folder of a USB stick (FAT32 4k clusters) and will autoload at boot.
The FW OTOH is selected from any folder from your USB stick and told to run/recall.
Utility (P3 IIRC) > Upgrade and follow your nose. 

When both are installed and after a min of 30mins run the SelfCal then you are fully updated and good to go.

[orzel]

V1 was the very first OS now updated to V3 to support the later added featureset...

I know all of this. I have updated the firmware for sure, and i kinda recall also updating the OS. (but thanks for caring !)

My questions are really focused on "8.1". What is it ? What does it mean ? It seems so unrelated to the official documents / web pages.

[tautech]

V1 was the very first OS now updated to V3 to support the later added featureset...

I know all of this. I have updated the firmware for sure, and i kinda recall also updating the OS. (but thanks for caring !)

My questions are really focused on "8.1". What is it ? What does it mean ? It seems so unrelated to the official documents / web pages.

As I recall the 8 signifies the product line or maybe UI type and 1 is the OS version.
Not all get 8.3 displayed after installing with some displaying 8.2 but V3 OS can be confirmed installed correctly if you have the Logging or NTP feature working correctly.

I've done many OS installs prior to dispatch without issue.

[orzel]

As I recall the 8 signifies the product line or maybe UI type and 1 is the OS version.
Not all get 8.3 displayed after installing with some displaying 8.2 but V3 OS can be confirmed installed correctly if you have the Logging or NTP feature working correctly.

Ok, so it's really messy, no wonder i was lost. Thanks for clarifying somehow !

[tautech]

As I recall the 8 signifies the product line or maybe UI type and 1 is the OS version.
Not all get 8.3 displayed after installing with some displaying 8.2 but V3 OS can be confirmed installed correctly if you have the Logging or NTP feature working correctly.

Ok, so it's really messy, no wonder i was lost. Thanks for clarifying somehow !

Not exactly sure why this is but I suspect production was installing V2 OS and labelling it as the very early V1.
Some I installed only displayed V2 however the NTP feature worked as it should....we enter the NZ NTP server URL before dispatch too.

[rf-loop]

There have been now 4 versions. V0, V1, V2 and now V3
Afaik V3 do not add anything (visible to user) over V2 in HW version below 09.

V3 is for support some changes on hardware (hardware version 09-xx)

It is also told in OS revision history: If your HW version is below 09-xx  you do not need update to V3

Bit difficult to understand why peoples try update to V3 if they have HW version below 09-xx

With other words:  If your HW version is below 09-xx) do not update to V3. (If you still try, nothing happens but you waste time - remember that it is a non-renewable resource at the personal level)

[orzel]

With other words:  If your HW version is below 09-xx) do not update to V3. (If you still try, nothing happens but you waste time - remember that it is a non-renewable resource at the personal level)

This is crystal clear from the update document. Still people from v0 or v1 will probably want to update to the latest version, and wont waste more time doing so.

And it's really fast anyway, worth few minutes including download, putting on usb key and reboot of scope.