Just out of curiosity, what significant benefits do you get from the
RTC? I have NTP running on mine, and the only anomaly I notice is
this sort of thing in the `last` output:
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
although `uptime` is correct and I can't find any '1970' or 'Jan' in
any of the greppable log files.
so ladies, fish, and gentlemen,
here's my angled dream
I understand why that's the magic reset date (which is why I was
grepping for "Jan" as well as "1970") --- I was just wondering about
what kind of situation needs the external clock so the time is
accurate *before* NTP starts working.
I heard that Hans Christian Andersen lifted the title for "The Little
Mermaid" off a Red Lobster Menu. ---Bucky Katt
It rather depends on how long might elapse before reaching a time
server, if there's any danger of that being a long time then a RTC is very
helpful, if you're sure of a time server immediately after boot then it's
pretty much useless.
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
Don't forget that an old GPS unit, provided it has serial NMEA0183 output
which many of them had, can be used by ntpd as a primary time reference.
These can be connected to an RPI via a USB-serial adapter. There is a
reference driver for ntpd that allows it to accept an NMEA0183 primary
My home server is a syslog server for other stuff - like the VDSL router
and Wireless access points - so I like it to have a reasonably good time
as soon into boot as possible, even if it has only booted a handfull of
times in the last couple of years. Also if the house power goes, then
when it comes back, the server will come back well before the router
gets DSL sync and an internet connection - and it's time will be good
until internet connectivity is resumed.
Several years ago we had several incidents where power would go (all our
street) for 30 secs or so and then return. It turned out there was
something dodgy under a road - and an especially heavy lorry in the
wrong part of the road would cause problems. The road was up for quite a
while as they fixed it.
How long with a GPS unit take to get a time fix from cold, out of interest?
The OP's situation sounds like one where a RTC would be quicker than a cold
GPS, although maybe there's a way to get a time out of GPS before it has
seen enough satellites for a position fix.
(and can you do A-GPS by configuring the lat/long of your stationary Pi?)
I think it'll know the time as soon as it receives a single frame (every
30 seconds) that's the number of 1.5 second "ticks" into the current
week, weeks start at midnight.
But it might need to receive the full almanac (every 12.5 minutes) to
know the date offset to UTC, because the week number rolls around every
That depends on the make, model, how good its view of the sky is and how
long since it last had a fix. The older trekking units, e.g. Garmin GPS
II, generally took 1-2 minutes to get a fix outdoors and didn't work
indoors. The slightly more recent GPS-35, a puck with no controls or
screen, was quite a lot faster and IIRC would get a fix if left on a
south-facing window sill in the UK.
How long since last the last time a GPS had a fix matters because each
receiver has a copy of the ephemeris, which contains orbital parameters
and time adjustments for all the satellites in the GPS constellation. If
this is out of date, the receiver can't get a fix until it has downloaded
a fresh ephemeris. GPS satellites broadcast their ID and time every
second and a new ephemeris rather less frequently. To get a fix the
receiver needs to know the ID and time at each satellite. It looks up
orbital details for the satellites it can hear in the ephemeris and from
this and the broadcast time at each satellite it knows where it was when
that satellite sent its last time message. This lets it work out times of
flight for the signals and, from that, its distance from the satellite.
Then it combines information about all the satellites to work out exactly
where it is and what the exact time is at its location.
I'm certain thats true, particularly with an old GPS receiver.
Another caveat: I have a pair of old Garmin GPS II+ units, used
originally for model aircraft tracking and later for full-size glider
navigation, bought in 2001 and 2004. They still work because they have
always had good AA cells in them. That's important for early GPS units,
which used battery-backed RAM to store waypoints and, most importantly,
the GPS epoch counter. The old Garmins used a soldered-in battery (2032
or similar) to keep the RAM active while you changed the AA cells, but if
left for any time with AA cells removed, the coin cell will die and the
RAM will be wiped and the epoch counter will be zeroed. However, none of
these units have any ability to configure the epoch, so once that
happens, the GPS receiver is bricked. My pair still work because having
good batteries in them has kept the coin cell from being used except for
a minute every 2 years or so when the AA cells get changed.
More recent receivers use non-volatile memory: these should still be
usable but I don't know which specific makes or models these would be.
I also have a pair of PNAs (a Binatone and a Medion S3747) which run on
Li-ion batteries and store vital data in non-volatile memory, both are
used to run LK8000, a glider navigation and flight logging app. The Medion
normally comes up from cold in about a minute. The Binatone was bought in
around 2008 and the Medion in 2014.
However, when I suggested using a GPS as time source I was thinking that
in at least some cases it may be better to treat the GPS receiver as its
prime time source, particularly if the RPi isn't more or less constantly
online to an internet time source.
Probably not - seeing that the GPS still needs to have current ephemeris
data, which it picks up when a satellite it can see broadcasts it.
I'm only suggesting that using an old trekking or puck GPS is a good idea
for somebody who already has one lurking, unused in a drawer.
Otherwise the obvious way to do it is to buy one of the RPi GPS expansion
cards. Most of them seem to use uBlox GPS receivers, which appear to be
You shouldn't see any 1970's on reboot. Raspian saves the current value
of the clock every 15 minutes or so. When you reboot it uses this saved
time until it gets updated from ntp.
You may notice the syslog doing this
1720 Some stuff happening # the last log entry before rebooting
1715 Rebooting # Reboot using last saved time
1715 Getting RTC
1722 More startup # The time has been updated
1723 Finished rebooting
The jumping of the time backwards and forwards can be a little
confusing, but it is possible to work out what is happening.
The advantage of a real time clock chip is this is avoided and the
reboot time will be more accurate.
I wouldn't use a GPS clock for reboot, as may take too long to give a
reading, it is more suited to keeping accurate time once the machine is
up and running - as long as it has a good view of the sky.
It does not matter - time and coordinates are members of the same
equation group which has to be solved to get any of the members.
The ephemerides data comes pretty slowly, it will take several minutes
to get them if the receiver is out of date.
A decent net connection and NTP will get the time much faster.
(Not that I need something like this, but it's interesting.)
I don't think an old GPS unit would be able to get a signal in my
"network cupboard", which is a shelf in the back of a wardrobe under
the stairs from the 1st to 2nd floors, & not on an outside wall.
Let me tell you what I think of bicycling. I think it has done more to
emancipate women than anything else in the world. I stand and rejoice
Sure, but I don't think that affects a GPS receiver's startup process: it
still needs the almanac data to determine the exact time: its location
matters to it when correcting for signal travel time from satellite to
receiver and, if any satellite clocks have been reset recently, what
their UTC offset is now. If the receiver hasn't been run for a while it
will need an updated almanac and, as Andy said, it may have to wait up to
12.5 minutes for this to be retransmitted.
If a GPS receiver is designed to be a time source, it will emit NMEA-0183
ZDA messages which only contain UTC date/time information, but equally
there's no reason why the time recipient shouldn't accept NMEA-0183
message types RMC, GGA or GNS and discard everything except the time
field because all these messages contain a UTC time stamp accurate to 10
The older ones often don't work in a house, and sometimes not in a forest
either, let alone under a tin roof. Modern receivers are much more
sensitive. I've just fired two GPS receivers up to prove this point:
- My old (1990) Garmin GPS2+ had no signal at all in the sill of a South-
facing window and had problems outside it as well, due mainly to the sky
view being restricted by both the house behind me and (bare) trees on the
other three sides. It did eventually find two satellites, but never
determined where it was.
- My more recent (2014) Medion S3747 PNA got enough signal on the window
sill to set its clock, but couldn't see enough satellites to determine
its position. However, when it was taken outside to the same point as the
GPS2+ it was able to determine its location and altitude after around 2