Martin Gregorie wrote:
> I don't think that affects a GPS receiver's startup process: it
> still needs the almanac data to determine the exact time:
But every satellite sends a NAV message every 30 seconds, receive just
one of those and you know the TOW (time of week)
> its location
> matters to it when correcting for signal travel time from satellite to
> receiver and, if any satellite clocks have been reset recently, what
> their UTC offset is now.
I realise you need high time precision (a few tens of ns?) to calculate
location based on distances from at least 4 satellites, but how
imprecise is the single time stamp in each NAV message? sure you can't
compensate for propagation delays etc between it and you, AIUI the
message is timed to start on the :00 or:30 second mark by the
satellite's atomic clock.
> If the receiver hasn't been run for a while it
> will need an updated almanac and, as Andy said, it may have to wait up to
> 12.5 minutes for this to be retransmitted.
>
> If a GPS receiver is designed to be a time source, it will emit NMEA-0183
> ZDA messages which only contain UTC date/time information, but equally
> there's no reason why the time recipient shouldn't accept NMEA-0183
> message types RMC, GGA or GNS and discard everything except the time
> field because all these messages contain a UTC time stamp accurate to 10
> mS.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | FidoUsenet Gateway (3:770/3)
|