61 GPS Location: Ranging Methods

61.1 Start With the Decision

A GPS receiver measures travel time, not a dot on a map. Four biased ranges are needed to solve position and clock error.

61.2 Route Overview

This is part 1 of 2. Continue with GPS Location: Architecture and Error Control.

61.3 Part Objectives

• Derive pseudorange from signal travel time.
• Solve position and clock bias with satellite geometry.

61.4 Start Simple

Design for the Moment the Position Becomes Uncertain

Picture a walking app beside tall buildings. The dot appears on the wrong street, moves in jumps, and then freezes while still looking current. The user needs to know whether the position is good enough for the next choice, not merely whether a dot exists.

Start with the decision the position supports. Record event time, arrival time, age, stated accuracy, movement, and the amount of open sky. Define the states the user will see: searching, usable, weak, old, and unavailable. Keep the last known place separate from a fresh position.

Walk from open ground into a narrow street, stand still, restart the receiver, change direction, and block part of the sky. Check how quickly the state changes, whether the screen explains uncertainty, and what safe action remains when the position is lost. Compare the record with a known route rather than one perfect point.

This trial cannot prove every city, weather, or device. The deeper sections show how satellite timing, geometry, reflected signals, clock error, update rate, and receiver evidence bound an outdoor position claim.

Outdoor positioning begins with a simple question: can the receiver see enough sky to support the promise? Start with satellite geometry, timing error, multipath, update rate, and power, then decide what the user should see when the fix is good, degraded, or unavailable.

Phoebe’s Field Notes: Why the Pseudorange Needs a Fourth Satellite

The mathematical gist. Light needs about 67.4 ms to cross the chapter’s 20,200 km orbit-scale distance. A 1 µs receiver-clock error becomes 299.8 m of pseudorange error, while a 3.00 m target requires about 10.0 ns timing precision. Position plus clock bias creates four unknowns, so the receiver needs at least four independent satellite equations.

Math Bridge · guided foundationsWhy does one microsecond become three hundred metres?Let UX Uma turn light travel, clock bias, pseudorange, and the fourth satellite into one chain. Learn the maths

61.5 Summary

GPS/GNSS positioning depends on satellite timing, pseudoranges, geometry, receiver clocks, and environmental multipath. Outdoor positioning designs should account for accuracy limits, power use, update rate, and failure conditions.

61.7 Learning Objectives

By the end of this chapter, you will be able to:

• Explain GPS/GNSS Architecture: Describe the space, control, and user segments of satellite navigation systems
• Calculate Positioning from Satellites: Apply Time of Flight and TDoA principles to determine position
• Diagnose Multipath Effects: Distinguish how signal reflections degrade positioning accuracy in different environments
• Justify Clock Synchronization: Explain why atomic clocks are essential and demonstrate how pseudoranges compensate for receiver clock errors

61.8 Prerequisites

• Location Awareness Fundamentals: Understanding of positioning technology landscape

61.9 GPS Timing as Product Context

GPS/GNSS is not just a map dot. It is a timing system that lets an IoT product infer outdoor context from weak satellite signals, known orbits, receiver clock error, and a changing view of the sky. The product decision is what the system should do with that context: show a vehicle route, confirm a gate arrival, enforce a geofence, steer a machine, timestamp a field event, or refuse an unsafe automation.

Before deciding how User Position shapes gps timing as product context, inspect Figure 61.1 beside pseudoranges (at least 4). Together, User Position and pseudoranges (at least 4) frame the gps timing as product context claim: a gps product should treat the coordinate as the output of satellite timing, pseudorange, and receiver clock-offset solving, not as an isolated latitude and longitude value.

Read User Position alongside pseudoranges (at least 4) in Figure 61.1; their named relationship makes a gps product should treat the coordinate as the output of satellite timing, pseudorange, and receiver clock-offset solving, not as an isolated latitude and longitude value concrete. For gps timing as product context, User Position supplies visible evidence; pseudoranges (at least 4) constrains the decision. In Figure 61.1, retain User Position beside pseudoranges (at least 4) so gps timing as product context remains explicit.

Good outdoor location design starts by separating the fix lifecycle from the user promise. A receiver may be searching, downloading assistance data, using a two-dimensional fix, using a three-dimensional fix, coasting on dead reckoning, or reporting a stale position after losing sky view. The interface should not show all of those states as the same precise blue dot.

That distinction matters because the same receiver can be excellent in one context and misleading in another. A field sensor with a clear antenna view may produce stable fixes every few minutes. A courier phone in an urban canyon may report plausible but wrong locations because reflected signals make pseudoranges too long. A tracker under a vehicle dashboard may acquire slowly because metal and glass attenuate the satellite signals. The product should expose the quality difference before it triggers an action.

Design the user promise around the consequence. “The asset was last seen near gate 4 at 10:31” is a different promise from “unlock the gate because the vehicle is here.” A route display can tolerate a snapped-to-road correction, but an audit trail should keep the raw fix and the corrected point separate. A safety geofence should require dwell time, accuracy radius, and current timestamp instead of accepting a stale point inside the boundary.

