SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Discuss Year 2000 Issues -- Ignore unavailable to you. Want to Upgrade?


To: John Mansfield who wrote (2572)9/12/1998 5:16:00 PM
From: John Mansfield  Respond to of 9818
 
Military site: 'c4i-pro The Millennium comes early to GPS

tom briggum (tom_briggum@ccmail.nctamslant.navy.mil)
Thu, 27 Jun 96 09:36:16 EST

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Calvin, James E., SSgt: "c4i-pro LOAC and Info Attack"
Previous message: David K. Probst: "c4i-pro perimeter defense"

"tom briggum" <tom_briggum@ccmail.nctamslant.navy.mil>
Don't know the validity of the following, but it sounds authentic
to me. Talk about your major C4I problem!
... Tom Briggum
---------------------------------------------------------------------

From: gwinn[SMTP:gwinn@ed.ray.com]
Sent: Wednesday, June 26, 1996 11:48 AM To: osswgx
Subject: The Millennium comes early to GPS

I have good news and I have bad news.
The good news is that GPS will not have a "Year 2000" problem.
The bad news is that GPS System Time will roll over at midnight
21-22 August 1999, 132 days before the turn of the millennium.
On 22 August 1999, unless repaired, many or all GPS receivers
will claim that it is 6 January 1980, 23 August will become 7
January, and so on. I would expect that some manufacturers have
already solved the problem, but many have not.

The details: Section 3.3.4(b) (page 33) of the ICD-GPS-200 rev B
(30 November 1987 issue) states that the GPS Week count starts at
midnight 5-6 January 1980 UTC (Julian Date 2,444,244.500), and
that the GPS Week field is modulo 1024. This means that the week
count will roll over 1024/52= 19.69 years from then, or in
1980+19.7= 1999, only a few years from now. Specifically, first
rollover will occur at Julian Date (2,444,244.5 + 7*1024)=
2,451,412.500, which is midnight 21-22 August 1999 UTC.

I could find no mention of any field in any GPS message that
would tell you which 1024-week cycle you were in. In the July
1993 update of ICD-GPS-200, a note has been added (also on page
33) saying that the week number *will* roll over, and that users
must account for this, but no way to accomplish this is
mentioned. I take this note as further evidence that there is no
way to tell, given only the signal-in-space definition as of July
1993. I have gotten some email traffic indicating that, just as
I had suspected, some manufacturers did realize that GPS would
soon roll over, and were keeping it to themselves in the hope
that the others would fall upon their swords. Not pretty.

Our supplier was dumbfounded when I raised the issue, couldn't
stop thanking me for pointing it out years before rollover. They
clearly feel that it could have been a life-threatening disaster
for them. Every GPS-related product they had ever made would
have come back for repair, under warantee, all at once. Too
close for comfort. And, discovered by luck.

The firmware in all older units will have to be replaced. This
would involve replacement of PROMs; some are socketed, some are
soldered. New units presumably will know better than to claim
dates from before they were manufactured, and/or will allow the
user to directly or indirectly tell the firmware which 1024-week
cycle to assume, without requiring replacement of that firmware
at the second rollover, in 1980+(2*1024/52)= 2019 AD. Some of
this equipment will still be in use then, long after the
manufacturer has forgotten the product.

However, in spite of everything, not everybody will get the
message, so system software will forever have to have an
independent idea of what year it is, to know when to disbelieve a
receiver or receivers (they could all be wrong), and to handle
arguments between various GPS receivers (if only some are wrong).

Without a GPS Simulator, there is no way for users to test a GPS
receiver for this problem. All most users can do is to ask their
manufacturer for a solution, and also to imbue the system
software with a suitable degree of skepticism about GPS eceivers'
sense of time.

My intent in posting this note is to alert the entire industry to
the problem, allowing it to be solved with minimal disruption to
all. As a technical matter, the solution is quite simple. It's
the logistics that will take some years.

Joe Gwinn


stl.nps.navy.mil