From Data to Physics: Building the GNSS Measurement Engine

Introduction

In my last article, I discussed the data files that power my sensor fusion project. But raw data alone isn't enough. The real challenge begins when you must transform those satellite ephemerides and reference trajectories into physically meaningful measurements that a rover can use to navigate.

Today I want to share how I built the core of my system: the GNSS Measurement Engine. This is the component that takes static data and converts it into a dynamic simulation of how satellite signals interact with my rover.

The Purpose: Where Data Meets Physics

The engine's main goal is simple in concept but complex in execution: generate corrected GNSS measurements that are realistic enough to feed into my future end to end system.

In practical terms, this means taking known satellite positions (SP3), antenna corrections (APO), and the rover's true trajectory, then producing:

• Corrected pseudoranges: The apparent satellite-to-receiver distance, including simulated errors

• Pseudorange rates: For Doppler measurements and velocity estimation

• Line-of-sight information: Crucial metadata about each visible satellite

The Architecture: Three Stages of Data Transformation

My implementation follows a three-stage flow that mirrors real GNSS signal processing:

Start with raw satellite data and rover trajectory
↓
Filter out unusable satellites
    - Wrong constellation? Remove
    - Too low elevation? Remove  
    - Missing corrections? Remove
↓
Propagate satellite orbits to exact times
    - Take sparse position points (every 5 minutes)
    - Interpolate to get positions for every second
    - Achieve centimeter-level precision between known points
↓
Generate realistic measurements for each satellite
    - Calculate geometric distance rover-satellite
    - Compute elevation and azimuth angles
    - Apply physical corrections and error models
    - Output final pseudoranges with error breakdowns

Stage 1: Feasibility Filtering

Not all satellites in the data are useful. My filtering process eliminates satellites that don't meet practical operational criteria.

Stage 2: Bridging the Time Gaps with Lagrangian Interpolation

Here's where I faced a fundamental challenge: precise satellite orbits are only provided every 300 seconds in the SP3 files, but my simulation requires positions every single second. Five-minute gaps are eternity in GNSS time.

This is where Lagrangian interpolation becomes essential. The process works like this:

Take 10 known position points around my target time
    - Five points before, four points after the gap
    - Use polynomial fitting to create smooth trajectory
    - Evaluate polynomial at each required second
    - Repeat for X, Y, Z coordinates independently
    - Do the same for satellite velocities

The beauty of this approach is that it doesn't just guess positions, it reconstructs the physical continuity of orbital motion. A 10th-order polynomial captures the subtle accelerations and curvatures that simple linear interpolation would miss. The result is Satellite positions with centimeter-level accuracy at any moment, even between the sparse reference points.

Stage 3: The Measurement Kitchen - Where Physics Comes Alive

The measurement generation is where the true data-to-physics transformation occurs. Most of these values aren't in the raw data. We derive them through computation:

For each satellite that passes our filters:

    Calculate the straight-line distance to rover
    Convert positions to local navigation frame
    Derive elevation angle from vertical/horizontal components
    Compute azimuth for directional relationships

    Apply relativistic timing corrections
    Model atmospheric delays that bend and slow signals
    Account for satellite clock imperfections

    Combine everything into final distance measurements
    Package comprehensive metadata for analysis

Important: We compute elevation and azimuth ourselves because these angles drive many physical models. Atmospheric errors, signal strength, and even satellite selection all depend on these derived values.

Visual Validation: From Numbers to Insight

The real test isn't just producing numbers but producing numbers that make physical sense. I use visualization to transform raw output into intuitive understanding by plotting whatever result I'm interested in. For example:

Create sky plots showing satellite positions
    - Plot each satellite as point on circular chart
    - Position shows direction (azimuth)
    - Distance from center shows elevation
    - Color indicates signal quality

Analyze error patterns vs elevation
    - Plot different error types on separate charts
    - Show how errors decrease at higher elevations
    - Verify models match expected physical behavior

Track measurements over time
    - Graph pseudorange changes for each satellite
    - Highlight when satellites appear/disappear
    - Compare with geometric truth for validation

...

These visualizations serve as my "sanity check". They instantly reveal patterns that would be invisible in spreadsheets of numbers. Seeing atmospheric errors follow expected patterns, or watching satellites move predictably across the sky, confirms the physics is working correctly.

The Crucial Lesson: Understanding Orders of Magnitude

The biggest challenge wasn't implementing algorithms, but developing physical intuition about what the numbers should represent. I had to internalize the expected scales:

• Satellite distances: Around 20,000 kilometers

• Relativistic effects: Dozens of meters

• Atmospheric errors: Meters to tens of meters

• Clock errors: Typically 1-2 meters

Without this "numerical sense", debugging would be nearly impossible. The visualizations became my truth-teller, instantly flagging when results drifted from physical reality.

Current Limitations and Next Steps

Currently, hardware/local errors are simulated within realistic bounds. This works for prototyping, but eventually I'll need more sophisticated models based on real estimated data.

The combination of corrected measurements and comprehensive metadata provides both inputs for future filtering and diagnostic tools to understand system behavior.

Conclusion: From Theory to Practice

Building this measurement engine taught me that in precision navigation, the devil is in the physical details. It's not enough to know the equations; you must develop deep intuition about expected magnitudes and interactions. The visualizations bridge the gap between mathematical correctness and physical plausibility.

For those working on positioning systems: What's been your biggest challenge when modeling realistic GNSS measurements? Any counter-intuitive physical effects that surprised you? What visualization techniques have you found most valuable?

As I continue refining this measurement engine, I'm reminded that engineering is rarely a solitary pursuit. The insights and shared experiences from mentors, colleagues and community are invaluable. I'll be diving into the IMU engine implementation next, and I'd love to hear your stories and advice as I take that next step.