Time sync system clock R&S RTB2004

[R.J.]

I am the proud owner of an R&S RTB2004.
Connected to the internal network of my home, using the web browser integration, remote control of this oscilloscope is very convenient.
I have now found out that when creating screenshots, the system clock of this oscilloscope does not synchronise with the system clock of e.g. the computer(s) on the network. After leaving the device switched off for several weeks, it appears that the clock is several minutes behind.
There is no possibility in the menus to synchronise this time or to synchronise it with e.g. the router acting as NTP server in the network.
The clock can only be set to a time.
This is quite a bad thing, as time synchronisation within a network is essential for many devices.

Perhaps there is a possibility of using a SCPI command to synchronise the system time to the DHCP server/router acting as an NTP server.
I have searched but cannot find a solution.

Does anyone know of a solution?

[pdenisowski]

You can set the time on the RTB2000 using SCPI commands:

SYSTem:TIME <Hour>,<Minute>,<Second>

[R.J.]

Thank you for replying.
But that's manual setting the time and is not in sync.
I can also set the time by using the menu.
This is not what I want to do.

[pdenisowski]

Sorry, I assumed that you wanted the RTB2000 time to match the time of a computer on your network.  Is it possible to run (manually or automatically, e.g. using a cron job) a script on one of your computers that checks that computer's time and then issues a SCPI command to the RTB?  I can write an example in Python if that would be helpful.

[R.J.]

Thanks for your offer.
But weird that such an elaborate device like this scope does not have by default the ability to conform to a system time within an environment it is in. A system time is the most important parameter when it comes to things that are somehow interconnected, dependent on each other and evidence to/about each other.
The menu for TCP parameter settings should also provide an option to retrieve a system time according to the NTP protocol from the DHCP server so that the oscilloscope's system time has a reference.
Then there is no room for error in a script that would have to run on some PC.

Am I the only one who has experienced this "problem" and is now finding out?

[modoran]

As a workaround you can run the NTP sync on your computer and send SCPI commands automatically to the scope every time. Not ideal, but it will do the job.

[pdenisowski]

Here's a short Python script that queries the time on the local machine and then connects to and sets the time on the oscilloscope.  I don't have an RTB in my lab at the moment, but I did test it against an RTM and it works as expected. 

I'll talk to the product line about the desire for NTP based synchronization.  It really hasn't come up for me before with this type / class of instrument.  In my experience, very tight time synchronization between devices in a test setup is usually achieved using an external trigger signal. 

Sorry, but that's probably the best I can do in the short-term.  Given that the resolution of the RTB "clock" is only seconds, I don't think an NTP client running on the RTB would achieve significantly greater accuracy than using a SCPI command to check/set the RTB time.  If you can provide me with more details of your test scenario (PM is also fine if you don't want to publicly share), that would also be helpful.

[nctnico]

Here's a short Python script that queries the time on the local machine and then connects to and sets the time on the oscilloscope.  I don't have an RTB in my lab at the moment, but I did test it against an RTM and it works as expected. 

I'll talk to the product line about the desire for NTP based synchronization.  It really hasn't come up for me before with this type / class of instrument.  In my experience, very tight time synchronization between devices in a test setup is usually achieved using an external trigger signal. 

I think the OP is not after synchronising measurements as NTP is good down to tens of milliseconds anyway. I can imagine that having the correct time on instruments could be helpful to cross-reference measurements / screendumps between various instruments to determine which measurement lead to certain results.

Using NTP is a bit of a can of worms though as NTP provides UTC time. The oscilloscope would need to know the time zone and daylight savings schedule for that time zone.

[R.J.]

Dear pdenisowski, I understand that you represent R&S and that you work for R&S. I am glad you want to help me with the issue I have run into.
Often it is not possible to "speak" to someone from the manufacturer of the gear purchased.
I appreciate it very much, especially precisely because you could have some "influence" with the manufacturer of this fine tool.

What matters is the following. Measurements taken should have a correct date/time relative to each other in case of e.g. reporting.
This means that when measurements are saved (e.g. in a CSV file on a USB stick) or screenshots are taken, they have the correct date and time.

As nctnico described: The oscilloscope would need to know the time zone and daylight savings schedule for that time zone.

[pdenisowski]

Dear pdenisowski, I understand that you represent R&S and that you work for R&S. I am glad you want to help me with the issue I have run into.
Often it is not possible to "speak" to someone from the manufacturer of the gear purchased.
I appreciate it very much, especially precisely because you could have some "influence" with the manufacturer of this fine tool.

Very happy to help.  We (R&S) are always very interested in feedback, requests, etc. from customers, and I'll discuss this request (time synchronization / timestamps) with our oscilloscope product management team.  Can't promise that we'll implement anything (in the short term), but I can guarantee that the request will be heard

[pdenisowski]

I think the OP is not after synchronising measurements as NTP is good down to tens of milliseconds anyway. I can imagine that having the correct time on instruments could be helpful to cross-reference measurements / screendumps between various instruments to determine which measurement lead to certain results.

Understood.  I work with a lot of loaner / demo instruments and pretty much none of them arrive at my lab with the date/time set appropriately   Can be an issue when I'm searching for measurement results or screenshots I remember making at a certain time or on a certain date.

Using NTP is a bit of a can of worms though as NTP provides UTC time. The oscilloscope would need to know the time zone and daylight savings schedule for that time zone.

Yep, that would also need to be addressed as well. 

[R.J.]

That's exactly what I mean.
Without being connected to the network, I can imagine you setting the date and time manually every time.
However, just about everyone has a network in his or her home/lab and will also want to connect his/her measuring equipment to it in order to use the nice and fast remote control that is possible.

How convenient it would then be to have the scope's date/time set by the router in that environment, (that router is basically always used as a time server [NTP server] for the locally connected network equipment) to be set equal to the actual date, time and time zone.

[tooki]

That's exactly what I mean.
Without being connected to the network, I can imagine you setting the date and time manually every time.
However, just about everyone has a network in his or her home/lab and will also want to connect his/her measuring equipment to it in order to use the nice and fast remote control that is possible.

How convenient it would then be to have the scope's date/time set by the router in that environment, (that router is basically always used as a time server [NTP server] for the locally connected network equipment) to be set equal to the actual date, time and time zone.

I’m not aware of any routers that act as NTP servers. I’m not sure why you’d bother since you can just sync to a public one. It’s not like NTP causes enough traffic to bog down your network.

Using NTP is a bit of a can of worms though as NTP provides UTC time. The oscilloscope would need to know the time zone and daylight savings schedule for that time zone.

Given that there are time libraries that handle all of that, both large libraries for PC software and compact ones for microcontrollers, that is a problem that is absolutely trivial to solve.

I mean, a minimal implementation takes under 20 lines of user code to do on an ESP32 with ready-made libraries.

[tautech]

I’m not aware of any routers that act as NTP servers. I’m not sure why you’d bother since you can just sync to a public one. It’s not like NTP causes enough traffic to bog down your network.

Yet a member here experienced in security systems maintains some can and we were to investigate to sync with the NTP server in SDS1104X-E which doesn't have a RTC.
He wanted it for portable use with valid timestamps on screenshots however carrying around a router just for that seemed nuts to me so a much simpler solution was devised using the already inbuilt functionality with a USB WiFi dongle and hotspotting it to your phone. < Worked a treat !

Carrying an additional few grams of dongle and the phone that is always with you seemed make far more sense.

[R.J.]

Quote from: tautech on Today at 18:45:51>Quote from: tooki on Today at 18:10:19>"I’m not aware of any routers that act as NTP servers. I’m not sure why you’d bother since you can just sync to a public one. It’s not like NTP causes enough traffic to bog down your network.
Yet a member here experienced in security systems maintains some can and we were to investigate to sync with the NTP server in SDS1104X-E which doesn't have a RTC.
He wanted it for portable use with valid timestamps on screenshots however carrying around a router just for that seemed nuts to me so a much simpler solution was devised using the already inbuilt functionality with a USB WiFi dongle and hotspotting it to your phone. < Worked a treat !

Carrying an additional few grams of dongle and the phone that is always with you seemed make far more sense."


Gentlemen, the situation I am trying to outline concerns a stable situation, not a mobile lab.
Every router connected between the home network and the Internet basically can work/works as an NTP server or is easily set up as such. Precisely because there are more and more devices at home that require time synchronisation. PCs have depended on it for some time, but anything with an internal clock will be able and willing to make use of it. And that just works.
Thank you for understanding.

[tooki]

Gentlemen, the situation I am trying to outline concerns a stable situation, not a mobile lab.
Every router connected between the home network and the Internet basically can work/works as an NTP server or is easily set up as such. Precisely because there are more and more devices at home that require time synchronisation. PCs have depended on it for some time, but anything with an internal clock will be able and willing to make use of it. And that just works.

Again, I have used myself (or set up for clients) numerous routers over the years and have never encountered one that offered an NTP server out of the box. (One of them could do it via third party firmware.)

So while the FritzBox apparently does do it, I don’t think it’s a particularly common feature. It certainly isn’t something “every router” does, as you claim.

[2N3055]

Gentlemen, the situation I am trying to outline concerns a stable situation, not a mobile lab.
Every router connected between the home network and the Internet basically can work/works as an NTP server or is easily set up as such. Precisely because there are more and more devices at home that require time synchronisation. PCs have depended on it for some time, but anything with an internal clock will be able and willing to make use of it. And that just works.

Again, I have used myself (or set up for clients) numerous routers over the years and have never encountered one that offered an NTP server out of the box. (One of them could do it via third party firmware.)

So while the FritzBox apparently does do it, I don’t think it’s a particularly common feature. It certainly isn’t something “every router” does, as you claim.

Every Mikrotik does..You need to load NTP package but it is available...

[R.J.]

The question is not whether the router can be used as an NTP server or whether a network client can synchronise its system clock with a router or not.
Your PC will sync his date/time also, with or without a router configured as a NTP-server. It's just an example.

The issue is that there is currently no way to synchronise the oscilloscope's system clock with the system time of the environment in which it is located.
For example, via parameters (NTP time server URL or such) that could be entered in the network settings of the oscilloscope, you could have the firmware synchronise the system date and time/timezone when booting the scope using the (S)NTP protocol.

[modoran]

Every Mikrotik does..You need to load NTP package but it is available...

I tried myself on Mikrotik hap ac2 with ntp package installed, it doesn't work if no internet available.  The "server" is still on the internet.   Anyway you still need to set the ntp server to use on your device settings to work, which this scope doesn't have. If it has the setting no router will be needed, just IP adress of ntp server.

[tooki]

Gentlemen, the situation I am trying to outline concerns a stable situation, not a mobile lab.
Every router connected between the home network and the Internet basically can work/works as an NTP server or is easily set up as such. Precisely because there are more and more devices at home that require time synchronisation. PCs have depended on it for some time, but anything with an internal clock will be able and willing to make use of it. And that just works.

Again, I have used myself (or set up for clients) numerous routers over the years and have never encountered one that offered an NTP server out of the box. (One of them could do it via third party firmware.)

So while the FritzBox apparently does do it, I don’t think it’s a particularly common feature. It certainly isn’t something “every router” does, as you claim.

Every Mikrotik does..You need to load NTP package but it is available...

Niche equipment hardly makes up a significant share of the routers in use. And I even said “out of the box”, which an added package does not qualify as.

[nctnico]

Either way, if you have an internet connection you can use oodles of NTP servers. So it is not like having an NTP server on a router is going to provide more features. After all, the NTP server on a router will need to get the time from somewhere as it likely doesn't have an accurate internal RTC. For standalone use you might want to venture into GPS enabled NTP servers but it appears there are also phone apps that can turn your phone into an NTP server.

[RBBVNL9]

I totally sympathize with the desire of the OP to have the right time set on instruments in order to have files and screenprints carry the right time and date. If possible, a time server function that automatically updates, with time zone support and all, would be ideal. Some instruments have this (the degree to which this actually works varies ;-) and others do not have it.

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!! Not even manual...  (Not going to do naming and shaming now). That is hugely inconvenient. The files created on a USB stick etc. carry time stamps like “30 Dec 1999 at 23:00”. Oef!

[tautech]

I totally sympathize with the desire of the OP to have the right time set on instruments in order to have files and screenprints carry the right time and date. If possible, a time server function that automatically updates, with time zone support and all, would be ideal. Some instruments have this (the degree to which this actually works varies ;-) and others do not have it.

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!! Not even manual...  (Not going to do naming and shaming now). That is hugely inconvenient. 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.
1 month should show some variance......

[Hexley]

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.

[pdenisowski]

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. 

That's a Unix-style timestamp that's set to all zeros.  "Unix time" is the number of seconds since midnight, January 1, 1970

[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.