• Acquisition: cold start, warm start, assisted GPS, and time-to-first-fix affect what a user sees during setup and recovery.
• Continuity: update rate, power mode, antenna placement, map matching, and IMU handoff decide whether tracks are smooth or jumpy.
• Trust: accuracy radius, timestamp, fix type, and fallback wording tell users when the location is useful enough to act on.

61.10 Receiver State Machine Design

Treat the GNSS receiver as a stateful component. During setup, record whether the device has a valid time source, recent almanac, recent ephemeris, enough satellites, acceptable HDOP, and a clear antenna view. During operation, record whether the receiver is using GPS alone or a multi-GNSS fix with Galileo, GLONASS, BeiDou, or QZSS; whether position comes from GNSS, Android Fused Location Provider, Apple Core Location, or an external receiver; and whether the product has applied map matching or sensor fusion.

For battery IoT devices, the correct update rate is rarely “as fast as possible.” A livestock collar, rental scooter, delivery app, and safety beacon have different duty cycles. Track the cost of each fix in active current, radio upload, cloud storage, and user attention. Use batching, geofence triggers, adaptive sampling, and motion detection when continuous GNSS would waste energy without improving the decision.

Build acceptance tests around the places where GNSS changes behavior. Test open-sky startup, tree cover, urban street canyons, indoor-to-outdoor transition, pocket or bag carry, low battery, airplane mode, poor antenna orientation, and recovery after several hours powered off. For embedded modules, include antenna ground plane, enclosure material, cable length, and placement near radios or processors. For phones, include permission denial, approximate-location mode, background throttling, and operating-system power saving.

Use different display and automation rules for different fix classes. A dashboard can show a stale position with a timestamp and grey styling. A dispatch workflow can route a driver only after speed, heading, and map-matched road segment agree. A custody workflow can ask for a QR or NFC confirmation at the site when the GNSS radius is larger than the loading bay. Those rules make uncertainty operational instead of leaving support staff to explain why a blue dot looked exact.

1. Specify the fix policy: define no-fix, searching, coarse, good, stale, and degraded states with display text and allowed automations.
2. Specify the movement policy: combine speed, heading, accelerometer, gyroscope, odometer, or map-matched road segment only when their timing and frames line up.
3. Specify the power policy: choose continuous tracking, periodic fixes, event-triggered fixes, or user-requested fixes based on consequence and battery life.

61.11 Under the Hood: The Fix Is a Pipeline

A practical GNSS pipeline starts with RF acquisition and ends with a position, velocity, and time solution. The receiver searches for signals such as GPS L1 C/A, GPS L5, Galileo E1/E5, BeiDou B1/B2, or GLONASS signals; locks code phase and Doppler; decodes navigation data; applies ephemeris, clock, atmospheric, and relativistic corrections; estimates pseudoranges; and solves for receiver position and clock offset. Many modules expose the result through NMEA sentences such as GGA, RMC, GSA, and GSV, or through binary protocols such as UBX.

The product should keep the quality fields near the coordinate. Useful fields include fix type, HDOP/VDOP/PDOP, satellite count, constellation mix, C/N0 signal quality, estimated horizontal error, estimated vertical error, speed, course over ground, timestamp, leap-second/time status, assistance-data age, and antenna status. If a cloud service or map layer changes the coordinate, keep both the raw fix and the processed position so operations teams can distinguish receiver behavior from product logic.

The receiver clock is the reason GPS needs at least four satellites for a full fix. Each satellite gives one pseudorange equation. The unknowns are receiver x, y, z, and receiver clock offset from GNSS time. Once more than four satellites are available, the solver can use an overdetermined least-squares solution and report dilution-of-precision values that describe the geometry. Good geometry does not remove all error, but poor geometry can make otherwise valid measurements produce a weak position.

Make that fourth unknown visible with the chapter’s clean four-satellite teaching case. Step from one range sphere through the added constraints and shared clock term to one Gauss–Newton update and the final rank/geometry diagnosis. Keep a pseudorange ledger beside the solved receiver and clock-bias values so the geometry and arithmetic stay tied to one state.

For the counterexample, leave every satellite coordinate, pseudorange, clock term, and noise value unchanged and vary only the enabled measurements from three to four. The conclusion reverses from insufficient independent measurements with no published fix to a solved 3-D position plus the shared receiver-clock bias. Then compare GDOP and PDOP with the residual ledger; a rank-four solution can exist while weak geometry still amplifies small measurement errors.

Assistance and correction services change the pipeline. Assisted GNSS can provide approximate time, approximate location, almanac, or ephemeris data over a network to reduce time-to-first-fix. SBAS, DGPS, RTK, or PPP can reduce some satellite, clock, and atmospheric errors when the receiver and service support them. Those features should be represented in product metadata because a centimeter-capable RTK rover in fixed mode is making a different claim from a phone-grade coarse fix.

