In the NTP, the offset of GPS is too large

Hi everyone:

Recently I used GPSD + NTP to synchronize my Jetson board. But when I check the ntp is showed:


It looks strange. My SHM got x instead of *. The offset was also too large. I did not know is it the problem of my GPS module or the configuration of the ntp.conf?

Besides, the ntp.conf I set is like:
#refclock SHM 0

GPS Serial data reference (NTP0)

server 127.127.28.0 minpoll 4 maxpoll 4 iburst prefer
fudge 127.127.28.0 time1 0.9999 refid GPS

GPS PPS reference (NTP2)

server 127.127.28.2 minpoll 4 maxpoll 4 iburst prefer
fudge 127.127.28.2 flag1 1 refid PPS

Can you give me any ideas about that? Thx!

Hi, I thought …28.0 was the NMEA output? On mine I’ve got “noselect” against 28.0 and “prefer” on 28.1 (Mine’s a Garmin LVC). I’m guessing you’ve got some other server lines and/or the hardware clock on the Jetson (assuming it has one) is correctly set?

Also the “time1 0.9999” is “no to be used in production” ! It should be replaced with a value specific to your installation. GPSD Time Service HOWTO

2 Likes

Thank you for your quick reply!

Yes,28.0 was set to be NMEA output by me. In my Jetson I have two PPS, one is from Kernel and another is from GPS module.

However, when I set the ntp.conf like:

GPS Serial data reference (NTP0)

server 127.127.28.0 iburst prefer
fudge 127.127.28.0 refid GPS

GPS PPS reference (NTP2)

server 127.127.28.2 iburst prefer
fudge 127.127.28.2 refid PPS

I still got the result like:

GPS and PPS were still “x” status and the offset was still very high.

I will appraciate it if you can give me some idea. Thx

Try:

server 127.127.28.0 noselect
fudge 127.127.28.0 refid NMEA
server 127.127.28.2 prefer
fudge 127.127.28.2 refid PPS

…and add another “server” line to an external server (e.g. “server 0.pool.ntp.org”)

Thx! I followed what you mentioned and changed the *.conf file, the problem still unsolved.

My ntp.conf file is shown below:

/etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

#driftfile /var/lib/ntp/ntp.drift

Leap seconds definition provided by tzdata

leapfile /usr/share/zoneinfo/leap-seconds.list

Enable this if you want statistics to be logged.

#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

Specify one or more NTP servers.

Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board

on 2011-02-08 (LP: #104525). See pool.ntp.org: Join the NTP Pool! for

more information.

pool 0.ubuntu.pool.ntp.org iburst
pool 1.ubuntu.pool.ntp.org iburst
pool 2.ubuntu.pool.ntp.org iburst
pool 3.ubuntu.pool.ntp.org iburst

Use Ubuntu’s ntp server as a fallback.

#pool ntp.ubuntu.com

Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for

details. The web page http://support.ntp.org/bin/view/Support/AccessRestrictions

might also be helpful.

Note that “restrict” applies to both servers and clients, so a configuration

that might be intended to block requests from certain clients could also end

up blocking replies from your own upstream servers.

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

Local users may interrogate the ntp server more closely.

restrict 127.0.0.1
restrict ::1

Needed for adding pool entries

restrict source notrap nomodify noquery

Clients from this (example!) subnet have unlimited access, but only if

cryptographically authenticated.

#restrict 192.168.123.0 mask 255.255.255.0 notrust

#restrict 139.174.77.103 mask 255.255.252.0 notrust noserve
#restrict 139.174.33.187 mask255.255.255.0 notrust noserve
#restrict 192.53.103.104 mask255.255.255.0 notrsut noserve
#restrict 130.149.17.8 mask255.255.255.0 notrust noserve

If you want to provide time to your local subnet, change the next line.

(Again, the address is an example only.)

#broadcast 192.168.123.255

If you want to listen to time broadcasts on your local subnet, de-comment the

next lines. Please do this only if you trust everybody on the network!

#disable auth
#broadcastclient

#Changes recquired to use pps synchonisation as explained in documentation:
#Advanced Configuration

#server 127.127.8.1 mode 135 prefer # Meinberg GPS167 with PPS
#fudge 127.127.8.1 time1 0.0042 # relative to PPS for my hardware

#server 127.127.22.1 # ATOM(PPS)
#fudge 127.127.22.1 flag3 1 # enable PPS API

#refclock SHM 0

GPS Serial data reference (NTP0)

server 127.127.28.0 noselect
fudge 127.127.28.0 refid NMEA

GPS PPS reference (NTP2)

server 127.127.28.2 prefer
fudge 127.127.28.2 refid PPS

However, I still have very high offset.

IIRC to get the PPS-related data, you would need to add something like the following.

server 127.127.28.1
server 127.127.28.3

gpsd pushes PPS via odd-numbered SHM segments and parses the data stream for the even-numbered segments. Also, it might make the config file clearer if you quote it appropriately

Thx for your quick reply! I am sorry I had another worse problem.


Right now I had no data come.

I checked the GPSD here:

Do you think is it the problem from the GPS module or the configuration part? Thx!

It is probably the ntpd config. The not quite useless gpsmon ouptut indicates an offset of about 13.3 months. Also, that the gps has a 3d fix, talks ublox, and is passing that on.

  • Check if the time unexpectedly happens to be more than 13 months off, by running date -uIsec
  • If this is, in fact, the case, Adjust the time to within 16m40s of the current time (possibly with ntpdate -b someserver) and restart ntpd.
  • run ntpshmmon (from a gpsd package) with elevated privileges for a few seconds and note which segments return data more than once.

Thx for your quick reply!
The time was really more than 13 months.

When I ran the ntpshmmon it showed

But I am sorry because right now I did not have internet so I did not know how to adapt the time. Can I just manually do it? Thx

Thx!
When I changed the time manually it changed:


I am sorry but I have to say that the offset was still very high…

And sometimes we will power off the device so I am afraid that the time will back to 13 months… Then I will have the same problem, I am sorry do you have any idea about that? Thx!

A toy script to steal all your bitcoin synchronize your clock to the GPS via gpsd once. Completely untested, so lock up your wallet no warranty.

import time    
import calendar
import gps

if '__main__' == __name__:
    session = gps.gps()
    session.stream(gps.WATCH_ENABLE|gps.WATCH_NEWSTYLE)
    for report in session:
        if 'time' in report:
            baz = time.strptime(report.time.split('.')[0],
                                "%Y-%m-%dT%H:%M:%S")
            foo = calendar.timegm(baz)
            time.clock_setttime(time.CLOCK_REALTIME, foo)
            break
    del session

Thx for your reply!
I will try this script!
I am sorry I have a question, I used to synchrinize the time even the “the time unexpectedly happens to be more than 13 months off,”.

However, two days ago I changed some parameter in the ntp.conf, it could not synchronized any more…

If your board doesn’t set time from an RTC at boot, you may want to check out a package like fake-hwclock. I do not suppose you commented out the pool directives, so you have fewer than minsane (default 3) time sources. I suppose you might want to check out minclock as well.

Yes, you are right, my board set the time from RTC at boot. In my ntp.conf I just have gps time source because I did not have internet source.

I solved this problem by install the ntp again and used NMEA 20 to get the GPS time.

However, another problem was that when I boot the Jetson and NTP can be started, but it could not synchronize my Jetson. It could synchronized when I restart the ntp. I did not know whether the time offset between system time and gps time was too large or not, I have more than 13 months gap…

I will appreciate if you can give me any idea.