When GPS Drops Out: R&D for Dynamic Speed Limiting in Tunnels

Dynamic Speedlimiter
Back to all articles

A vehicle enters a long tunnel. The road continues, but its satellite position may stop updating. For a dynamic speed limiter, that creates a practical engineering challenge: how should the system maintain road context as the vehicle keeps moving?

At Elementz, we are investigating this challenge using the u-blox NEO-M9V receiver, inertial sensing and wheel-tick inputs. This introductory R&D case study shares our current integration progress and the questions guiding the next stage of testing.

Why tunnel positioning matters

A dynamic speed limiter relates vehicle position to a road’s speed-limit data. When position becomes stale or drifts towards a neighbouring road, the application can lose the context needed to select an appropriate limit.

Our existing solution performs road and speed-limit lookups, allowing that part of the system to operate without mobile connectivity. Tunnel navigation introduces a separate challenge: maintaining a useful position estimate when satellite measurements become unavailable.

The research objective is to bridge those positioning gaps using measured vehicle motion. This preserves an estimated navigation solution; it does not restore satellite reception inside the tunnel.

Dynamic Speedlimiter Display
Dynamic Speedlimiter Display

Combining GNSS, inertial sensing and wheel ticks

GPS is one part of the broader Global Navigation Satellite System (GNSS) landscape. The NEO-M9V supports sensor fusion that combines GNSS measurements with its internal accelerometers and gyroscopes. Automotive dead reckoning adds wheel-tick or vehicle-speed information to that combination. The u-blox integration manual describes these operating modes.

Each input contributes a different part of the motion estimate: satellite measurements provide an absolute reference, inertial sensors describe changes in motion and orientation, and wheel ticks provide a measure related to travel distance. Together, they offer a way to estimate the vehicle’s progress during a GNSS outage.

For this application, the engineering task includes checking pulse behaviour, sensor alignment and calibration, then evaluating how the resulting position affects road selection.

Making sensor fusion observable

Dead Reckoning test dashboard

We have developed a dedicated diagnostic dashboard that brings receiver status and wheeltick pulse output into one view. It exposes fusion mode, subsystem initialization, sensor calibration, measurement availability and navigation output. Session logging captures receiver navigation and status data for later analysis.

In the captured development session, the dashboard reports:

  • Active fusion mode and a combined GNSS-plus-dead-reckoning solution.
  • Initialized wheel-tick, mounting-alignment, inertial-navigation and IMU states.
  • Fine-calibrated status across the listed sensors.

These are useful integration milestones. The capture is stationary and still has satellite reception, so it records the receiver’s reported state. Performance during a GNSS outage requires separate validation. The wheel-tick channel’s participation flag is also inactive in that frame. Checking calibration and actual measurement use separately is therefore part of our moving-vehicle validation.

Building a repeatable calibration workflow

We have added tools to capture sensor-fusion calibration data, save it during fusion operation and send stored data back to the receiver. Automatic capture and connection controls make repeated development sessions easier to manage.

The next question is how consistently that workflow supports recovery across receiver restarts and vehicle power cycles. A saved calibration file gives us something concrete to inspect and test; startup behaviour still needs measurement under the intended operating conditions.

This work connects the navigation experiment to the practical realities of an embedded vehicle device: installation, startup, interrupted power and repeatable testing.

The next milestone: measured tunnel behaviour

Dead reckoning depends on sensor quality and calibration. Good GNSS conditions before an outage also matter because satellite measurements help calibrate the motion sensors, as u-blox explains in its discussion of dead-reckoning limitations.

Our proposed validation programme will examine:

  • Position continuity and drift: compare the estimated path against a suitable reference over increasing outage durations.
  • Vehicle behaviour: evaluate curves, speed changes, stops and restarts.
  • Recovery: measure how positioning settles when satellite reception returns.
  • Application decisions: assess road selection, speed-limit transitions and fallback behaviour when position confidence falls.

The current milestone is an instrumented prototype that makes these questions testable. The next is evidence showing how well it supports dynamic speed limiting through long tunnels.

Developing a vehicle product that must operate through positioning gaps? Talk to Elementz about your embedded systems R&D requirements.