3 ms·
> I am guessing when GPS was originally designed the designers didn’t anticipate that the 10 but counter would be an issue and/or proliferation of these consume
by labcomputer 2y ago
> I am guessing when GPS was originally designed the designers didn’t anticipate that the 10 but counter would be an issue and/or proliferation of these consumer devices.
Or maybe they just assumed that some other source of information could disambiguate the week number.
For example:
1. The week rollover interval is almost co-prime with the number of weeks per year. If the user is given a way to override just the current day-of-month, the full current date and time can probably be disambiguated to within a ~255-year window. If the user is given a way to override just the current year, the current date and time can be exactly calculated.
2. A receiver with non-volatile storage can keep track of the last week number it has seen. If the week number at the next power-up is less than the previous value, it is likely that at least one week rollover has occurred. If the receiver is powered on at least once every few years, this would be a fairly reliable way to count the number of rollovers.
3. (NV storage again) Leap seconds are added at a rate of roughly 10 per 1024 weeks. If the number of leap seconds suddenly jumps, that may be a sign that a large amount of time has passed. This might be used to augment #2 to estimate the number of rollovers that have occurred. There are some reliability concerns here, as the earth seems to be slowing somewhat.
4. (NV storage again) GPS satellites do not (as far as I know) really have enough fuel to change which orbital plane (of the ~6) they are in. If the set of PRN-plane assignments do not match the assignments from last power-up, it is likely that large amount of time has passed (because it means that some satellites were retired and others launched).
All in all, it's a relatively minor problem. Most receivers just hard-code a minimum date in software and assume that they are within 20 years of that. Most of the time, nobody cares.
- Animats 2y agoIt's possible to brick some GPS units by sending them faked signals that advance the time until the next rollover. Then they're permanently stuck in the next epoch, far in the future.
- terinjokes 2y agoPermanently, as in they're blowing efuses? Or just until some memory is cleared? Do you have more details on this?
- myself248 2y agoAs in, they don't provide a user-facing way to clear the memory. The Arbiter suffers from this: https://users.ece.cmu.edu/~dbrumley/pdf/Nighswander%20et%20al._2012_GPS%20software%20attacks.pdf https://users.ece.cmu.edu/~dbrumley/pdf/Nighswander%20et%20a... And someone went to silly lengths to fix a Furuno: https://tomverbeure.github.io/2024/08/18/Fixing-the-Symmetricom-S200-GPS-Week-Number-Rollover-Problem.html https://tomverbeure.github.io/2024/08/18/Fixing-the-Symmetri... Fun trivia, the Unix epoch rolls over in January of 2038, but the next GPS WNRO happens in Novermber of that same year. So some systems, if you hiccup the epoch past that, may immediately suffer Y2038 problems.
- terinjokes 2y agoInteresting, thanks for the links, I'll give them a read. Since with the GPS 95 at worse I can pull the battery cell and clear the memory, I should try to see if it's Y2038 compatible (I'm guessing not).