I have a Raspberry Pi that will be used for logging sensor data while not connected to the internet. Since the Raspberry Pi doesn't have an RTC, and to still get the actual time, I want to use a GPS receiver for the time. I would like to use gpsd and chrony to achieve this. I chose chrony, as it offers some advantages over ntpd that I'll be using later on.

I have installed gpsd and chrony from the Raspbian repository. My /etc/default/gpsd:


gpsd works, I can verify that with cgps (which says Status: 3D FIX).

My /etc/chrony/chrony.conf:

refclock SHM 0 offset 0.05 delay 0.5 refid SHM0 noselect
makestep 1 10
maxupdateskew 5

local stratum 1

pidfile /tmp/chronyd.pid

driftfile /var/lib/chrony/chrony.drift

keyfile /etc/chrony/chrony.keys
commandkey 1

logdir /var/log/chrony
log tracking
logchange 0.1

dumpdir /var/lib/chrony



bindcmdaddress ::1

Now I expect chrony to keep the date and time of my Raspberry Pi in sync. However, the result:

On my own pc:

$ date
Mon 12 Dec 08:58:13 CET 2016

On my Raspberry Pi:

$ date
Mon 12 Dec 16:11:39 GMT 2016

If I check on chrony, it does seem to get date from the gpsd daemon, as shown by this table that lists an ~8 hour time difference, which seems about right:

$ chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
#? SHM0                          0   4   377    22  +29618s[+29618s] +/-  250ms

I can set the time with chronyc:

$ sudo chronyc
chrony version 1.30
Copyright (C) 1997-2003, 2007, 2009-2014 Richard P. Curnow and others
chrony comes with ABSOLUTELY NO WARRANTY.  This is free software, and
you are welcome to redistribute it under certain conditions.  See the
GNU General Public License version 2 for details.

chronyc> password ****
200 OK
chronyc> settime Dec 12, 2016 12:11:39
200 OK
Clock was 15194.06 seconds fast.  Frequency change = 0.00ppm, new frequency = 12.75ppm

$ date
Mon 12 Dec 12:11:44 GMT 2016

So why isn't chronyd setting my system time by itself?

  • GPS may be a valid option, but frankly a RTC is far cheaper and simpler.
    – Milliways
    Dec 12 '16 at 8:52
  • You are right. I do intend to use the GPS itself too. :-) Dec 12 '16 at 8:57
  • Is your user's (pi) timezone set, try running tzselect and see what it suggests you insert into your ~/.profile... Also, if you were using the ntpd it would take a while to "sync up" if your system clock was badly adrift and you did not have the iburst option set on the server lines in the configuration file. I wonder whether there is a corresponding option for the software you are using that says "don't smoothly alter the time if it is badly out of whack but make a big step change to fix things instead"?
    – SlySven
    Dec 13 '16 at 23:11

My chrony.conf now looks like this, and chrony does synchronize with GPS:

driftfile /var/lib/chrony/drift

makestep 1 10
keyfile /etc/chrony/chrony.keys
commandkey 1


# set larger delay to allow the NMEA source to overlap with
# the other sources and avoid the falseticker status
refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2

I haven't taken the time to figure out why this configuration does work. There's one more problem left: if the GPS receiver is not plugged in at system startup, then chrony will not synchronize the time when the receiver is plugged in.


Remove noselect from the refclock line, otherwise that refclock will not be taken into account.

  • This is precisely correct. Adding 'noselect' does exactly what it says: it prevents the refclock from being selected by chrony. That question mark in the chronyc sources output means the GPS is "unreachable" and it's due to that 'noselect' parameter. Jan 30 '19 at 19:23

You have to use chronyc makestep in your terminal to sync your system time immediately. See the documentation for chrony:

Normally chronyd will cause the system to gradually correct any time offset, by slowing down or speeding up the clock as required. In certain situations, the system clock might be so far adrift that this slewing process would take a very long time to correct the system clock.

The makestep command can be used in this situation. There are two forms of the command. The first form has no parameters. It tells chronyd to cancel any remaining correction that was being slewed and jump the system clock by the equivalent amount, making it correct immediately.

  • 2
    Welcome to stack exchange. Please visit the help center. Just so you know, it's usually best to make your answers a little more detailed. You might have a great answer, but right now it's not detailed enough for people to actually understand it. For example, how do we use makestep? and how do we make it sync the system time "immediate"? You can edit your post to add these details. Thankyou!
    – scitronboy
    May 24 '18 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.