Since someone posted the GPS/Y2K stuff, I thought I would pass on this and
another post....
 
>X-Mailer: Mozilla 4.05 [en] (WinNT; I)
>Date:         Fri, 11 Sep 1998 18:58:52 +0100
>Reply-To: [log in to unmask]
>Sender: ArchComp-l <[log in to unmask]>
>From: Nick Ryan <[log in to unmask]>
>Organization: Computing Laboratory, University of Kent
>Subject:      Re: GPS_Failure
>To: [log in to unmask]
>
>Unusually for him, Irwin is a bit out on on this one, but he's not alone.
Yes,
>the GPS system clock uses a 10 bit counter for its week number (GPS time is
>expressed as week and second of week), and this means that it does indeed
roll
>over at 1024 weeks. If I remember correctly, the first rollover will
happen just
>before midnight on 1999-08-21 (actually at 23:59:47 - the slight offset
from UTC
>is because GPS time does not count the leap seconds of UTC*).
>
>The important point to note here is that we are talking about an internally
>consistent clock, not a calendar. This is nothing to do with, and bears no
>similarity to, the so-called Y2K problem. To claim that this will cause the
>system to break is like saying that your digital wrist watch will fail
when the
>minutes counter rolls over every hour, or the hour counter rolls over
every day!
>Remember that Y2K is not a problem because the century rolls over, but
because
>many systems lack a century counter.
>
>When solving its position, a GPS receiver uses the broadcast ephemeris
(orbital
>parameters) of each satellite, and a new set of ephemerides is broadcast
every
>few hours. The ephemeris contains the week number and time in seconds for
which
>it is applicable, and a code that distinguishes it from all other ephemerides
>broadcast in the previous few days. A receiver will typically expect to
use a new
>ephemeris at the start of each week, and will check that the various sets of
>parameters it is using are all applicable to the current time frame. This
>checking is an essential part of the position solution and a receiver could
>potentially fail every couple of hours if this were not done.
>
>It is conceivable that some very badly written receiver code (ie that expects
>incrementing week counters) might get confused for a short while immediately
>after the rollover, and it is likely that many older devices may not
translate
>the date correctly to the 'human readable' UTC form (reverting to
1980-01-06, the
>start of the first week zero), but there is no excuse for it not to
continue to
>produce correct position solutions. Position solutions depend only on the
>internal consistency of the system.
>
>Having said that, I am aware of reports, such as that mentioned by David
Carlson,
>that certain receivers will indeed fail at week 1024 or Y2K. By all
accounts, it
>is a minority. I've written code to handle raw GPS data, and I have to say
that I
>would be very suspicious of the quality of programming in a system that
actually
>crashed at the GPS week rollover, but would not be at all suprised to see an
>incorrect date reported. Because the date is merely displayed for the user's
>convenience and is derived from the GPS clock, but not used in position
>calculations, it should not cause a serious problem.
>
>Whether GPS receivers fail at the Y2K boundary is a separate issue. It is
>possible that if they are  storing the current date using two digit years
then
>they make take longer than usual to get a first fix when turned on, simply
>because they do not know which satellites should be visible. On the other
hand,
>if they store a 4 digit year (or just use GPS time internally), then they
should
>not suffer this problem.
>
>
>Nick Ryan
>
>* I suppose it could be at 23:59:46 if a leap second is added at the end
of June
>next year, but that is not currently planned.
>
>Irwin Scollar wrote:
>
>> Re: GPS failure
>>
>> Actually it's going to happen toward the end of 1999. The problem lies in
>> the programming of the GPS system itself which was programmed by
>> people who didn't worry about the millenium. The internal clocks turn
>> over through zero after several decades because they don't have enough
>> bits. Maybe someone will think of a kludge to fix things, but there is
going
>> to be an awful mess, and I rather doubt it. There have been reports on this
>> in many of the professional programming journals. No one has offered a
>> solution for it yet. It has nothing to do with the price paid for the
system.
>>
>> I.S.
>
>
>
>--
>------------------------------------------------------------------------
>Dr Nick Ryan                       Lecturer in Computer Science
>Computing Laboratory               Chair, CAA Steering Committee
>University of Kent at Canterbury   Email: [log in to unmask]
>Canterbury                         Tel: +44 (0)1227 827699 (direct line)
>Kent                                    +44 (0)1227 764000, Ext 7699
>CT2 7NF                            Fax: +44 (0)1227 762811
>UK                        www: http://www.cs.ukc.ac.uk/people/staff/nsr/
>------------------------------------------------------------------------
>
>
********************************
*  Mary Ellin D'Agostino       *
*  [log in to unmask]   *
*  Department of Anthropology  *
*  University of California    *
*  Berkeley, CA 94720-3710     *
********************************