IoT Interfaces, Location and Privacy · Study deck
GPS Accuracy: Error Budgets
This first route explains accuracy promises, error sources, geometry, and a calculated GPS error budget.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Analyze GPS Error Budget: Explain the contribution of each error source to total positioning uncertainty
- Calculate UERE: Apply root-sum-square to combine independent error sources into a single accuracy metric
- Compare Enhancement Technologies: Evaluate DGPS, SBAS, RTK, and PPP against specific accuracy requirements
- Design for Accuracy Requirements: Justify the selection of appropriate positioning technology for specific IoT applications
Major section
Accuracy as Product Promise
Location accuracy affects what a user is allowed to trust.
- The same GNSS receiver may report a good open-sky fix, a weak urban-canyon fix, a stale assisted-GPS estimate, or no fix indoors.
- The indoor handoff shows why no signal works the same everywhere.
- Accuracy also changes over time.
Major section
Accuracy as Product Promise (continued)
When confidence falls, switch sources, ask for a check, or stop the action.
- Fallback: switch to Wi-Fi, BLE, UWB, IMU dead reckoning, computer vision, manual confirmation, or a safe stop when GNSS no longer supports the task.
- The same latitude and longitude can be acceptable for one feature and unsafe for another.
- Satellite geometry shifts, antennas are shadowed by a trailer or building, leaves and wet glass create multipath, a correction stream ages, and an indoor handoff may depend on Wi-Fi, BLE, UWB, barometer, or IMU data.
Major section
Accuracy UI Rules
Field validation should use representative routes, not a lab bench alone.
- Translate the tolerance table into UI states and automation guards.
- A dashboard might show a green "RTK fixed" badge only when correction age, satellite count, and covariance are inside bounds.
- Those traces become regression tests for later firmware, antenna, map, or dashboard changes.
Major section
Accuracy UI Rules (continued)
A mobile app might label a delivery as "near the entrance" instead of pinning it to a door when the reported horizontal accuracy is wider than the building frontage.
- A robot controller might slow down, request vision confirmation, or stop when the uncertainty radius overlaps a curb, crop row, loading dock edge, or restricted zone.
- Conversely, a cheap receiver is not cheap if it causes false arrivals, missed stops, manual dispatch calls, damaged products, or unsafe robot behavior.
- The design record should state why the chosen accuracy tier is enough and what the system does when it is not enough.
Major section
Corrections Need Visible Errors
GNSS accuracy is built from measurement quality, satellite geometry, correction data, and receiver state.
- DGPS uses a nearby reference station.
- RTK uses carrier-phase measurements and needs continuous lock.
- PPP relies on precise orbit and clock products and usually has convergence time.
- Mathematically, the receiver is estimating position from noisy range observations.
Major section
Corrections Need Visible Errors (continued)
Logs should preserve fix type, covariance or accuracy estimate, correction source, correction age, geofence decision, command id, map-matching result, and the message shown to the user.
- RTK correction streams may arrive over NTRIP using RTCM 3 messages, local radios, or a vendor cloud service.
- Safety boundary: when error exceeds the clearance needed for steering, docking, routing, or emergency response, slow down, ask for confirmation, or switch control mode.
- Sensor fusion adds another layer of contracts.
Major section
Corrections Need Visible Errors (continued)
If the correction age grows, the rover loses fixed status, the antenna is shadowed, or the receiver falls back from RTK fixed to float or standalone GNSS, the product must stop presenting centimeter-level confidence.
- Privacy boundary: collect only the accuracy needed for the feature; a zone event can be enough when a continuous coordinate trail would expose unnecessary movement history.
- A low-noise receiver with poor geometry can still produce a poor position.
- A good correction stream cannot remove a reflection from a nearby wall if the antenna receives a delayed signal path.
Major section
Corrections Need Visible Errors (continued)
An extended Kalman filter or similar estimator can combine GNSS, wheel odometry, IMU acceleration, magnetometer heading, barometer altitude, camera lane detection, lidar obstacles, Wi-Fi fingerprints, BLE proximity, and UWB ranges.
- The fused output should expose covariance, source contributors, last update time, and fault flags so downstream automation can decide whether the estimate is suitable for display, routing, steering, billing, or only historical logging.
- Persistence should keep enough evidence to debug bad decisions without storing unnecessary movement history.
- A compact event can include fix_type, horizontal_accuracy, vertical_accuracy, hdop, satellite_count, correction_age, correction_source, map_version, fusion_mode, confidence, stale_after, and the user-visible label.
Major section
Putting Numbers to It
The terms combine at the range estimate even though they originate in different places and vary on different timescales.
- That connection explains why a product needs both a calculated uncertainty and operational evidence about sky view, environment, corrections, and receiver state.
- The ionosphere (50-1000 km altitude) is a layer of charged particles created by solar radiation.
Major section
Putting Numbers to It (continued)
Geographic location: Equatorial regions have 2-3× higher ionospheric activity than poles.
- Each sigma term represents a one-sigma range-error contribution in metres; squaring prevents positive and negative deviations from cancelling, summing combines the independent variances, and the square root returns the result to metres.
- The resulting UERE is a ranging uncertainty, not the final horizontal position error.
- Satellite geometry and correlated or biased errors still matter, so carry those limits into the accuracy promise.
Major section
Checkpoint: UERE and GDOP
Once the math is visible, the design choice becomes a tiering decision.
- Different IoT applications require different levels of positioning accuracy.
- A phone GPS fix can support broad navigation or tracking, while augmentation and differential methods narrow the error under their stated conditions.
- PPP and RTK sit higher in precision and require more supporting service or equipment.
Major section
Checkpoint: UERE and GDOP (continued)
The pyramid presents example ranges and uses, not a guarantee at every site.
- Indoor Positioning Reality Check: GPS signals are −130 dBm (extremely weak) outdoors.
- Myth 1: "GPS is always accurate to within 5 meters" Reality: 5-10m is open-sky accuracy.
- Urban canyons (tall buildings) can degrade accuracy to 50+ meters due to multipath and poor GDOP.
- Myth 4: "RTK gives 2cm accuracy everywhere" Reality: RTK requires continuous phase lock to satellites.
Deck summary
Key takeaways
Location accuracy affects what a user is allowed to trust.
- When confidence falls, switch sources, ask for a check, or stop the action.
- Field validation should use representative routes, not a lab bench alone.
- A mobile app might label a delivery as "near the entrance" instead of pinning it to a door when the reported horizontal accuracy is wider than the building frontage.
- GNSS accuracy is built from measurement quality, satellite geometry, correction data, and receiver state.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A GPS receiver reports UERE of 6 meters and HDOP of 4.0. What is the expected horizontal one-sigma uncertainty?
Show answer
Answer: B Horizontal one-sigma uncertainty = UERE × HDOP.
Q2Independent range-error terms are 3 metres and 4 metres. What is their combined UERE?
Show answer
Answer: C The square root of 3² + 4² square metres is 5 metres.
Print reference
Answers
Answer key.
- B · Horizontal one-sigma uncertainty = UERE × HDOP.
- C · The square root of 3² + 4² square metres is 5 metres.