# What is the highest achievable update rate for a civilian GPS receiver?

I'm interested in knowing the maximum achievable update rate for a civilian GPS receiver. Specifically

• Receivers that depend exclusively on GPS satellites (e.g. not including IMU-based movement estimation to interpolate)
• The hypothetical limit (i.e excluding feasibility concerns, e.g. processing power)
• Update rate after lock (e.g. TTFF)

The fastest civilian receiver chips I've found have an update rate of 50Hz, such as the Venus838FLPx.

According to alex.forencich in this stackexchange thread, it might be "rather high":

It's difficult to pin a position update rate on the satellites as it's all in the receiver. The satellites simply transmit orbital ephemeris data and the time of day at 50 bits per second and a CDMA chip rate of 1.023 MHz, all precisely phase locked to an atomic frequency standard. The GPS receiver maintains a lock on the CDMA spreading code and uses that to determine the time of arrival differences between the satellites. Getting a lock in the first place takes a while, but after that the position can be updated at a rather high frequency. I'm not sure what the upper limit on that is.

And this is of course unrelated to the CoCom speed and altitude limits for civilian receivers.

That's what I've found.

• @MarkoBuršič that's very obviously wrong. there's multiple hard limits. to begin with the phase, that obviously gives you a first hard limit (frequency of the carrier). Then, you have Cramer-Rao that will not allow you any significant accuracy without accumulating enough observation. then, an arbitrarily high update rate is completely uncompatible with Shannon's channel capacity. Then, you have, due to Planck/Heisenberg, very limited potential LO accurracy, leading to limited location accuracy, and limited update rate. The list goes on. – Marcus Müller Feb 20 '17 at 22:27
• From a gut feeling, I'd start with Shannon's Channel capacity, as it seems a rather harsh limit considering the low bandwidth and low SNR that is physically possible, even without atmospheric effects. – Marcus Müller Feb 20 '17 at 22:31
• Nothing to indicate the GPS position calculation meets or exceeds the output. The output could be oversampling the position. – old_timer Feb 21 '17 at 3:45
• Javad and Topcon both make receivers with 100Hz position update rates. Those are the fastest I've seen generally available. As others have noted most manufacturers are limited to 20 or 50Hz, there is little real world benefit in running any faster so for most applications its a waste of CPU time and power to do so. – Andrew Feb 21 '17 at 14:37
• @winny Shannon haunts my sleepless nights; I might as well give him credit where credit is due :P – Marcus Müller Feb 21 '17 at 19:47

The constraining factor is the lowpass-filtering after despreading. If we assume -204dBW/Hz noise power density (~ 17°C noise temp), we can only allow around 25kHz of noise bandwidth before it reaches the L1 power of -160dBW. Our integration time must be at least 1/25.000s to detect the signal from the noise background (assuming omnidirectional antenna). This is the theoretical limit for a full strength signal.

The product of integration time $T$ and tracking loop bandwidth $B_n$ must be significantly less than unity for the loop to be stable, so at most 25kHz bandwidth are possible (in real-world-receivers, you will often find $T=10^{-3}s$ and $B_n<=18Hz$). The relative timing of received signal and local replica can only change (meaningful) at a rate of $B_n/2$, making more frequent position fixes useless.

You can cheat by using a directional antenna, but in order to compute azimuth and elevation, your antennas position needs to be fixed, and that kind of contradicts the purpose of a navigation system.

Now back to reality: shortening the integration period of makes the position fixes more noisy. Given the link budget of an off-the-shelf unit, more than 50 fixes/s is a waste, unless you have really strong signal, all you get is (phase-)noise. And theres a high computational burden, it will eat battery like hell.

• Nice. A couple complicating factors, though: 1. We can get a "virtual" bandwidth increase by observing more than the minimum four satellites; you'd normally increase the accuracy, not the speed, with that. 2. We could push down the noise floor by using receiver diversity; that's a pretty limited, but a relatively cheap way to go. Thinking about it, 1. and 2. are both exploiting redundant info in the receiver system with independent noise, so both are diversity techniques. Both are very much at the "logical" boundary of what is still a single GPS receiver, and not effects of sensor fusion. – Marcus Müller Feb 21 '17 at 5:58
• @MarcusMüllerYes, Increasing accuracy also increases possible fix-rate and thereby maximum trackable dynamics. Multiple coherent signals help (L2), same goes for phased array antennas. We are no longer talking "civil" here. – Andreas Feb 21 '17 at 6:40
• Well, diversity by adding more receiver chains would be relatively simple, compared to let's say significantly pushing down noise figure. I'm pretty sure a 18Hz GPS receiver already falls under what you'd have to fill an export control form for. – Marcus Müller Feb 21 '17 at 14:14
• Great. Now I want to revisit SDR implementations of GNSS receivers. And I don't have the time... – Marcus Müller Feb 21 '17 at 14:22
• @MarcusMüller FWIW: I've not seen >10Hz in COTS SMD IC's, but 5 and 10Hz solution rates are common as far as I know. – Morten Jensen Feb 22 '17 at 20:00

A GPS receiver operates by maintaining an internal software "model" of the receiver's position (and derivatives of the position). A Kalman filter is typically used to keep this model in sync with reality, based on raw data coming from the satellites.

The signal from each satellite is normally integrated for 20 ms at a time, because this is the bit period of the PSK data coming from the satellite. This means that the model gets a raw update on the distance from each satellite 50 times a second. However, note that the updates from different satellites are essentially asynchronous (they don't all occur at the same time), because the path length differences from satellites overhead to satellites on the horizon is also on the order of 20 ms. As each new satellite measurement comes in, the internal model is updated with the new information.

When the GPS receiver puts out an update message, the data in the message comes from the model. The receiver can update the model as often as it likes, and output position messages as often as it likes, too. However, the result is simple interpolation — no new information is contained in the extra output messages. The information bandwidth is constrained by the rate at which the raw satellite measurements are fed to the filter.

As Andreas notes, having a high output message rate does NOT mean that you can track higher receiver dynamics. If you must track high receiver dynamics, you must use other sources of information such as an IMU. In a "tightly-coupled" system, the IMU data updates the same internal model that the GPS receiver is using, which allows the IMU to "assist" the tracking of the individual GPS signals.

There's also an economic side to the question. Most "civilian" GPS receivers are highly cost-constrained, and therefore, only enough CPU power (and battery power) is employed in order to meet the update rate requirements for the application at hand (e.g., car or cellphone navigation). An update rate of once a second (or less) is more than enough for most such applications. "Military" applications that need higher update rates have higher budgets for materials and power. The GPS receivers are priced accordingly, even though the actual receiver hardware is essentially the same, with the possible exception of employing a more powerful CPU.

• Ah well, as you said and I think might be worth stressing: higher update rates usually come from sensor data fusion with other sensors. Things like precision compasses and accelerometers are usually the hefty costs in IMUs you don't normally buy if you're not flying at high speeds. I mean, seriously, a Kalman, even an extensively modified one, is probably not a problem for a microcontroller with FPU running at a couple 100 MHz. The algorithm and it's parametrisation, the calibration and integration knowledge is what manufacturers are going to make you pay for (aside from expensive sensors) – Marcus Müller Feb 21 '17 at 14:20