GPS System Failures Last Week (Shades of Y2K!)
-
Last week, in the final stages of site preparation for a new substation, I called on our tribal GIS department to assist in creating a landform profile and spotting some points for equipment placement. They tried for hours, two days in a row, but could not acquire and track sufficient satellites to do the job. A few frantic phone calls turned up a bit of interesting news. An error in the satellite programming - now 15 years old - caused every unit in orbit to change the date to 1993 two weekends ago. This renders the tribe's $50,000 GPS hardware useless, along with every other station of this type in the world. The manufacturer (and, presumably, all other manufacturers similarly affected) is working on a firmware revision and should have a fix by Wednesday, but in the meantime no one using this type of equipment is getting any work done. Considering the bruhaha that ensued in 1998 and continued for about 3 years, I find it inconceivable that any programmer who experienced that era would fail to check, double check, and still distrust any coding that operates on date data. How could such an error happen? And how could it have gone undetected for 15 years? These things have had periodic revisions to their operating code, and should have been regression tested for each upgrade. Surely some clue that a problem was cooking must have turned up! So, what about you? Do you take special care in working with date-related code? Do you just copy and paste whatever is lying around from previous projects and reuse it, assuming it to work? Are you too young to remember the billion$ wasted trying to find and fix potential disasters before the magic witching hour and so just type what looks like it will work and move on?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Last week, in the final stages of site preparation for a new substation, I called on our tribal GIS department to assist in creating a landform profile and spotting some points for equipment placement. They tried for hours, two days in a row, but could not acquire and track sufficient satellites to do the job. A few frantic phone calls turned up a bit of interesting news. An error in the satellite programming - now 15 years old - caused every unit in orbit to change the date to 1993 two weekends ago. This renders the tribe's $50,000 GPS hardware useless, along with every other station of this type in the world. The manufacturer (and, presumably, all other manufacturers similarly affected) is working on a firmware revision and should have a fix by Wednesday, but in the meantime no one using this type of equipment is getting any work done. Considering the bruhaha that ensued in 1998 and continued for about 3 years, I find it inconceivable that any programmer who experienced that era would fail to check, double check, and still distrust any coding that operates on date data. How could such an error happen? And how could it have gone undetected for 15 years? These things have had periodic revisions to their operating code, and should have been regression tested for each upgrade. Surely some clue that a problem was cooking must have turned up! So, what about you? Do you take special care in working with date-related code? Do you just copy and paste whatever is lying around from previous projects and reuse it, assuming it to work? Are you too young to remember the billion$ wasted trying to find and fix potential disasters before the magic witching hour and so just type what looks like it will work and move on?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Last week, in the final stages of site preparation for a new substation, I called on our tribal GIS department to assist in creating a landform profile and spotting some points for equipment placement. They tried for hours, two days in a row, but could not acquire and track sufficient satellites to do the job. A few frantic phone calls turned up a bit of interesting news. An error in the satellite programming - now 15 years old - caused every unit in orbit to change the date to 1993 two weekends ago. This renders the tribe's $50,000 GPS hardware useless, along with every other station of this type in the world. The manufacturer (and, presumably, all other manufacturers similarly affected) is working on a firmware revision and should have a fix by Wednesday, but in the meantime no one using this type of equipment is getting any work done. Considering the bruhaha that ensued in 1998 and continued for about 3 years, I find it inconceivable that any programmer who experienced that era would fail to check, double check, and still distrust any coding that operates on date data. How could such an error happen? And how could it have gone undetected for 15 years? These things have had periodic revisions to their operating code, and should have been regression tested for each upgrade. Surely some clue that a problem was cooking must have turned up! So, what about you? Do you take special care in working with date-related code? Do you just copy and paste whatever is lying around from previous projects and reuse it, assuming it to work? Are you too young to remember the billion$ wasted trying to find and fix potential disasters before the magic witching hour and so just type what looks like it will work and move on?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
What about the time corrections that are sent to the satellites all the time? Also, no sign of this problem anywhere else. Maybe it's the receiver that has the problem which is much more likely.
Visit http://www.notreadytogiveup.com/[^] and do something special today.
-
You sure someone isn't pulling your leg? You'd think there would be a bit more news out there if all of the satellites suddenly reset to 1993. As it is now, I can't find a single reference online. Cheers, Drew.
That's the line we're getting from the manufacturer, but I too have trouble believing it. I've checked the military site that has oversight for the system, and there isn't a word about it there.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
What about the time corrections that are sent to the satellites all the time? Also, no sign of this problem anywhere else. Maybe it's the receiver that has the problem which is much more likely.
Visit http://www.notreadytogiveup.com/[^] and do something special today.
I agree! I've been checking the GPS system site a bit and I can't find any mention of a failure, though there have been quite a few uploads to prevent the imminent failure of the system that was predicted years ago. It looks to me like the system is well in hand by its managers, and the device manufacturer hasn't kept up with the changes. Still the question applies... Why don't they (the device manufacturers) take this seriously?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Last week, in the final stages of site preparation for a new substation, I called on our tribal GIS department to assist in creating a landform profile and spotting some points for equipment placement. They tried for hours, two days in a row, but could not acquire and track sufficient satellites to do the job. A few frantic phone calls turned up a bit of interesting news. An error in the satellite programming - now 15 years old - caused every unit in orbit to change the date to 1993 two weekends ago. This renders the tribe's $50,000 GPS hardware useless, along with every other station of this type in the world. The manufacturer (and, presumably, all other manufacturers similarly affected) is working on a firmware revision and should have a fix by Wednesday, but in the meantime no one using this type of equipment is getting any work done. Considering the bruhaha that ensued in 1998 and continued for about 3 years, I find it inconceivable that any programmer who experienced that era would fail to check, double check, and still distrust any coding that operates on date data. How could such an error happen? And how could it have gone undetected for 15 years? These things have had periodic revisions to their operating code, and should have been regression tested for each upgrade. Surely some clue that a problem was cooking must have turned up! So, what about you? Do you take special care in working with date-related code? Do you just copy and paste whatever is lying around from previous projects and reuse it, assuming it to work? Are you too young to remember the billion$ wasted trying to find and fix potential disasters before the magic witching hour and so just type what looks like it will work and move on?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
So, what about you? Do you take special care in working with date-related code?
I don't see how anyone can use database and programming languages for anything sensible having to do with dates. I mean, come on. You can't even use SQL Server (or couldn't, I actually haven't looked at it in years) for chronology of anything historical before, what 1751? Was that the magic date? And what about MFC or .NET? something like 1901 for the earliest date? It's absurd, IMO. For a long time anytime I had to deal with dates I would use a 3 field structure for year, month, and day, and had my own routines for comparisons. Marc
-
Roger Wright wrote:
So, what about you? Do you take special care in working with date-related code?
I don't see how anyone can use database and programming languages for anything sensible having to do with dates. I mean, come on. You can't even use SQL Server (or couldn't, I actually haven't looked at it in years) for chronology of anything historical before, what 1751? Was that the magic date? And what about MFC or .NET? something like 1901 for the earliest date? It's absurd, IMO. For a long time anytime I had to deal with dates I would use a 3 field structure for year, month, and day, and had my own routines for comparisons. Marc
I rather doubt that the GPS network uses SQL Server, or any other HLL for date manipulation. Space is at a premium still in satellite systems, and RAM is more precious than anything save, perhaps, fuel for orbital corrections. It's almost a certainty that they use nothing more fancy than C for the flight hardware. Similarly, the handheld devices used for precision GPS data collection rely on custom software optimized for compactness and efficient use of resources. That rules out any commercial database product - none are efficient, or friendly to systems with limited storage.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Last week, in the final stages of site preparation for a new substation, I called on our tribal GIS department to assist in creating a landform profile and spotting some points for equipment placement. They tried for hours, two days in a row, but could not acquire and track sufficient satellites to do the job. A few frantic phone calls turned up a bit of interesting news. An error in the satellite programming - now 15 years old - caused every unit in orbit to change the date to 1993 two weekends ago. This renders the tribe's $50,000 GPS hardware useless, along with every other station of this type in the world. The manufacturer (and, presumably, all other manufacturers similarly affected) is working on a firmware revision and should have a fix by Wednesday, but in the meantime no one using this type of equipment is getting any work done. Considering the bruhaha that ensued in 1998 and continued for about 3 years, I find it inconceivable that any programmer who experienced that era would fail to check, double check, and still distrust any coding that operates on date data. How could such an error happen? And how could it have gone undetected for 15 years? These things have had periodic revisions to their operating code, and should have been regression tested for each upgrade. Surely some clue that a problem was cooking must have turned up! So, what about you? Do you take special care in working with date-related code? Do you just copy and paste whatever is lying around from previous projects and reuse it, assuming it to work? Are you too young to remember the billion$ wasted trying to find and fix potential disasters before the magic witching hour and so just type what looks like it will work and move on?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
(1) Date math is harder than you think, even when acocunting for this rule (2) Why would anyone need a GPS station?
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist -
Roger Wright wrote:
So, what about you? Do you take special care in working with date-related code?
I don't see how anyone can use database and programming languages for anything sensible having to do with dates. I mean, come on. You can't even use SQL Server (or couldn't, I actually haven't looked at it in years) for chronology of anything historical before, what 1751? Was that the magic date? And what about MFC or .NET? something like 1901 for the earliest date? It's absurd, IMO. For a long time anytime I had to deal with dates I would use a 3 field structure for year, month, and day, and had my own routines for comparisons. Marc
TheLastWord wrote:
anything historical before, what 1751?
FYI 01/01/1753
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
Last week, in the final stages of site preparation for a new substation, I called on our tribal GIS department to assist in creating a landform profile and spotting some points for equipment placement. They tried for hours, two days in a row, but could not acquire and track sufficient satellites to do the job. A few frantic phone calls turned up a bit of interesting news. An error in the satellite programming - now 15 years old - caused every unit in orbit to change the date to 1993 two weekends ago. This renders the tribe's $50,000 GPS hardware useless, along with every other station of this type in the world. The manufacturer (and, presumably, all other manufacturers similarly affected) is working on a firmware revision and should have a fix by Wednesday, but in the meantime no one using this type of equipment is getting any work done. Considering the bruhaha that ensued in 1998 and continued for about 3 years, I find it inconceivable that any programmer who experienced that era would fail to check, double check, and still distrust any coding that operates on date data. How could such an error happen? And how could it have gone undetected for 15 years? These things have had periodic revisions to their operating code, and should have been regression tested for each upgrade. Surely some clue that a problem was cooking must have turned up! So, what about you? Do you take special care in working with date-related code? Do you just copy and paste whatever is lying around from previous projects and reuse it, assuming it to work? Are you too young to remember the billion$ wasted trying to find and fix potential disasters before the magic witching hour and so just type what looks like it will work and move on?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
You might find this site[^] interesting. It is used mostly in the aviation field to predict when there will be problems with navigation by GPS. I've been watching it daily for some time now, and haven't seen any outages like you describe.
Karl - WK5M PP-ASEL-IA (N43CS) PGP Key: 0xDB02E193 PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
-
That's the line we're getting from the manufacturer, but I too have trouble believing it. I've checked the military site that has oversight for the system, and there isn't a word about it there.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
More likely it's your particular gps unit itself that has the flaw in the code. Our garmin seems to be working fine.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg