Electronic – the highest achievable update rate for a civilian GPS receiver

gnssgps

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.

Best Answer

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.