I’m working with a Reach M+ plus a set of sensors handled by a nvidia Jetson TX2 computer and I require to synchronize the clock of the jetson with the satellite-converged clock of the M+.
Quite similarly to this closed thread:
As far I could understand the PPS is still not currently exposed through the USB. I double-checked this using the gpsmon tool available in the gpsd toolset and effectively PPS is missing, and without PPS the gpsd tool doesn’t provide enough capabilities to synchronize clocks.
Working directly with the hardware and build a special connector/write an interruptor handler for the PPS (as PPS output on the Reach suggests) is out-of-scope of the project, and we are trying to come with a workaround.
We though about installing a ntp server on the Reach M+ linux (chronyc for example) and synchronize clocks at OS-level setting a service-client between M+ and the jetson. This way, ideally, the M+ would set his clock based on the GPS and share it to the jetson through ntp.
Is this possible? would a ntp server interfere with the time setting procedures/scripts already present on the M+ system?
Neither the jetson nor the M+ have internet connection, so the ntp server would be installed on the M+ in order to provide time synchronization downwards only (from M+ to the jetson).
I might have to edit ntpd config files (ntp.conf / chrony.conf) and comment out every external server in order to prevent it to try reaching online ntp servers.
I’m open to advises regarding configuring an ntp server in “only downwards” mode, or maybe some easier way to achieve this time sync.
The M+ OS system actively reads the NMEA messages of the GPS chip and updates his time (I checked) and this is quite accurate i think.
My main concerns are that installing a ntp server may interfere with the ability of the M+ OS to sync with the GPS chip, and of course adding cpu load to the M+.
Do you mean the ntp server would get its time from the M+? Are you writing custom firmware for the M+?
How would this be an issue, If you are only reading the time from the M+?. NMEA output is one way, even if the other end is unable to receive it it will still just keep sending. like a radio station.
Yes, I want a ntp daemon installed on the M+ that takes the OS time and shares it to the Jetson. Not really a custom firmware, the M+ has a linux OS that you can just connect with ssh. I pretend to connect using ssh, looking for a way to reach internet connection in the lab and install a ntp package on the M+. I don’t really have it with me until later this week, if I’m not able to install the package using the package manager of the linux I may try to do it copying the package directly (using scp maybe).
Well I did a quick search and inspection of scripts running on the M+ OS and seems that there is a python script named time_sync (or similar) that draws the time from the GPS NMEA message and sets it to the OS linux. But that’s just me messing around on the ssh prompt on things that are not really documented, I don’t really know if that’s all to it and I’m afraid that may brake some internal time sync procedure of the M+.
This entails a workaround idea in order to sync the jetson with the M+ time, if the M+ would share the PPS through the USB this would be much easier and doable with tools specially prepared for that.
Well your project seems complicated, I would leave M+ as is and do everything on a separate micro controller. If a firmware update comes for the M+ it may overwrite all of your hard work.
Reading variables never gets you into issues, just writing to them breaks things.
As @PotatoFarmer said, the next firmware update will delete scripts you write on Reach M+. Since firmware updates are needed to support new features, I’d recommend checking other ways of dealing with the clock sync.
Reach M+ provides PPS output on C1 and C2 ports. Does it work for you?
