RS4D time synchronization

Technical Support
1

I have 6 RS4D running on the same network through the Ethernet hub and Lan line. My question is that what is the accuracy of timing among these 6 RS4D? Should I expect it to be less than 0.05 seconds difference for acceleration records?

Thank you very much for your help

1 Like
2

Should be much better once they have been running for a while.
Log into each (ssh) and run the ntpq command. Then to the ntpq> prompt, enter pe:

ntpq> pe
      remote           refid      st t when poll reach   delay   offset  jitter  
 ==============================================================================
 SHM(0)          .GPS.            0 l    -   16    0    0.000    0.000   0.000
 SHM(1)          .PPS.            0 l    -   16    0    0.000    0.000   0.000
*45.87.78.35     244.220.219.218  2 u  303 1024  377  159.768   -0.594   1.709
+ntp3.ds.network 92.21.53.217     2 u  230 1024  377  149.588   -1.461   1.893
+45.83.234.123 ( 10.1.105.2       2 u  794 1024  357  163.223    1.635   2.459
ntpq>

The remote server with the* is the current “master” NTP server. Those marked with + are potential servers that can take over should the primary fail.

The “offset” column shows the offset of the system clock to the atomic clock reference (in milli-seconds). In the case above, the R-Pi clock is running 594µS slow.

1 Like
3

hello titima,

all Shake units are guaranteed to be within one sample rate of actual time (that is, 10 msecs for 100Hz data), assuming NTP daemon is locked to a server, and has been running for a while. but since each Pi’s clock runs at slightly different rates, there is no way to guarantee that each of your units will be “off” in exactly the same way.

but there are a couple of things you can do to minimize the differences:

  1. edit the NTP configuration file /opt/ntp.conf to specify the same NTP server pool for each unit, picking one that is closest to you.
  2. you can also try specifying the same specific server for each, but this comes with the risk that if that server is not available, then you will not have a lock on an NTP server and your timing will begin to drift.

to test the timing:

  1. boot the units and let them run, connected to an NTP server, for at least a few days
  2. do a “stomp test”, where you can then compare to the millisecond any timing differences between each unit.

let us know if you have other questions,
richard

1 Like
4

Is there any way to get the time difference in micro-seconds by using GPS modules?

5

Hello AR1,

using a similar process to what Philip has described a couple of answers above, you can get the offset time difference with either NTP connection or a GPS module by logging in to the Shake via SSH (if needed, instructions are her: How to access your Raspberry Shake’s computer via ssh — Instructions on Setting Up Your Raspberry Shake) and then executing ntpq> pe from the command line.

6

hi AR1,

in the case that what you are asking is “can i get the difference down to micro-seconds by using a GPS module?”, the answer is no.

the reason for this is because there are two clocks running on the Shake itself:

  • one on the micro-chip (MCU), responsible for collecting the data off the ADC
  • and the other on the Pi

these two clocks also need to be synchronized, in addition to NTP’s synchronization with external time servers.

using a GPS module on the Shakes will definitely minimize any differences between the Shakes and their external time servers. but since each MCU runs at a slightly different rate to each other, the drift and subsequent adjustments to keep the Pi’s clock and the MCU’s clock in sync will be unique to each unit.

please let us know if you have any other questions.

regards,
richard

1 Like
7

Thank you very much for your answer. I actually didn’t know about time of MCU.

In that case can you suggest me what can I do to get the least time difference between my Raspberry shakes. I am planning to use 12 RS4D at once and need the time difference less than 10 milli-seconds.

Best Regards

8

hello,

to minimize the time difference between multiple shakes, the following:

Minimize the difference between each Shake’s NTP daemon:

  1. arrange / set up a local NTP server that all the Shakes will connect to:
    1.1. this should be on the same LAN as all the Shakes themselves
  2. connect a GPS unit to this NTP server:
    2.1. make sure that the NTP daemon on this Shake is using the GPS module as the NTP server it is using to set its time
  3. configure all Shakes to use the NTP server set up in step 1
  4. let the Shakes run for at least a week for each Shake’s NTP daemon to “settle” on the minimum adjustment necessary to keep the Shake’s clock as close to “in sync” as possible

Minimize the difference between each Shake’s MCU clock:

this is trickier since each MCU is governed by a crystal that is unique to each Shake. the only thing that can be done here is to guarantee that the external conditions of each Shake are as close to the same as possible:

  1. minimize all wind influences
  2. minimize temperature fluctuations
  3. maintain the same ambient temperature for each unit
  4. add no extra software onto the Shake computer, to guarantee that the internal temperature is minimized:
    4.1. if you don’t need to use SWARM, consider stopping the docker container rsh-data-consumer to further reduce CPU load, as a way to further minimize temperature variance over time.
    stopping this container can be done with the following command, executed after the Shake boot-up sequence is complete, (see log file /opt/log/postboot.log):
    > sudo systemctl stop rsh-data-consumer

but like i said, since the MCU crystals run completely independent from each other, there is no way to guarantee “sync-ness” between Shake beyond what is advertised: within 10Ms of the Pi’s clock time.

once these conditions are set up, if you can, measure the difference between the units; though if the units are far apart from each other, this might not be possible. perhaps it would be an idea to set up the units in a lab, on a pier, and then generate a man-made “event”. any observed time differences between units placed close to each other could be regarded as accurate.

cheers, hope this helps,
richard

1 Like
9

Thank you very much for the information.

1 Like