Products > Test Equipment

Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

<< < (507/518) > >>

sylvandb:

--- Quote from: 2N3055 on November 16, 2023, 10:14:20 am ---
--- Quote from: tautech on November 16, 2023, 09:45:05 am ---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.

--- End quote ---

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.

--- End quote ---

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:

--- Quote from: sylvandb on November 17, 2023, 05:00:03 am ---
--- Quote from: 2N3055 on November 16, 2023, 10:14:20 am ---
--- Quote from: tautech on November 16, 2023, 09:45:05 am ---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.

--- End quote ---

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.

--- End quote ---

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.

--- End quote ---

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:

--- Quote from: 2N3055 on November 17, 2023, 08:17:28 am ---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.

--- End quote ---
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.
 

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod