GPS Time Rollover Failures Keep Happening, But They’re Almost Done | Hacker News Reader

GPS Time Rollover Failures Keep Happening, But They’re Almost Done

blog.fosketts.net

132 pointssfoskett43 comments

> GPS is being modernized to use a 13-bit Week Number

If you want to dig into the details, this is one of the specification documents of the GPS signal [1].

"Figure 40-1. Data Format (sheet 1 of 11)" displays the layout of the legacy messages LNAV, while "Figure 30-6.Message Type 33 -Clock & UTC" displays the layout of the new CNAV messages. You can see that WN in the old message has 10 bits only, while WN_{ot} has 13 bits in the new message.

13 bits are a bit short IMO. It's 157 years instead of 20. Just puts the rollover into that uncanny valley where you forget about it too easily. Instead, IMO one could have extended it to 32 bits directly, which would be enough for 82 million years. In the CNAV messages, there are 53 bits of reserved space around, so it's not like that bits are super scarce, and if they are you could take from the reserved space.

[1]: https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf

If we're still using this protocol 158 years on we've got bigger fish to fry.

It's accurate to within a meter and works perfectly fine today, without us having to spend billions more on a replacement that could surely be spent on those pesky problems like healthcare or education.

Why wouldn't we keep using it for hundreds of years to come?

Why stop at a meter?

You can get cm level accuracy with RTK: https://en.wikipedia.org/wiki/Real-time_kinematic

This looks amazing. Any idea if there are consumer level CPGPS devices?

The error beyond this level is due to local ionospheric conditions rather than the protocol. Corrections can be transmitted to interested receivers, WAAS is an example of such a system.

cm level accuracy is available with RTK. It works by comparing GPS signals from a known nearby location with that of a mobile receiver, providing what amounts to especially good correction. It works fine and you can get started at home for <$100.

A new protocol that does better than what we have right now will take some major breakthroughs.

Any recommendations on what hardware or project should I look for to "start at home"? Sounds interesting...

http://rtkexplorer.com/how-to/posts-getting-started/

Kessler syndrome.

I had to look it up... https://en.m.wikipedia.org/wiki/Kessler_syndrome

The Kessler syndrome (also called the Kessler effect,[1][2] collisional cascading or ablation cascade), proposed by the NASA scientist Donald J. Kessler in 1978, is a scenario in which the density of objects in low Earth orbit (LEO) is high enough that collisions between objects could cause a cascade where each collision generates space debris that increases the likelihood of further collisions.

> I had to look it up...

You're a disappointment as a nerd. As penance, go watch Planetes.

He's one of today's lucky 10000. No insults please, Tanabe-san would be disappointed.

You have to replace the satellites periodically anyway so you are already spending lots of money.

Sure, so spend just enough to replace them with same, rather than extra billions to develop something new.

IDK because European ones already work down to the centimeter...

I've just sailed into 2-3 meter wide canal after dark here in NZ. Used my previous track from earlier today. 1 meter accuracy is not precise enough to do it safely - had to look for fairly poorly lit nav marks and rocks.

I wouldn't trust GPS down to sub-meter precision even if the spec technically supported it. I often travel a route, then turn around and retrace the exact same route, only to see the GPX data indicate fairly large variances. LEO is very large and the atmosphere is not uniform.

Or you could use lights and your eyes.. Blindly trusting anything like GPS to guide you through risky situations like that sounds like a good way to ruin your boat.

I would still do, but you use GPS as a confirmation rather than source of truth.

> Or you could use lights and your eyes..

Assuming there's no thick fog.

Though radar, depending on its resolution (which is determined by array/beam width), is also handy.

Why not go in the other direction? Make the rollover happen every few years as just a normal part of operation. It means it'll be a well tested code path.

Are there physical reason why that wouldn't work?

It would preclude the existence of long-running GPS devices. I'm pretty sure that, in addition to devices that never have tested the rollover scenario, there are actually older devices produced in 2000s and still running today.

Mention of both Y2K and 2038 in that article made me realize that we are now closer to the latter than the former.

