In message: <[EMAIL PROTECTED]>
            Rob Seaman <[EMAIL PROTECTED]> writes:
: The question is whether "at least 20 minutes" (presuming this to be
: accurate) is intrinsic to the system design or is rather a result of
: poor implementation by some receiver manufacturers.

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.

As I stated before, various recievers have differing definitions of
'cold'.  Some are 'cold' the instant you turn them off.  Others are
cold only if they have been off so long that they have no way of
knowing the current correct leap count.  Given that BIPM only
publishes 6 months in advance, this means that the longest a receiver
can be off is about 6 months.  Many modern receivers do a good job of
caching the data over short to medium periods of being off.  This is
why others have reported that you get the right time from a Garman
within a few seconds of power on.

Also, a GPS receiver that has cached the almanac can acquire
satellites much more quickly than one who has to wait for the almanac
to be downloaded.  Many receivers, when acquiring satellites, take a
while to do this when they have no almanac.  This adds a little time
to recovery.  I believe the almanac is retransmitted every 18:<mumble>
seconds, but I've been saying 20 because it takes a little time (a
couple of minutes) to find the first satellite to start the process.

: A typical design pattern for conveying crucial metadata that is only
: rarely updated is to also convey a timestamp or expiration date.
: Either the eggs are expired or they aren't.  There certainly are ways
: for a GPS receiver to store metadata - even over a period of a year.
: Having cached the leap second table, the only question is whether it
: is expired for which a 4 or 8 byte timestamp would be quite sufficient.

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.

Warner

Reply via email to