GNSS Tunnel Positioning: Why Post-Processing Wins – Urban Challenges #4

Short intro and dataset
For this mini-series we keep one consistent dataset: 20 drive logs, each close to one hour. We drove a normal passenger car in Darmstadt and Frankfurt through forest, city, dense residential, industrial zones, highway, and the high-rise/banking district. Hardware was a geodetic GNSS receiver (Javad Triumph-LS) and a MEMS IMU from ~2013 (Xsens MTi G-700). Processing uses AlgoNav’s tightly-coupled Network-PPK with our mobile VRS (MVRS), fused with IMU, odometry, and motion constraints. All five posts rely on these runs.

Part 1 — Why post-processing beats real-time (especially in tunnels)

Tunnels make one core point very easy to see: post-processing has a structural advantage over pure real-time.

Assume the position error grows quadratically with time while GNSS is unavailable (classic IMU drift behavior in position). Let the tunnel traverse take time \( T \). A real-time (forward-only) solution reaches its maximum error at the exit, call it \( E_{\text{RT,max}} \). At the tunnel midpoint (\( T/2 \)) you only have a quarter of that: \( E_{\text{RT,mid}} = \frac{1}{4} E_{\text{RT,max}} \).

Now in post-processing we can also run the estimator backwards in time. At the midpoint we have two estimates with similar uncertainty (one from the forward pass, one from the backward pass). Combine them, and the standard deviation reduces by \( \sqrt{2} \) (two independent estimates of equal variance). So the maximum post-processed error occurs at the midpoint and is

That is the clean math picture. In practice, the gap often widens further: robust outlier handling, model consistency checks, and bi-directional integer fixing typically cut the effective error to 10% or even ~1% of a comparable real-time result on hard segments.

“Use a real-time solution only when you truly need real-time. If you can process offline, do it—you get a large, structural accuracy win for free.”

Part 2 — Tunnel ≠ hardest algorithmic case. Exits are.

Many teams treat tunnels as the ultimate algorithm challenge. Reasonable at first glance: no GNSS, so IMU drift accumulates. Our view is different:

• Inside the tunnel: The algorithmic picture is actually simple: you integrate IMU (plus odometry, motion constraints). Stability is set by sensor quality and correct stochastic modeling.
• The real fight: The algorithmic fight happens at dense entrances/exits. You leave the tunnel with large state uncertainty and immediately face urban canyon visibility with many potential outliers—but not much redundancy to separate good from bad.

The AlgoNav Strategy for Tunnel Transitions

To handle this, you need logic that goes beyond a forward Kalman filter:

1. Iterative outlier detection: Use an optimal smoother (e.g., RTS) over a window spanning before and after the exit to re-evaluate residuals.
2. Smoothing-stage ambiguity fixing: Allow bi-directional/lagged fixing inside the smoothing pass. Short clean windows after the exit can “reach back” and lock ambiguities earlier.
3. Reliability before availability: Right after the exit, cap measurement influence in weak directions and use MDB-aware gating.
4. Tightly-coupled fusion: Feed raw carrier/code + IMU jointly to shrink the integer search space.
5. Deferred optimism: First stabilize, then go aggressive with fixing and tighter weights as confidence grows.

What we see in data

• Inside tunnels: Smooth IMU/odo propagation; covariance grows as modeled; no algorithmic drama.
• Exits into dense streets: First GNSS samples are a mix—some clean, some multipath. Forward-only filters either over-trust or over-reject.
• With smoother-based reweighting and lagged fixing, the solution stabilizes within a few seconds without lateral jumps.

Practical takeaways

What this means for your projects

If you can run post-processing, do it. You’ll get smaller errors exactly where you fear them most. If your routes include tunnel exits into dense city, invest in smoother-based outlier handling. That’s where robustness is won.