Comment by seba_dos1 | Hacker News Reader

Comment by seba_dos1 | Hacker News Reader

Parent Full thread

> 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).

For a cold start, you have to wait 30 seconds for the whole ephemeris data to be broadcast unless you have another data path getting you A-GPS data. (it's literally just broadcast that slowly)

You can still get pretty accurate time (microseconds) with the GPS almanac which is broadcast over ~15 minutes and only updated every few months.

Doing really fast time acquisition isn't a hard problem but it's a hardware problem, you can't really change how an ordinary GPS receiver operates, you have to have a custom receiver.

I once researched how accurate GPS time is, and the answer is it's within 40 ns. Good luck finding a way to transmit that to your CPU that doesn't add a much larger delay.

I don't think delays are a problem for accuracy, as long as they're predictable.

I kind of think the ntp driver could handle this in an elegant way.

have a driver at 127.127.20.20 -> nmea time

make it normal stratum ntp, like stratum 1 or 2

doesn't give out the time unless there is a position fix (normal behavior)

and make another driver 127.127.20.99 -> nmea time without position fix

at the start, there is no time given at all

then you might get a time without a position fix

then you get a time with a position fix

then you might lose the position fix, but still give out a time.

make it a stratum 14 ntp server

> 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.

That 'three words' grid-hex system seems a lot cheaper and doesn't rely on time-space constraints in this light

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.

Reply on news.ycombinator.com