Thanks,
On Mon, Mar 1, 2021 at 10:40
AM Xavier Ruiz <xavier.ruiz@earthrover.farm> wrote:
Thanks Greg and Gary for your quick responses. I really appreciate it.
So I found this ROS package https://github.com/vooon/ntpd_driver that listens to the time of a ROS message (that will be published by the SBP driver) and sends it to ntpd/chrony via SHM. I think this is exactly what I needed and should work. I'll keep you posted.
I think I will use chrony rather than ntpd since it seems to be more accurate. Also, do I need gpsd to create a shm for the pps signal? Or chrony can read it directly?
Thanks so much for the help.
On Fri, Feb 26, 2021 at 7:19 PM Gary E. Miller <gem@rellim.com> wrote:
Yo Xavier!
On Fri, 26 Feb 2021 11:22:07 +0100
Xavier Ruiz <xavier.ruiz@earthrover.farm> wrote:
> I want to sync my arm host clock with a GPS clock using your package
> gpsd but we have some differences in the configuration.
UNIX is choice.
> Typical implementations of that synchronization use your package gpsd
> to read NMEA messages through serial and get the absolute time. This
> absolute time together with a PPS signal is used to sync the clocks
> with chrony or ntpd.
No just NMEA messages, any message from the GNSS recevier that specifies
the correct time will work.
> In my case, I have a Piksi Multi RTK GNSS module
> https://www.swiftnav.com/piksi-multi
My condolences. I found the doc for that:
https://support.swiftnav.com/support/home
Finally a worse serial protocol than TSIP. I don't see how gpsd can
ever support that device while allowing auto-detection of receiver
type. Even a dedicated decoder will have problems with that mess.
> that I am using in Linux 18.04 with ROS.
No such thing a "Linux 18", the hightest kernel is now only 5.12.
I assume you mean ROS based on Ubuntu 18.04.
> This device is manufactured by Swift Navigation and they
> have their own protocol called SBP (Swift Navigation Binary Protocol)
> instead of using NMEA.
Yuck.
> The module also provides a PPS signal. We have
> a Nvidia Jetson Xavier as a host Arm computer. We connect the GPS
> with the Nvidia through ethernet. We have a way to extract the
> absolute time of the SBO message using a ROS (Robotics Operating
> System) wrapper of the Piksi GPS
> https://github.com/ethz-asl/ethz_piksi_ros.
Then you are almost done with getting time to ntpd.
> ROS is basically a
> robotics middleware that runs on Linux.
Not really middle ware, just another distro.
> My question is if I could use
> this absolute time from ROS in the gpsd pkg rather than from the
> serial NMEA msg in order to sync my clocks.
Not without a lot of work. SBD is terrible. Writing a gpsd driver
is a non-trivial exercise even with a good protocol. Supporting SBD
would be a makor PITA.
Much easier to just use a better receiver.
If you must use SBD, then use the decoder you already have, and
have it write directly to the ntpd SHM. With a bit of cut/paste
from the gpsd source that would only be a dozen new lines of code.
Look in this file for a start:
gpsd/ntpshmwrite.c
Then have ntpd read the PPS directly from the /dev/pps0
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin