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