There’s a bug about to hit older GPS hardware that has echos of Y2K. Those old enough to have experienced the transition from the 1990s to the 2000s will no doubt recall the dreaded “Year 2000 Bug” that was supposed to spell the doom of civilization. Thanks to short-sighted software engineering that only recorded two digits for year, we were told that date calculations would fail en masse in software that ran everything from the power grid to digital watches. Massive remediation efforts were undertaken, companies rehired programmers whose outdated skills were suddenly back in demand, and in the end, pretty much nothing actually happened.
Yet another epoch is upon us, far less well-known but potentially deeper and more insidious. On Saturday April 6, 2019 — that’s tomorrow — GPS receivers may suffer from software issues due to rollover of their time counters. This could result in anything from minor inconvenience to major confusion, with an outside chance of chaos. Some alarmists are even stating that they won’t fly this weekend, for fear of the consequences.
So what are the real potential consequences, and what’s the problem with GPS in the first place? Unsurprisingly, it all boils down to basic math.
Epoch Story
GPS satellites are essentially super-accurate clocks in orbit, transmitting navigation messages at a screaming 50 bits per second. The navigation messages include a timestamp and information about the orbit of each satellite, which GPS receivers below can use to determine their location. Each full navigation message is 37.5 kilobits long, meaning that a full page of GPS data takes 12.5 minutes to transmit.
The navigation message is broken down into frames of 1500 bits, each divided into five 300-bit subframes that take 6 seconds each to transmit. Each 300-bit subframe is further divided into ten 30-bit words. The first 30-bit word of each subframe is a telemetry word, encoding certain information about the health of the satellite. The telemetry word is followed by a 30-bit time of week (TOW) word, which encodes the week number and time within that week. GPS time reckoning is a bit weird due to some gymnastics needed to encode the number of seconds in a week (604,800) into the 17 bits available in the TOW word after taking out 13 bits for parity and other uses. The TOW word actually represents the number of 1.5 second periods in a week, which is further divided by four, since there are four 1.5 second periods in the six seconds it takes each subframe to be transmitted.
Despite appearances, the complexity of time encoding on the space side of the GPS system is not the cause of the looming problem, although it is related. The problem is with how the time data is interpreted by GPS receivers, and like the erstwhile Y2K bug, comes back to decisions made by software engineers. Of the 17 bits devoted to encoding the TOW word, the week counter uses 10 bits. That means the satellites can count up to 1024 weeks, or about 19 years and 8 months, before the counter rolls over to zero. Right now, the week counter is all ones: 1111111111. On Saturday April 6, the week counter will be incremented, rolling back to 0000000000. Therein lies the problem.
Been Here, Done This
Now, this is not the first time this has happened. The GPS system has been operating in various forms since the late 1970s, strictly for military use at first, then opened up for the civilian market in 1983, partially as a response to the shootdown of Korean Airlines flight 007 by Soviet air defenses which claimed that the airline was a spy plane. The beginning of the GPS epoch was set to January 6, 1980, with time reckoned from that point forward. That means the first rollover occurred on August 21, 1999 – 1024 weeks after the clocks were started.
The astute reader will note that the world did not come to an end the last time the GPS week counter rolled over, so surely this time will be a non-event as well. Probably, but there are a couple of complicating factors this time around. First, in 1999 there were very, very few GPS receivers in civilian hands. While Magellan introduced the first handheld GPS receiver, the Magellan NAV 1000, in 1989, and some mobile phones were equipped with receivers as early as 1999, any problems with the nascent system when the date flipped the first time were just not that big of a deal.
The year after the first rollover, the US Department of Defense made the decision to broadcast navigation messages with full positional accuracy enabled. For the first time, everyone would be able to get centimeter accuracy with the right equipment, and the GPS industry took off. By 2001, dashboard navigators by Garmin and Tom Tom became the killer app for GPS. Cell phones would morph into smartphones shortly thereafter, and would begin to incorporate GPS receivers and navigation software. In 2017 the worldwide market for GPS receivers was estimated at almost $38 billion, so there are a lot of GPS receivers out there, far more than there were back in 1999.
Back to the Future?
So what’s likely to happen to your GPS devices? Probably nothing. GPS manufacturers have known about this rollover for a while, and pretty much any receiver made in the last decade is already capable of dealing with the rollover. Older devices, like my ancient Garmin eTrex Legend that was once the source of a lot of family geocaching fun back in 2003 but has been sitting in a drawer for years, might have a meltdown on Saturday.
How the end of the second GPS epoch will manifest on specific devices is completely dependent on how the manufacturer coded the thing. Some will interpret the rollover as a 19.7 year leap in time, either backward or forward. Navigation itself should not be impacted, even if the time goes wonky, or just for a moment if it does. Non-navigational GPS receivers, like the GPS timebases used to synchronize cell phone services, might have more of an issue, but again, if the devices are of recent vintage or have been patched, there shouldn’t be an issue.
So, relax and go about your business, secure in the knowledge that when ten ones become ten zeroes sometime on Saturday, pretty much nothing will happen. If you’re so inclined, you might want to plug your car GPS in and see if there are any updates needed, but other than that, you’re probably all good. And if you really want to spend some time fretting over rollovers, think about this: it’s less than 19 years until we have to deal with the Year 2038 problem.
Fun fact: In my lab at NASA I couldn’t find a SDR or GPS test generator so I dug out my HackadayFeatured ™ FL2k and synthesized some GPS before and after the flip, testing is today to check what happens on our instruments.
Wooot!
Write it up? (tips@hackaday.com)
And do it inside a metal box, pls. :)
I am loath to be “that guy.” But hey: I was an IT professional working at the turn of the century. “…in the end, pretty much nothing actually happened” trivializes the hundreds of thousands of hours I and others like me did to make sure that—as you say—”pretty much nothing actually happened.”
Yeah, leading up to 2000-01-01, my wife (now-ex) was crashing gas pumps with her credit card that expired after the rollover. Apparently someone was dividing by the 2-digit year or something?
The year was stored as 2 digits. So as soon as the first credit card came out that expired in “00,” some machines thought it had expired 98 years before it was issued and had a freakout.
I was working at a company in China at the time that specialized in doing the COBOL dirty work in making sure the global banking infrastructure didn’t go belly up. They got rich.
I’m guessing that’s what Dan was referring to with “massive remediation efforts” in the same sentence…
And of course, Many of these systems had been fixed already, as they had “Y2K” style bugs which impacted earlier. My mum was writing COBOL back when these bugs were written. She protested against a 2-digit year for DOBs because when the system was written, there were users born pre-1900. She was overruled, and dates post-1980 became 1880s. That system presumably got fixed or replaced long before Y2K.
Indeed it was.
I’ve got to agree with you there. Don’t suggest that no one should worry. Had the IT world not spooled up and addressed the Y2K bug, I can tell you based on the number of systems and vendor solutions we had to patch, fix and rewrite, we would most certainly have had a number of serious issues.
Whether that will happen here or not? Time will tell. :-)
Eric, I too have many nasty phrases that I wish to hurl in the OPs direction. I was one of those people who spent many thankless hours making sure no one noticed ‘nutin’. BTW, a few businesses did decide that it wasn’t such a big deal and had major problems but the majority took it very seriously.
What bothers me more is random non-technical people using the fact that “you guys were saying it was going to be horrible and it was nothing” as justification for ignoring any warnings about current issues with for instance iot security.
…or climate change…
Certainly, but that’s not an IT danger. That’s a global existential crisis.
IoT is man-made and can, therefore, be changed by human activity.
But mankind does not have the power to influence the climate. Despite many climate alarmists – or should we call them eco-terrorists – think otherwise and want to control other people in a more or less religious way, reduce their living standard, increase their costs of living, prescribe them how to live or not to use their cars and so on, while they fly to “climate”-conferences themselves
Yes, the fact that ”pretty much nothing actually happened.” shows that the people working hard on the problem did their jobs well.
Yes, which I acknowledged in the same sentence. A lot of people worked very hard to patch everything so that the sky wouldn’t fall. I didn’t say that the sky wouldn’t have fallen without those efforts, or that the effort was wasted.
There was a lot of wasted effort, though – I clearly remember contractors coming through our labs with instructions to put big yellow “Potential Y2K issue” on almost every instrument. Their instructions were “If it has a light on it, it gets a sticker.” We ended up with power supplies with no microcontrollers stickered, which we then had to go and prove weren’t a Y2K liability. There’s cautious, and then there’s stupid cautious.
Least they weren’t sticking them on people. :–D
Some pacemakers were not Y2K complaint and had to be replaced.
As one of the people in a software development company, back in the day… I spent a lot of nights at work with my big dogs (mastiff and great dane) going from one end of the building to the other patching everything in sight. We had started writing down the computers and apps but that started getting out of hand and in the end it was easier to just physically start at one end and after hours work my way all the way around. The dogs liked the late night outings, I liked the comp time. In the end nothing major broke. Two small things escaped. One was the time/date on the phone system voice mail went nuts. The phone system was actually another persons bailiwick so I excused myself for that one. And the last was the fidget we had to index the websites. That turned out to be an old version and everybody had forgot about it. Updating that as soon as someone realized things were a bit wokky fixed that. Overall nothing major happened. Midnight on dec 31, 1999 was just like almost any other night leading up to it. Me and the dogs in the big building all alone. I hung out for a few hours to make sure everything major seemed OK and we all headed for home…
My wife also worked for a company that had to certify things and had the same “if it uses electricity, it gets a sticker” (think of an X-ray viewer that’s nothing more than a light bulb behind a diffuser screen.)
I made up some jars of home-made strawberry preserves that year and she took some of them to work to pass out. All were fitted with a sticker listing the ingredients, etc and all were proudly bearing the “Cerified Y2K Compliant” phrase at the bottom of the label *laugh*
Not saying Dan is a denier, but they to exist. Denying that mitigation efforts where why, the Y2K computer bug, appeared to be dud. Many of us do appreciate the mitigation efforts. Some of have been involved with other mitigation efforts that where measurably effective.
Actualyl bad stuff DID happen. I heard about an automated food warehouse that destroyed a lot of food had “expired” in ’00.
EXACTLY! Everyone that flippantly says “pretty much nothing happened” is stunningly oblivious to cause and effect and even to their own statement.”All these people were working to bail out the life boat we were on, and we didn’t even sink.” BECAUSE we worked to fix the problem.. DUHHHH!!!!!!!! Dang millenial simpletons!
Firing up my etrex today so it can get current info and see what happens tomorrow. The best thing Bill Clinton did was turn off selective availability! As soon as that happened and I had the cash I got my first GPS.
I thought ETREX used dead reckoning, accelerometers, flux gate compasses, and detailed map rules instead of “real GPS”.
It was also featured in the very horrible movie “Nothing But Trouble”, IIRC.
Never mind, that was the Etak… sorry, wrong product.
At the time of the first GPS week rollover, I was working at a navigation manufacturer of VOR, DME, ILS. We also had radar systems that used the super accurate (and way cheaper than Cesium) 1 pps GPS time sync. Those board all had the GPS week rollover issue and glitched back then. I heard or some fighter planes in the air did too (their systems rebooted in mid-flight, if memory serves). We also had some minor issues related to Y2K that we were paid by the FAA to fix (as they were our of warranty and there was no Y2K requirement at the time). Some 32 bit “seconds since xxx” counters like the older one used in MS-DOS, Windows, Unix, etc. will also encounter a rollover in 2038, as they are tied to midnight, Jan 1, 1900. See: https://www.google.com/search?q=unix+32+bit+seconds+clock&oq=unix+32+bit+seconds+clock&aqs=chrome..69i57.23668j0j7&sourceid=chrome&ie=UTF-8
1970
Y2K38 (2038-01-19 03:14:07 UTC) when signed epoch time turns negative and rolls back beyond the start of epoch time (1970-01-10 00:00:00 UTC) all the way to the beginning of the last century (1901-12-13 20:45:52 UTC), has me more worried. 32-bit epoch time storage is far more ubiquitous than GPS use, on a global scale
I should probably add that not worried at all about the very first NTP rollover (sometime around 2038-02-07 06:28:16 UTC – I’ve not allowed for any leap seconds) when compared to the Y2K38 issue because the latest NTPv4 has transitioned from storing time as 32+32 (2^32 for seconds and 2^−32 for the fractional part of the second) to 64+64 bits. With the same starting epoch that is good until the year 584,542,047,990 (our local star runs out of fuel in about 5 billion years). Basically I can not picture any computers running versions of NTP older than NTPv4 still being used by Y2K36.
Bad typo, 2038 on my mind, it should be: “2036-02-07 06:28:16 UTC”.
Technically NTPv4 is 32+32+64 ( era, seconds since epoch, fractions of second )
But the end result is almost the same. It could be functioning long after our sun is not (It will only function correctly until the year 292,271,024,945).
2k38 would be 2380, not 2038, as we use the SI prefix as the decimal separator.
Just like 2k18 is 2180, NOT 2018. Always bothered the crap out of me.
Surely that is only if a lowercase k were used ?
The Y2.038k or 2038 bug still exists in *nix and Apache which all our web servers run on.
Pretty much every PC made in the last 10 years or so (and many somewhat older than that) is 64 bit and immune to that problem. What’s problematic are embedded systems, of which there are a lot of new designs that are still 32 bit.
By 2038 (if I’m still alive) I’d be disappointed if everything that uses a processor, (including my toaster) has anything less than a 128bit processor! Or doesn’t use IPv8!
B^)
This!^
Most toasters would be lucky to get a processor and if it did there are plenty of 4 bit ones that are ideal for such a task yes I said 4 bit. They go for pennies.
But 4-bit processors are inadequate for Cloud connected Toast-Shade-Setting.
And until you have sold an infinite number of toasters, the software developers wage is still an important factor, which means a lot of products are getting 32 bit processors instead of 4 or 8.
Y2K turned out to be less of a crisis but how much of that is truly attributed to the many hours techs/devs put into addressing the issue the last few years leading up to 2000 versus whether there were that many real threats. Either way you can BET more then one low level developer warned of the y2K issue from the very start and while memory was expensive at the time thus the reason for cost cutting it just shows how business mgt puts quality/reliability and smart long term planning on the back burner and has no problem kicking something down the road for as long as possible. Why address today what can be kicked down the road for ever or at least a long time (long enough that the current leaders are long gone and don’t have to deal with the issue). Memory may have been expensive at the time but how much more expensive was it to try and tackle Y2K down the road versus doing it right the first time?
One thing I suspected back in the late 90’s was that with the (assumed) attrition rate of hardware progress, that most of the devices that had firmware written (poorly?), wouldn’t even be around by the time 2K hit. Guessing they assumed it would have all been replaced by then? Now, if I’d written something in say 1996 – yeah, no excuses there.
I was a Systems Administrator for the county courthouse IT department in 1999. As such it fell on me to evaluate all our systems for Y2K readiness from a hardware standpoint. There were a ton of bios’ with date fields having only 2 digits for the year from several brands. Some of these were only 2 years old at the time, some were server hardware and one server system that was only 4 years old had a 2 digit date in the management firmware for the remote console. Worst part was the courthouse tied into a county wide network that was used for the sheriff and local city police that ran the entire traffic and parking ticket system on a mainframe from 1969.
So no the expectation of replacement was never there, in fact the opposite was true in most cases in that time frame. The developers were writing code for the ages, not for a time period with expectations that the whole infrastructure would be replaced in a few years like today’s developers seem to do. Kinda funny to think about how current software is written with the expectation to evaporate in a few years time due to the platform being obsoleted out from under it.
In the mid 90s when I decided I’d look into it, it had become really difficult to find worst case example on consumer PCs. There were some very early 486 boards, a few 386 boards and it was 286 machines that were seeing the worst of it. Then most cases were only a sticky rollover, where manual date setting fixed it. By 96-97 though most people were at least wanting to run Windows 3.11 so 286s and below were not doing much important. Anyway, in PC hardware it was the constant hammering of y2k awareness to the tech savvy folks already running pentiums, PIIs, and better by late ’99 which were unaffected, that led to y2k fatigue.
Worse yet, the attrition rate for industrial control equipment is even lower. There is still plenty of pre Y2K industrial control hardware in use. Just three months ago I replaced a power supply on a PLC that had date stamp 1996 (and a Y2k compiance sticker, of course).
Also, 23 years for a power supply – not bad…
” Those old enough to have experienced the transition from the 1990s to the 2000s will no doubt recall the dreaded “Year 2000 Bug” that was supposed to spell the doom of civilization. ”
Or the doom of all those books warning us about Y2K. Couldn’t give them away after civilization didn’t end.
“Navigation itself should not be impacted, even if the time goes wonky, or just for a moment if it does.”
Well.. not entirely true. Really crappy receivers that are in the wrong epoch can end up completely unable to find satellites, and just end up sitting there forever, never acquiring lock. Why? Because they use the time and date to calculate which antennas should be overhead (from the almanac/ephemerides), and if the receiver is *amazingly stupid*, all of its calculations will be violently off and it can end up completely unable to find satellites at all: because if it only finds 1 in a “search the sky” mode and gets the almanac from it… it starts looking for ones that aren’t there. Like I said, you have to be amazingly stupid.
It’s basically just a firmware bug, and only 1 receiver I know of that was that stupid (the old Motorola UT Oncore with some pre-1999 firmware). If you fix it by forcing its date/time to the correct value it’s fine for another 19.6 years. They had some early code in it which attempted to figure out the epoch crossing somehow but didn’t work terribly reliably, so you’d see some of them come up in 2019, some in 2037.
I presume this is why my mid-90s Garmin has been unable to acquire satellite lock for years…?
Garmin had an update on their website for those old receivers. I updated my GPS-45, never had an issue after the rollover.
I agree that, in 2000, “pretty much nothing actually happened”
However, in 2001, a major disaster hit New York City, and I feel sure that the backup plans and procedures put in place for Y2K saved our butts in a way that most folks don’t realize.
See: http://news.mit.edu/2002/terror
Let’s just hope that none of the Boeing developers who are responsible for the 737MAX’s MCAS found previous employment working on GPS avionics. Here are some specifics about MCAS from a 737 pilot and trainer.
https://www.youtube.com/watch?v=xixM_cwSLcQ
“Thanks to short-sighted software engineering that only recorded two digits for year, we were told that date calculations would fail en masse in software that ran everything from the power grid to digital watches. Massive remediation efforts were undertaken, companies rehired programmers whose outdated skills were suddenly back in demand, and in the end, pretty much nothing actually happened.”
I hope you don’t mean to imply that nothing happened because the problem was blown out of proportion. I worked at a company that developed back-end financial trading software in the 90’s. When you go talk to your bank to buy mutual funds, or trade stock in your online trading account (as a couple of examples), our software processes the back end of the transaction. Several of the biggest banks in the country were running our code.
I, along with a fairly large team, spent 3 years in the late 90’s updating the software to be y2k compliant. We spent about 30 person-years on the fix, and in the end we did our job well and it worked. The software would have absolutely blown up spectacularly had it not been fixed.
To pretend ‘pretty much nothing actually happened” so there was no real issue beyond a media scare, is ignorant and offensive historical revisionism. It was an immense problem that took hundreds of thousands of skilled programmers years to fix. And the fact that it was fixed well should be commended,not used to pretend it was all a big joke.
OK, but for every situation like yours there was 3 where LITERALLY nothing happened. The hype leading up to Y2K had the public thinking everything from their home appliances to their cars would simply shut down. These aren’t things that could be “patched” in the field (well, at the time at least), and yet there were few examples of actual devices bricking at the rollover. Not NONE, mind you, but very few.
There’s no debate that there were systems out there that needed attention before the rollover, but those were the exception.
If there had not been an all-out effort to prevent it, close to 90% of the IBM mainframe systems in the USA would have failed on Y2K.
So while there certainly was some “hype” thrown around before the event, if it wasn’t for computer programmers working hard to prevent it, nearly every financial institution and half the hospitals in the country would have crashed hard. Think about that for a while.
We also fixed some other trigger dates at the same time (like September 9th, 1999 for example) that would have had a lesser impact.
What you might not realize is that IBM mainframe programmers in the USA at that time were part of a cohesive culture, and that culture used 2-digit dates. I watched mainframers literally flat out refuse to change from 2-digit years. I saw one guy literally QUIT rather than use 4-digit years, “because it’s not how it’s done”. It had become part of their identity. They’d do these insane algorithmic interventions to avoid revising their data structures, and some of those code monstrosities are still running today, in the calculation of ages by date of (2 digit) year of birth for example.
The VAX guys didn’t have a Y2K problem, the MacOS guys did not, the *nix guys did not, because it wasn’t part of their culture. Sure, as always, there were individual boneheads doing stupid stuff, but only on the mainframe was it literally part of the cultural identity. I never met a mainframer who didn’t use 2-digit dates, usually stored as EBCDIC strings (that’s right, 2-digit STRINGS) as a matter of course, even as late as the mid-1990s. The IBM PC only carried a little of that cultural baggage, but it was present.
Today I STILL have to stop programmers from using bad date formats; most US programmers have a broken thing in their brains that makes them think ISO 8601 is an attack on their heritage and sexual vigor, and insist on using mm/dd/yy formats that break in production and waste lots of money.
The only GPS specif device I have is a yellow Garmin hand held unit. I doubt Garmin support it anymore, If the do I neve5 aquired the computer interface cable. Such is life…
I respectfully submit that most of the “problems” of the 2 digit year “roll-over” for Y2K is not the fault of COBOL or any other programming language du jour, but even more innocuous (or insidious if you prefer) — the 80 column Hollerith punched card that formed the business foundation of what became IBM. SO MANY day-to-day issues were the result of that card dominating data storage. I remember taking FORTRANn66 with Watfor/Watfiv (I still have the book) back in 1972. I had to carefully use the card punch “editor” to craft my programs. Each FORTRAN line of code was “miraculously” limited to 80 characters. Certain column positions were “reserved” for specific functions (e.g. the first 4 or 5 was for the “line number” I “think”). So much of history’s more arcane details are lost in the noise of advancement. I’m sure we can really blame the “stupid” conservation of space for the year field to the limitations of punched cards. Only old farts like myself can even say “oh, I forget” about such subjects as younger persons never even knew such things existed, let alone experienced it first-hand. That card dominated so much of how things were done “back then”. When you know how little memory existed on old IBM mainframes, you may have some appreciation for the economizing how much memory is needed to do stuff back then. In 1980, the new, shiny DEC LSI-11 16 bit minicomputer we got at work only had 128 KB of RAM and a 5 MB diskpack — Wow!
Note that the GPS almanac bit rate is super slow, limiting how quickly a GPS can cold-start even though the almanac is short by today’s standards. This was after all designed well before it went into service back on Jan 6, 1980 and typical modems achieved 300 bps transmissions. Early GPS receivers struggled with 10 channels every 10 seconds while modern ones can handle 75 channels per second or better for a mix of GPS and other sat nav specs, like GLONASS and Galileo. Stop whining! Be glad you don’t have to use a 110 bps two-pass punched tape assembler for day-to-day coding like I did back in 1978-79 (three passes if you wanted a symbol table!).
In FORTRAN 66, and the FIELDATA FORTRAN V I wrote code in on Unisys 2200’s, columns 1-5 were for line numbers, 6 was for line continuation, and 73-80 were reserved for comments (we used it for change numbers) and not scanned by the compiler.
The WORLDFLIGHT Flight operations system at Northwest airlines, derived from UNIMATIC at UAL, would’ve had a very serious Y2K issue. It wasn’t the classic two digit year issue, but rather a translation table that was generated at assembly time in a date conversion library routine that everything used. The system had been written starting in 1966, and whoever decided to create that table decided to arbitrarily end it on 31 December 1999. Not unreasonable.
It was a simple fix, but that would’ve taken the entire system out.
Thankfully, we spent a lot of time testing with the system dedicated to Y2K, and we set the clock ahead and fixed our issues well before the actual event.
My GPS receiver has GLONASS support. Does GLONASS have this fault?
The only Y2K issue I ran into was an old 80286 a cement plant in Grangeville, ID was using for their accounting. All they ran on it was some old version of MS-DOS and some equally old DOS bookkeeping program. They’d bought it back in 1985 or 1986 and never changed a thing on it.
Fortunately the guy in charge of it was smart enough to create a new account and enter some test data, then he changed the system clock to Jan. 1, 2000. In his words “It freaked.”. After having a look at the old thing I said there wasn’t any way to update it to fix the year problem. Sold them a new PC with Windows 98SE and a copy of QuickBooks. My suggestion was to start entering info from the start of 1998 into QuickBooks and just hang onto the old 286 for archival purposes until they wouldn’t need the old data.
It’s amazing that the Y2K event is still poorly understood.
It was just media hype that your computer was going to blow up.
Yes, there were problems with PCs of that era. Many main boards had a 2 digit year real time clock soldered in and a fair amount of software including BIOS had issued.
But keep in mind that this was the late 90s when the three most common operating systems were Win95, Win98 and Win NT.
Nobody trusted these OSs with important tasks.
All the important things were done with embedded systems and this is where Y2K compliance was critical.
Things like aircraft avionics, medical devices, PLCs in critical infrastructure. This is were the important work was done.
It’s a shame we only remember the hype.
There so many people looking to test everyday non-critical equipment that we came up with 2 new job clearence definitions –
Fixed customer psychology
Adjusted customers expectations
So we’ll call this episode “Apocolypse WHERE”.
OMG my tablet clock is off by 1.6 seconds!
https://time.is
I could really give a ???? timewise. But applied to navigation that could be 0.463 miles or 2,444.444 feet. Again no biggie if you’re walking…. but potentially embarassing for an autopilot…..
Doc
Forget GPS week rollover issues. Many GPS receivers have difficulty with leap seconds that screw up their internal “clock model” for minutes to hours (at UTC 0, when it kicks in). There are many ways to mitigate the problems, but most still seem to still glitch “momentarily” (i.e. they “live” with it). It must be hard to introduce a relatively big discontinuity into a carefully crafted clock model that uses all kinds of techniques to smooth the time into something that resembles a continuous function. Most clock models ignore discontinuities by reducing their effects as satellites go out of or into view. Occasionally there may be a big ephemeris change in a satellite’s clock due to an on-board clock failure/switchover, that can still be quite disruptive. These typically doesn’t affect most uses of GPS time (e.g. our phones, hiking, driving), but it does affect WAAS landing systems, ADS-B, and systems of that ilk. The last leap second was Dec 31, 2016 and the next “possible” one could be on June 30, 2019, but that won’t happen. So when is the next leap second? I can’t seem to find a source that definitively answers that, but there are LOTS of deep thought web sites discussing leap second issues.
It’s over and i still don’t see any zombies. I’m disappointed. :-(
I don’t see zombies, neither. But my 2013 motorcycle PNA is now stuck at witching hour.
Connor Winfield who now own Navsync are offering new firmware for ‘some’ of their non-functional GPS engines
http://www.conwin.com/pdfs/gps_week_rollover.pdf
There is a widespread error in their firmware preventing the engine getting a lock during ‘Week 0″. Its unclear if those engines not updated will start working again in ‘Week 1’.
We are into Week 1 and my Navsync CW19 has come back to life so it looks promising for other Navsync devices
“The GPS system has been operating in various forms since the late 1970s, strictly for military use at first, then opened up for the civilian market in 1983, partially as a response to the shootdown of Korean Airlines flight 007 by Soviet air defenses which claimed that the airline was a spy plane.”
Maybe they thought James Bond was real!
I pulled my eTrex Legend out of its drawer for the first time in 5 years since I was hoping to take it camping next weekend. Those Garmin folks may have made some questionable firmware decisions (entering text with a mouse pointer that you move with a tiny joystick), but it appears they got the GPS rollover code right.
…or maybe they just delayed it, similar to what Hyundai seems to have done on older models (I guess they just put an offset to the rollover number, so they won’t be affected till 2 years from now). Anyway, if those devices just would allow you to enter date and time manually, they could easily use that information to understand which GPS WRNO period they’re in and prevent any problems at all.
My year-old Garmin GPSMAP 64 is A-ok, my elderly etrex Vista took a while to acquire satellites but finally did and gave the correct location; but this morning it’s balky – it found 2 birds, then dropped them, and hasn’t yet acquired satellites again. So, run your Legend a few times before trusting it.
My 4 year-old no-name GPS fob seems unable to acquire satellites :-( .
Update – I used the vista a couple of hours in the car yesterday and it was fine, Even had the correct date and time. And my USB GPS fob also worked fine, once it had a good enough shot at the sky.
Lots of people made lots of money out of the Y2K scare. That’s not to say there weren’t real issues.
Many companies used it as an excuse to get expanded budgets to do new development.
But some things were just plain money wasters like the Post Office requiring declarations from all recent (few years) suppliers certifying their products as Y2K compliant, or costs/fixes to make the supplied products compliant. Went out to everyone, including the flag maker – you know the countries flags flown from the flagpole – this is true. What a waste!
I turned on my Garmin geko 201 handheld today. Then went outside and after several minutes it had full satellite lock. A short walk around the backyard suggests that it is working. However, the date is shown as 08-Jul-58 (time is Ok). Perhaps the wrong date will affect its ability to find satellites, but it found some today.
To anyone who thinks this GPS rollover isn’t a serious issue obviously isn’t sitting in a plane waiting for an upgrade before takeoff.
https://arstechnica.com/information-technology/2019/04/gps-rollover-apparently-cause-of-multiple-flight-delays-groundings/