• Cold-start risk: without valid time, location, almanac, or ephemeris, first fix can be slow; assisted data over SUPL or a vendor service changes startup behavior.
• Urban risk: multipath and blocked sky can pass through the solver as plausible coordinates; map matching and inertial smoothing help but can also hide real uncertainty.
• System risk: a geofence, route, or safety command should consume the quality-aware location event, not a naked latitude/longitude pair.

61.12 Global Navigation Satellite Systems

“GPS” is often used as shorthand for satellite positioning, but a receiver may combine several constellations with different orbital and service characteristics. The constellation chart in Figure 61.2 establishes that wider GNSS estate before the chapter discusses accuracy and enhancement.

The first card in Figure 61.2 identifies US GPS, its 31 operational satellites, and a 20,180 km orbital altitude, with civilian accuracy in the 3–5 m range. GLONASS is shown separately with 24 operational satellites and 5–10 m civilian accuracy, while Galileo reports a different operator and 1–3 m class. Compare the Frequency rows as well as satellite counts: a multi-constellation receiver gains sky coverage, but its actual fix still depends on supported bands, antenna view, geometry, and the error sources examined later.

GPS (Global Positioning System): The first and most widely deployed Global Navigation Satellite System (GNSS), which has come to dominate outdoor positioning.

To understand GPS fully, we first examine two important techniques…

61.13 Time of Flight (ToF)

Time of Flight: Measure the time taken for a signal to propagate from transmitter to receiver.

Before deciding how Trilateration Steps shapes time of flight (tof), inspect Figure 61.3 beside d = c × t. Together, Trilateration Steps and d = c × t frame the time of flight (tof) claim: time of flight concept.

Read Trilateration Steps alongside d = c × t in Figure 61.3; their named relationship makes time of flight concept concrete. For time of flight (tof), Trilateration Steps supplies visible evidence; d = c × t constrains the decision. In Figure 61.3, retain Trilateration Steps beside d = c × t so time of flight (tof) remains explicit.

Distance Calculation:

Distance = Speed of Light × Time of Flight
d = c × Δt

where:
- c = 299,792,458 m/s (speed of light in vacuum)
- Δt = reception time - transmission time

Critical Challenge: Both transmitter and receiver must have synchronized clocks to know the true transmission time.

61.14 The Multipath Problem

Before deciding how Ideal: Clean intersection shapes the multipath problem, inspect Figure 61.4 beside Real: signal reflects off objects. Together, Ideal: Clean intersection and Real: signal reflects off objects frame the the multipath problem claim: multipath problem in gps.

Read Ideal: Clean intersection alongside Real: signal reflects off objects in Figure 61.4; their named relationship makes multipath problem in gps concrete. For the multipath problem, Ideal: Clean intersection supplies visible evidence; Real: signal reflects off objects constrains the decision. In Figure 61.4, retain Ideal: Clean intersection beside Real: signal reflects off objects so the multipath problem remains explicit.

Multipath: Signals reflect off objects, creating multiple paths between transmitter and receiver.

Impact:

Fine for communications: Multiple signals can be combined. Kills positioning: Makes distances appear longer than reality. Indoor environments: Severe multipath due to many reflective surfaces.

Checkpoint: Timing and Reflections

You now know:

• Time-of-flight turns signal travel time into distance, so 67-68 ms maps to GPS-orbit ranges.
• A 1 microsecond clock error means about 300 m of range error.
• Multipath can move an urban fix from 5-10 m accuracy to 50+ m error.

61.15 Time Difference of Arrival (TDoA)

Before deciding how Basic distance shapes time difference of arrival (tdoa), inspect Figure 61.5 beside Hyperbola Legend. Together, Basic distance and Hyperbola Legend frame the time difference of arrival (tdoa) claim: time difference of arrival.

Read Basic distance alongside Hyperbola Legend in Figure 61.5; their named relationship makes time difference of arrival concrete. For time difference of arrival (tdoa), Basic distance supplies visible evidence; Hyperbola Legend constrains the decision. In Figure 61.5, retain Basic distance beside Hyperbola Legend so time difference of arrival (tdoa) remains explicit.

The Problem with Simple ToF:

Mobile device and fixed sites separated by large distances. Cannot keep clocks synchronized. RF signals travel at c, so 1 μs sync error = 300m position error.

TDoA Solution:

Accept that clocks aren’t synced. Solve for the clock offset as an additional unknown. Any single range is wrong, but every range is wrong by the same amount. These erroneous ranges are called pseudoranges.

Key Requirements for TDoA:

Base Stations Must Be Synchronized:. Lay cables between stations. Use GPS (ironically!). Give them all atomic clocks ($$$).

Mobile Device Clock Can Be Wrong:. Clock offset becomes an additional unknown to solve. Need N+1 stations for N-dimensional positioning. 3D position + clock offset = 4 unknowns → need 4 satellites.

GPS uses the same idea in reverse: the expensive clocks are in space, and the receiver solves its own cheap clock error as part of the position.

61.16 Continue to the Next Part

Carry this evidence into GPS Location: Architecture and Error Control, which begins with GPS Architecture.