Setting system time and data frequently (offline, with LCM)

Hi,

I am doing a project using both beaglebone and raspberry pi. Now only the pi has internet connection and I have to sync their time. Currently I can send the pi’s time to beaglebone green every second, but I don’t know how to use this data to set the system time on Beaglebone. I plan to write a shell script so it can be running all the time from boot. Anyone knows how to do that? Thanks.

Thanks & Regards

"Information... We want... Information"

  How is the BBG connected to the R-Pi for this transfer? If the R-Pi is
sending time data, there has to be something on the BBG that is reading it.

  It would probably be easier to have the BBG /ask/ the R-Pi for the
time, and that could be done using a cron job on the BBG. Of course, that
means now the R-Pi has to have running process to accept the requests...
  
  It all comes down to how the two devices are communicating. If the BBG
is connected to the R-Pi via USB (hope you are using an external power
supply on the BBG -- don't think an R-Pi USB can provide the power draw)
you might just need to configure the R-Pi as a gateway, and let the BBG NTP
(or whatever recent Debian/systemd sets up) do normal time sync through the
R-Pi's network connection (or run a tier 3 NTP server on the R-Pi and let
the BBG time sync to it).

Yeah, GGB has its own power supply. And I am connecting raspberry pi and BBG through ethernet. For transmitting the message, it is done by LCM.
I think LCM is faster because at least there’s no password issue and I hope to let the BBG time sync quite often(like every 1 min), but not too often because that would be unnecessary.

What I now have is a program(c or python) that can get the time sending by a raspberry pi. Now I plan to read the output and set the time using think command: date -s “2 OCT 2006 18:00:00”
in the shell script. But I don’t know how to do that.

在 2020年7月2日星期四 UTC-4上午11:03:20,Dennis Bieber写道:

Setup NTP server on the pi.
The BBB should have the ntpd (NTP daemon) already setup. Change the ntp configuration to point to the IP of your pi.
Let ntp maintain the time by itself no need for cron. Any scripts or custom implementation will had a delay which will increase the time drift between your systems.

To maintain the clock between reboots or when the pi is unavailable, purchase an i2c real time clock like the DS1307 and use ntp to keep the time sync’ed.

I hope this helps.

Thanks. Fulfilling this by configuring ntp.conf sounds quite diable. I followed some instructions online but failed. Here is what in BBG’s ntp.conf and Pi’s ntp.conf. I use 192.168.0.102 to ssh into pi and 192.168.4.2 to ssh into BBG.

Part of ntp.conf in BBG:

pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will

pick a different set every time it starts up. Please consider joining the

pool: http://www.pool.ntp.org/join.html

server 192.168.0.102

Part of ntp.conf in Pi:

By default, exchange time with everybody, but don’t allow configuration.

restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict 192.168.4.0 mask 255.255.255.0 nomodify notrap

And here is the result for ntpq -p on BBG. I don’t know how to check if BBG is really trying to make time sync.

debian@beaglebone:~$ sudo ntpq -p
remote refid st t when poll reach delay offset jitter

It may depend on how your system is configured but look in:

/var/log/messages and /var/log/syslog

The “app” (daemon) responsible to sync is running as ntpd, every reboot will force a sync with your pi.

So the obvious way is to check the date after reboot. If it is correct, it means it sync’ed fine.

You can also check the journal with journalctl -u ntpd -n500 and look through the log.

The ntp query (ntpq) shows that your BBG is aware of the pi time server.

<chopped>

reach 0 shows that your not reaching your ntp server, or it's refusing connections or...

It will (reach field) get to 377 if all is well. This may also fail anyway as *most* ntp clients want more than one server. Typically at least 3, to ensure that you get a good chimer.

Mike