> 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