gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPSD Time Service HOWTO


From: Xavier Ruiz
Subject: Re: GPSD Time Service HOWTO
Date: Mon, 1 Mar 2021 15:58:46 +0100

Also, ntpd/chrony uses UTC or GPS time (GPST)? Can't seem to find the answer.

Thanks,

Xavier Ruiz Vilda
Robotics Engineer at Earth Rover
+34 623405772



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.

Xavier Ruiz Vilda
Robotics Engineer at Earth Rover
+34 623405772



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]