MERIDIAN.

What happens when GPS disappears?

Navigation applications depend heavily on satellite positioning. But in tunnels, covered roads, dense urban environments and other signal-restricted areas, GPS availability can become unreliable.

When positioning data disappears, conventional navigation experiences can lose the ability to accurately represent a vehicle's location.

For a driver, this creates uncertainty:

• Is the navigation system still working?
• Is the displayed location reliable?
• Is the vehicle still being tracked?
• What happens when GPS becomes available again?

MERIDIAN addresses this challenge through intelligent dead reckoning, using smartphone IMU data and available GNSS information to estimate vehicle movement during signal outages.

The design challenge: How might we make a technically complex navigation system understandable and trustworthy, even when its primary positioning source is unavailable?

MERIDIAN was developed for Smart India Hackathon problem statement 26168:

AI-ML based Intelligent Dead Reckoning system for seamless navigation.

The system combines smartphone sensors, GNSS positioning, an AI-assisted velocity estimation pipeline and map-based navigation.

At a high level, the experience needs to support three important states:

GNSS available The system uses available satellite positioning to establish and update the vehicle's location.

Dead reckoning active When GNSS becomes unavailable, the system estimates movement using inertial sensor information and continues navigation.

GNSS reacquired When satellite positioning returns, the system transitions back towards GNSS-aided navigation.

These states informed the way the interface communicates system status and positioning information.

I was responsible for the UI/UX design of MERIDIAN.

I designed the interface from scratch, including its visual direction, screen layouts, information hierarchy and presentation of navigation and technical information.

My design contribution covered:

• Overall interface design and visual direction
• Main navigation experience
• Route planning and destination selection
• GPS-loss and recovery interface
• Developer Mode and telemetry presentation
• Screen-level information hierarchy and visual consistency

The mobile application, runtime engineering and AI/ML pipeline were developed by other members of the team.

Designing for two different audiences

MERIDIAN has to communicate with two distinct audiences: people using the navigation experience and people inspecting the system's technical behaviour.

This created two different interface needs.

The navigation experience

The primary interface needed to keep the map and route at the centre of attention. Important information such as speed, heading and positioning accuracy needed to remain accessible without competing with the map.

The technical experience

Developer Mode needed to expose deeper information, including sensor readings, GNSS positions, predicted positions, drift and confidence.

Rather than presenting all this information on the main navigation screen, I designed a separate technical view.

This separation helps keep the everyday navigation experience focused while retaining access to detailed system information.

Five original UI design frames by Ishit Papnai. The two mobile app screenshots below show the team’s implementation.

01. Launch and initialization

The loading screen is the first thing users see when they open MERIDIAN. It establishes the visual identity and communicates sensor and mapping-engine initialization before the main navigation screen appears.

02. Main navigation

The main navigation screen is the primary interaction point of MERIDIAN.

The map takes visual priority, while essential vehicle and positioning information is organised around it.

The interface brings together:

• Current navigation map
• Route and location information
• Vehicle speed
• Positioning accuracy
• Heading information
• Access to additional navigation controls

The design objective was to make the most important information easy to identify at a glance.

03. Route planning

The route screen allows users to define a starting point and destination before navigating.

I designed this screen to make route-related actions and information easy to understand, while maintaining consistency with the main navigation interface.

04. Recovery Mode — Navigation without GPS

This is one of the most important states in the MERIDIAN experience.

When GPS becomes unavailable, the interface needs to communicate that change without making the user feel that navigation has completely stopped.

The recovery interface keeps the map visible and introduces a prominent GPS-loss status indicator.

The intention is to communicate three things:

• GPS positioning is currently unavailable.
• The system has transitioned to dead reckoning.
• Navigation information continues to be displayed.

Keeping the map visible is important because the user still needs spatial context during the outage.

05. Developer Mode

Developer Mode is designed for technical inspection and system monitoring.

It exposes information that would otherwise overwhelm the primary navigation interface, including:

• Raw sensor axes
• Physical GNSS position
• Accepted and predicted positions
• Drift and positioning error
• Confidence information
• Trip recording controls

The challenge was to organise a large amount of technical information into a structured interface that can be inspected without losing context.

This screen also makes MERIDIAN more useful as a development and validation tool, rather than only a navigation interface.

Keep navigation visible during GPS loss

Instead of replacing the navigation experience with a full-screen error state, the recovery interface retains the map as its primary visual element.

This reinforces the idea that the system is continuing to estimate movement.

Make system status explicit

GPS availability is not something the user should have to infer. A dedicated status indicator communicates when the system is operating without GNSS.

Separate everyday and technical information

The main navigation screen prioritises information relevant to navigation. Developer Mode provides access to deeper telemetry and system-level details.

Make positioning information accessible

Speed, heading, accuracy, predicted positions and confidence are important to understanding the system. Their presentation helps make the underlying navigation behaviour more visible.

Although my contribution focused on UI/UX, understanding the underlying system was important to designing the interface.

MERIDIAN uses:

• Smartphone IMU: Accelerometer and gyroscope data for motion estimation.
• GNSS: Satellite positioning when available.
• TinyVelocityCNN: A compact AI model used to estimate velocity from vehicle-frame sensor data.
• Dead reckoning: Forward-only motion integration with vehicle movement constraints.
• OpenStreetMap: Map tiles and nearby road geometry.
• Flutter and Dart: Mobile application development.
• ONNX Runtime: Portable edge inference reference.

The system also includes confidence reporting and explanatory reasons for velocity predictions.

This technical context informed the information that needed to be surfaced in the interface.

An evaluated dead-reckoning pipeline

The team's offline evaluation tested a 59.9-second GNSS blackout using a held-out IO-VNBD Driver A S3c recording.

Measured drift5.08%

SIH offline threshold10%

Common scale: 0–10% drift. Lower is better. Values supplied in the project brief; one held-out offline recording. This does not establish road-test performance.

The measured 5.08% drift was below the SIH offline threshold of 10%.

This is an offline benchmark result, not proof of validated real-world road performance. A fixed-mount real-car blackout test, mobile update-rate measurement and physical transition-latency measurement remained outstanding.

MERIDIAN challenged me to think beyond conventional app interfaces.

Designing a navigation product that continues operating through GPS outages meant considering not just what information users need, but also how the system should communicate changes in its own state.

One of the most important design considerations was balancing simplicity with technical depth: keeping the primary navigation experience focused while making detailed system information accessible when needed.

It also reinforced how important it is for designers to understand the technology behind the products they design. The better I understood the system's behaviour, the more thoughtfully I could structure its interface.

MERIDIAN was an opportunity to bring together interface design, information architecture and engineering context to create a coherent experience for a technically complex product.

Project credits

MERIDIAN — Smart India Hackathon

My contribution: UI/UX Design

Team contributions included mobile application and runtime engineering, AI/ML development, research, business and presentation deliverables.