Yep, and Y2K was mostly in your data center. 2038 is mostly in your walls.

"Multiple Boeing 787s in China experienced GPS 20 years rollover issue. Some aircrafts have to be grounded waiting for an update." https://twitter.com/ChinaAvReview/status/1114802018919411712

Are software issues as common to other manufacturers?

You guys remember a couple of days ago people were discussing this eventuality and consensus was "surely they aren't pulling timing information from GPS, unfiltered! It's an aircraft manufacturer we are talking about, they know what they are doing!" -- Well, no, they don't. It's almost like you could begin to see a pattern here.

Article is not correct: not every device on the planet will roll over.

Many GPS chipsets, such as many uBlox devices, program an offset such as the date of device firmware compilation. This means that the rollover will in fact occur decades out from when users are expecting. The way to discover the real rollover date for ublox devices is to interrogate them with the ublox software to find the relevant message and add 20 years on top. For old ublox devices this field can actually be modified by the user to effectively reset the countdown. For other brands it could be a lot more difficult, though manufacturers docs should cover it.

https://portal.u-blox.com/s/question/0D52p00008HKDTlCAP/gps-...

A properly programmed device should have no issue. A device only needs to know the date to within 10 years so that it can interpret the week number correctly. So if the device runs its own clock that it synchronizes to GPS, it should keep working indefinitely as long as that clock is running. Even if it doesn't run a clock while powered off, it could store the clock to non-volatile memory occasionally, and it would keep working correctly as long as it isn't powered off for more than 10 years.

Find me these “properly programmed devices”! This is the core of the issue: bad assumptions and poor QA let bugs like this have an outsized impact. It’s our fault, folks.

I've been raising awareness in outdoor recreation groups about this. Many people rely on GPS for rescue and navigation in the backcountry, and it's likely some will see a software failure this weekend.

Navigation is not affected. (Unless there is some other bug that bleeds over from the rollover issue)

Not sure why you were downvoted; this is my understanding also. Could someone with deeper GPS knowledge chime in?

If you read my post, it ends with "...and it's likely some will see a software failure this weekend" - of course a properly-coded GPS device will be fine but the likelihood of the many thousands of different types of GPS devices out there all gracefully handling an event that happens once every two decades is basically zero.

Satelite constellation (position in the sky) is date stamped right? If the internal clock date doesn't match the received the updates may be ignored.

The satellite position updates use essentially the same time format as the rest of GPS, as I understand it. So the problem comes when some GPS receivers try and use the latest information but base their calculations on an erroneous belief it's now 1024 weeks into the past, causing them to fail to find satellites.

If you're curious about the history of GPS, there's a fantastic write up here:

- https://www.gpsworld.com/origins-gps-part-1/

- https://www.gpsworld.com/origins-gps-part-2-fighting-survive...

There's also a documentary on Amazon Prime:

- https://www.amazon.com/Lonely-Halls-Meeting-GPS-Documentary/...

A bit off topic, but fyi Stephen, the mailhide widget at the bottom of your "About" page seems to be broken. I browsed your site beyond the article you submitted and wanted to mention that you may be able to use Ctrl-[ as a substitute for the missing Escape key on your iPad pro. I do that a lot on normal keyboards just to avoid the pivot movement and stay on the home row, as it's just a simple pinky stretch (assuming Caps Lock as an additional Control), and also map Ctrl-] to be the tmux escape for the same reason.

Thank you! I appreciate both tips!

What time does the rollover occur? Is it based on UTC, or what?

I assume UT1: https://www.oc.nps.edu/oc2902w/gps/timsys.html https://en.wikipedia.org/wiki/Universal_Time#Versions

Which is roughly UTC, give or take multiple seconds.

GPS atomic time rolled over approximately midnight UTC this Sunday morning, but ignoring leap seconds. GPS is 18 seconds ahead of UTC and 19 seconds behind atomic TAI. http://leapsecond.com/java/gpsclock.htm

Awesome article, thank you for writing it.

This is very off-topic, but how do you like the 2008 S Class? Are there reviews of it from a 2019 perspective anywhere?

Reply on news.ycombinator.com