# At what instant is a GPS receiver position/velocity output valid?

I am just learning about GPS and have been thinking about the timing aspects of GPS receiver navigation output. What is the relation between the time an output is produced and the time that output is a position/velocity estimate for? Is it always the case that the output is the estimate for the exact moment it is output, or was it the estimate for some (short) time in the past? And if it is the latter, is there a general method to figure out when that time was compared to the output instant?

One example of where this timing relation can be of great importance is when fusing GPS with other sensor data. For accurate fusion, being able to refer all input to the same time datum is relevant.

The common sense says that yes, the approximated position (and velocity) is related to some moment in the near past.

The signals need to be received (there is more than one signal and sometimes a single receiver, constantly re-tuned to all of them), decoded (introducing some delay), their timings compared (more delay) and the position calculated (cpu time spent).

Then, the result needs to be transmitted to whatever device expects it (generally by a serial bus, so some more delay, too).

The receiver may have moved while all these things happen. In consumer-grade GPS receivers, the position data is transmitted once in a second, or once in 1/10 second or some similar interval, simply because it is this much time (or somewhat less) that the whole this process needs.

In order to get rid of some ambiguity, timing pulses are provided between the data messages on the bus.

The exact amount of delay, as well as the exact meaning of the timing pulses are, or should be, stated in the datasheet of the particular GPS receiver.

• The velocity is derived from the position, so it will be the average velocity between two position measurements, not the momentary velocity at the point of measurement. Feb 26, 2022 at 20:38
• @SimonRichter it depends on the calculation strategy. The velocity can be derived from the timing data directly. This can skip some subtraction-related precision loss, but adds complexity and cpu load. Feb 26, 2022 at 21:00
• @SimonRichter: What fraxinus said -- in order to maintain lock on a satellite signal, the receiver must track not only the range (distance to the satellite) but also the range rate (the derivative of the range with respect to time). From the latter information, it is possible to compute an instantaneous velocity for the receiver directly. Feb 26, 2022 at 21:36