Comment by m463
1 day ago
I did went GPS+ntp route.
I have a few raspberry pis on my lan that serve NTP time. (you need more than one)
Over the years I've experimented with various flavors.
Right now I have a mix:
1) a pi3 with a gps hat and a battery backup for the pi itself. It uses ntp 127.127.20.20 for gps time, and 127.127.20.28 for PPS. The SMA antenna goes to receiver at the window
2) a pi3 with USB gps on a cable going to the window
3) a pi4 same as above, but with a tiny battery backup rtc attachment
4) a pi5 with usb gps + the new RTC with an added rechargable battery backup
usually, when power goes out, a few reboot, but #1 stays up if <1hr without power. If power outlasts the pi with battery backup, the RTC battery backups take over. strangely #1 doesn't reboot when it has power, some artifact of the battery backup hat - I have to manually reset it.
I've also kind of wondered if GPS might be able to give you a time less accurately but quicker. Sometimes I look at the NMEA GPS output, and it sometimes doesn't have a position fix, but it does give out a time + week number
(this is all for no good reason, just yak shaving.)
> I've also kind of wondered if GPS might be able to give you a time less accurately but quicker. Sometimes I look at the NMEA GPS output, and it sometimes doesn't have a position fix, but it does give out a time + week number
No. Accurate time is one of the prerequisites for acquiring a position fix, and it's the one that's the easiest and fastest to obtain from the sky. Typically a receiver should be able to get time within seconds from cold start if there's enough sky visibility, and once it does it is as accurate as it gets regardless of position fix status (unless you care about sub-nanosecond precision, but you need to be able to somehow consume that anyway and you won't with a Pi).
That said, NMEA output will usually contain the time from the module's internal clock that gets synchronized with GPS time when available rather than GPS time directly. Some modules can be configured to report when they have synced their time though, and you could pay attention to the time jumping to infer it too.
>Typically a receiver should be able to get time within seconds from cold start if there's enough sky visibility, and once it does it is as accurate as it gets regardless of position fix status.
It'll be good to far better than seconds when it first gets a signal and will get more accurate (microseconds to nanoseconds) once it has a position fix because it can then compensate for the delays in the signal propagation (you can think of a gps fix as a 4d fix because it also needs to solve for time). You will probably need to use the PPS output to resolve this, though.
What I meant was that it will take seconds to get an accurate time from the sky (as accurate as it gets without specialistic techniques or equipment to consume it, and better than NTP already).
1 reply →
> if there's enough sky visibility
Which is a thing we shouldn't be requiring here. Picking up a single satellite without any position data is enough to drive a clock.
You need enough sky visibility to discern signal from a single satellite from the background noise without having accurate time and recent enough almanac already.
That 'three words' grid-hex system seems a lot cheaper and doesn't rely on time-space constraints in this light