Yea I always liked the way Spanner solved this. Let's not bother with any of the distributed system theory and just use that Google money to build in to the system extremely precise clocks :-D.
(Obv I know it's more complicated than that, but where else can you be reductionist if not the internet)
This[^1] Barbara Liskov's paper gives me an impression the distributed systems people would be glad if they didn't have to bother with all the theory :)
It probably won't be 100 ns accurate in motion, but still quite accurate. Practically speaking you won't get better than ~1 s unless you connect the PPS pin to an interrupt or PLL.
With a bare minimum implementation you should be able to get the GPS time from the NMEA strings. You just need to guarantee you'll have GPS lock at least intermittently, which is probably true for a fleet of monitored cars in nearly all situations.
Urban canyons aside, the GNSS receiver itself should almost always have better than 100 ns accuracy, even when moving. After all, 100 ns at the speed of light is ~30 meters. At 200 ns you're on the wrong city block.
As for bringing that into a computer, I'm having a hard time imagining a hardware setup where a software PLL won't give you millisecond-level accuracy (assuming you have an internal clock with at least that much precision). 1 second accuracy implies just using the timestamp from the last NEMA string with no further processing...
Yes I am referring to NMEA string usage because that's as good as you'll get if the PPS output is not connected. You don't strictly need a hardware disciplined oscillator solution, which is why I mentioned connecting to an interrupt pin. This has worked pretty well for me when making raspberry pis into stratum 0 NTP servers.
> Yes I am referring to NMEA string usage because that's as good as you'll get if the PPS output is not connected.
1. That's only true with a super, super naive approach. You can easily estimate the average latency as part of your prototyping, and subtract that (while "live") from when you receive the full NEMA string. That will knock down the (in)accuracy by at least an order of magnitude, probably two, depending on latency variance. NEMA messages are (almost[1]) always sent synchronously with the PPS.
2. Again I'm having trouble imagining this naive hardware setup where you don't have a better timestamp than 1 second. NEMA usually comes over a UART, so just timestamping the first byte of the NEMA string will give you ~millisecond accuracy. Even a cheap USB 1.1 UART dongle that only polls at 125Hz should give you ~10 millisecond accuracy. As above, you can estimate average latency during development to improve accuracy during usage.
You'll need to do a little bit of software filtering to remove outliers, of course, but that requires no extra hardware.
The point is: The technical bar to getting 10ms accuracy with no special hardware and no PPS is basically zero.
[1] I'm hedging with almost, but I've never seen a counterexample.
As someone who's worked on some very similar problems, fix it properly on the vehicle side. Lamport/vector clocks are not a silver bullet here. They can be very difficult for end users to handle properly, and don't necessarily scale well in large fleets with unbounded drift. The vehicle network has a synchronized notion of time already. If the vehicles were designed properly, that's hooked into GNSS already. Even if they aren't (e.g. because it would impose unacceptably high uptime requirements), you have another system to bound drift already because various systems are required to stay within a small margin of "true" time (certificate validation comes to mind).
This is a fundamental system for the company, so it's worth cracking a few heads over the issue.
