Time sync system clock R&S RTB2004

[tautech]

But to put this into perspective: I have several recent and not-always-so-cheap instruments in my lab that have no time and date setting at all!!<snip> The files created on a USB stick etc. carry time stamps like “30 Dec 1999 at 23:00”. Oef!

Now there's a project for you to check which instruments you have that keep the most accurate time.

At the risk of derailing this nice R&S thread, I have to say that the Siglent SDG1000X arbitrary wave generator (and probably its siblings) gets a special mention for waking up at each power-on thinking it is midnight, January 1, 1970. 
   I actually modified pdenisowski's Python script to set the time and date of the SDG, but there is really not much point since the data is volatile and resets on every power cycle. In case anyone is interested, though, that modified script is attached.

Correct, these models make no claim of having a RTC so Linux default time it is.

[R.J.]

Done another measurement where the values had to be saved where the measurement is at a time in the future.
I understand it has to do with summer and winter time. However, you only find out when you have already saved the measurement. After all, the measurement is already recorded on USB stick.
If the scope had copied the correct date and time from, in this case the router acting as an NTP server in the network, this problem would not occur.
Every device in the network (Managed switches and home automation devices) uses the router as time synchronisation, but an expensive scope from a reputable brand does not ()
See the attached screenshot.

[nctnico]

Having an NTP server / client is not going to help you as NTP distributes UTC time. What would be needed is being able to setup the time zone with the correct daylight savings. Besides equipment running an OS like Linux or Windows, I have not seen any equipment with this capability. So what the RTB2004 is doing, is not out of the ordinary at all.

[R.J.]

In the scope, there is an option to set the date and time in a menu. How easy would it then be to include the option for the correct time zone?
By decoding the SNTP protocol and including it in the scope's firmware, the date/time parameters of the internal clock can then be synchronised.
SNTP time synchronisation is implemented in the smallest hardware, take an ESP32 from Espressif for example. Why there??
It is just extremely irritating and frustrating that such a device as a scope with all the options of ±€9300,= is not equipped with this (standard) functionality while data with date and time (such as screenshots and measurements) can be saved in a file for later diagnosis and processing.
The implementation of such a piece of SNTP-sync software might well be a standard in the more expensive/most expensive segment of these measuring devices()
Very unfortunate that they did not then include it in the "entry-level" models when it is available ().
If the higher-end measuring equipment does not have time synchronisation, then the manufacturers have made a big mistake.

A measurement is something fleeting and can occur once. How important it is then to have the correct and exact date and time of that event and to be able to record it in a file with the proper date and time stamp.

[tooki]

In the scope, there is an option to set the date and time in a menu. How easy would it then be to include the option for the correct time zone?

Probably a lot more complex than you think,* but still trivial since there are libraries that can do it, and the scope certainly has enough storage and CPU to handle it.

*time zones are one thing, but different countries switch to/from summer and winter time at different times, using different rules, so automatic switching, at least, is a lot more complex under the hood than just a checkbox.

[Kean]

Time zone data is quite big (for an embedded system) at more than 500kB compressed.  Maybe not a lot for recent hardware, but it does make the user interface for tz selection non-trivial.
It also changes quite frequently, with 197 commits and 71 releases over just the last 8 or 9 years (tzdata-info on github), so now you have an ongoing maintenance issue.
So what seems like a quite simple problem, actually becomes a reasonably complex problem to correctly address for all potential users.  I wish we could do away with summer/winter time changes.

[tooki]

I wish we could do away with summer/winter time changes.

I agree 100000%.

[2N3055]

Time zone data is quite big (for an embedded system) at more than 500kB compressed.  Maybe not a lot for recent hardware, but it does make the user interface for tz selection non-trivial.
It also changes quite frequently, with 197 commits and 71 releases over just the last 8 or 9 years (tzdata-info on github), so now you have an ongoing maintenance issue.
So what seems like a quite simple problem, actually becomes a reasonably complex problem to correctly address for all potential users.  I wish we could do away with summer/winter time changes.

It is a case of overthinking. A simple manual time offset (+2h UTC, or -4h UTC) and user need to twice a year set it right would address 99.99% of problems. Point in fact, it would be faster than searching linear list for your town/coutry/region setting..

[Kean]

It is a case of overthinking. A simple manual time offset (+2h UTC, or -4h UTC) and user need to twice a year set it right would address 99.99% of problems. Point in fact, it would be faster than searching linear list for your town/coutry/region setting..

