Re: [LEAPSECS] RAS hits the news

From: Tom Van Baak <tvb_at_leapsecond.com>
Date: Mon, 26 Sep 2005 09:36:49 -0700

> A cold GPS receiver takes about 20 minutes to get the almanac data
> from the GPS constellation. It is intrinsic to GPS that this is the
> case. You cannot get around this.

It's easy to solve that if the application requires it.
You could get the almanac from an external source;
such as another GPS receiver, a base station, a
memory card, a cell phone data service, the internet, etc.

> The GPS format already does this, even more efficiently than you might
> think. There's two 8 bit quantities, and two 10 bit quantities that
> represent the current and future leap second data. The 8 bit fields,
> as others have pointed out, are due to overflow in the next century or
> so. The week number also overflows in GPS. Many receivers 'cheat'
> and use a prediction algorithm to know which 1024 week epoch we're in
> by looking at the number of leap seconds. So when that field
> overflows (be it at 7 bit or 8 bit (it is defined to be a signed
> number, but that definition could be change)), better algorithms will
> be needed.

Firmware or manufacture date is also a method used
to establish the correct epoch; this is true for GPS
receivers as well as any clocks or watches that
display 4-digit years. Add to that any PDA or PC with
a CMOS clock.

Too much is made of the "overflow". Fields rollover all
the time in real life and it's often a simple engineering
matter to take this into account. Not sure I would call
it "cheating". We get by fine with just 7 names for days
of the week; calendars that rollover every 12 months,
wristwatches that overflow every 12 hours...

Has someone on the list looked into the details on how
Galileo or the new GPS L2/L5 messages handle leap
seconds?

/tvb
Received on Mon Sep 26 2005 - 09:44:11 PDT