Yes, in fact this is what I typically implement on embedded systems.  Sometimes there is a central server that pushes out TZ offset changes.  Where possible, we just use UTC.  And the UTC time is usually spot on due to NTP or GPS sync.

But R.J. complained about both lack of time sync and TZ offset correction - his image shows the time on the scope as 59 minutes fast.

[R.J.]

There are scopes who sync there internal OS-clock with the router on it's network!!! 
https://siglentna.com/application-note/datalogging-with-the-four-channel-sds1000x-e-oscilloscope-models/
So this is what I want to see in the R&S RTB200x....... When powering the scope, it's syncs the internel clock. That's all.

[tautech]

There are scopes who sync there internal OS-clock with the router on it's network!!! 
https://siglentna.com/application-note/datalogging-with-the-four-channel-sds1000x-e-oscilloscope-models/
So this is what I want to see in the R&S RTB200x....... When powering the scope, it's syncs the internel clock. That's all.

Not exactly.

X-E range DSO's have no internal clock until the NTP feature was introduced to support the new Logging feature.
This requires a WAN connection to your local NTP server via LAN or WiFi when your local timezone is also required to be set.

[R.J.]

It is exactly what I mean.
To take measurements and save them on a USB-stick, the date/time stamp is important.
Because now the OS's internal clock is never synced with the correct (NTP) time when the scope is switched on, the time of the file containing the measurements is not correct at all.
Especially when changing summer/winter time.
The issue is not whether the Operating Software clock should be exactly the same to the second or tenths of a second, it is about the internal OS clock being synchronised when turning on the scope so that the stored files are provided with the correct time and date stamp.
So exactly as it happens with the Siglent for logging measurements.

[R.J.]

Here is an example of a multimeter from GW-Instek in which the internal clock can be synchronised over the LAN connection by using an NTP server on the Internet, as it should be.
When the local router is the NTP-server you can use the router address.
The pictures are a part of the manual for the GDM-906X benchtop multimeter.
On pages 139/140 of the manual show the settings.

So there are instruments that can sync their RTC by using NTP time servers.
Such an implementation is just a piece of software.

[tooki]

So there are instruments that can sync their RTC by using NTP time servers.

Duh. Nobody ever said otherwise.

Such an implementation is just a piece of software.

Obviously. Nobody said a hardware RTC is the sole way to solve this problem.

[tooki]

There are scopes who sync there internal OS-clock with the router on it's network!!! 
https://siglentna.com/application-note/datalogging-with-the-four-channel-sds1000x-e-oscilloscope-models/
So this is what I want to see in the R&S RTB200x....... When powering the scope, it's syncs the internel clock. That's all.

No, it’s not syncing with the router, it’s syncing with whatever NTP server you tell it to. Most of the time that will NOT be your local router.

I’m puzzled as to why “router-as-NTP-server” occupies such a prominent place in your headspace, since that’s a comparatively rare configuration.

[nctnico]

There are scopes who sync there internal OS-clock with the router on it's network!!! 
https://siglentna.com/application-note/datalogging-with-the-four-channel-sds1000x-e-oscilloscope-models/
So this is what I want to see in the R&S RTB200x....... When powering the scope, it's syncs the internel clock. That's all.

No, it’s not syncing with the router, it’s syncing with whatever NTP server you tell it to. Most of the time that will NOT be your local router.

It depends a bit on how the network is setup. DHCP has a field that can tell a client which NTP server to use so routers can use that to announce NTP servers to clients. For example: the internet router that is supplied by my internet provider comes pre-configured with NTP servers and it likely includes the NTP servers' information as part of the DHCP fields it supplies to clients. In other words, it is not outlandish to think that an internet router can play a role in a plug&play NTP configuration of devices on the network.

[tooki]

Sure, but that’s still not the same thing as the router being the NTP server.

[R.J.]

I mentioned it before, see reply #14 in this topic.

Yes the router acts as a NTP-server and every router has de ability to do so!All the network clients can use the routers IP-address as the NTP-server, your IOT-devices, laptops etc....The router can be used if the ability is in the client to synchronise with an ntp server.

Furthermore, time-synchronisation is essential within a network.
After all, all servers and clients must have the same time, as otherwise logging on within the network is not possible with a large time difference between clients and servers.
Also, if there is no time synchronisation, the various internal clocks of clients will always be out of sync and the content of events in log files will be meaningless.

[tooki]

I mentioned it before, see reply #14 in this topic.

Yes the router acts as a NTP-server and every router has de ability to do so!

Your router has that option, but most do NOT. As I said, that’s a rare configuration, generally speaking.