Turning a Consumer Phone Into Class-1 Survey Equipment

Every road engineer knows the International Roughness Index number. It drives maintenance priorities, informs tender documents, and is embedded in most defect-liability contracts in jurisdictions that use chainage as the canonical asset reference. The instruments that produce it — laser profilometers, inertial profilers, specialist survey vehicles — cost in the tens of thousands of dollars and require certified operators.

For a significant class of users — smaller consultancies, contractors under performance-based maintenance contracts, public works departments in emerging markets — those price points are a wall. They end up doing visual inspections instead, which is faster than nothing but generates qualitative data that doesn't fit into the same reporting pipelines that demand numeric IRI.

Building a mobile road-survey application, we spent a lot of time on the question: can a consumer smartphone, with its built-in accelerometer and GPS, produce a genuinely comparable number? The answer is yes — but not casually.

The problem with naive approaches

The common path — read the accelerometer, integrate vertical acceleration twice, call it roughness — produces numbers that correlate with road quality in a rough-and-ready way. It does not produce numbers comparable to class-1 instrumentation, for several reasons.

Mounting tilt contaminates the signal. If the phone isn't perfectly level, gravity leaks into the vertical channel and swamps the actual road-induced acceleration. A tilt of 5 degrees is enough to render the raw number meaningless.

Speed variation breaks segment comparison. IRI is defined at a specific reference speed. A phone app that doesn't account for actual vehicle speed produces a number that varies with how quickly the driver was going, not with how rough the road was.

Consumer-grade sensors drift. Over a ten-minute recording, a cheap MEMS accelerometer accumulates bias that a laser instrument doesn't.

GPS outages corrupt chainage attribution. Lose fix for 200 metres and your roughness segments become attributable to the wrong kilometre.

All four of these produce failure modes that wouldn't show up in a laboratory test but dominate any real survey on a real road.

The pipeline that actually works

A defensible mobile IRI implementation has to be a proper multi-stage signal-processing chain. The one we settled on looks like this:

1. Gravity-compensated vertical extraction. Use the rotation-vector sensor to track the phone's orientation in space, decompose the accelerometer signal into its gravity-aligned and gravity-orthogonal components, and work only with the orthogonal one.
2. Band-pass filtering. Tune a filter to the spatial frequencies that actually matter for vehicle response — not the high-frequency noise, not the low-frequency drift, just the range a real vehicle's suspension responds to.
3. Road-profile integration. Convert the filtered acceleration signal to a displacement profile using numeric integration, with drift-correction between reset points.
4. Quarter-car dynamic model. The IRI specification is defined in terms of a reference vehicle model. You can't skip this step — you have to run the profile through the standard quarter-car response and accumulate the filtered suspension displacement.
5. Segment accumulation synchronised to chainage. Instead of emitting one IRI value per clock-time interval, emit it per chainage interval (20 m, 100 m, or 1 km depending on the use case). Chainage comes from a separately-filtered GPS stream with jump rejection and accuracy gating.
6. Quality flags per segment. Every emitted number carries metadata: what was the speed variance during that segment? How much mounting tilt? How many GPS samples landed in the segment? Downstream consumers can filter on confidence.

Every stage has to run deterministically at the sensor rate — on our target devices, around 100 Hz. That means no allocations in the hot path, long-lived worker threads, and rigorous attention to garbage-collection pressure. It looks more like embedded firmware engineering than typical mobile development.

Why the quality flags matter most

You could stop at step 5 and ship. The reason we insist on step 6 is that consumer hardware has honest limits, and a number emitted without context is a number that will be misused.

A 100-metre segment with two GPS fixes and a 6-degree tilt variance is not a class-1 IRI value. It's an indicator with a caveat. Systems that don't carry the caveat produce false confidence — and in any defect-liability context, false confidence is worse than no number at all.

The quality-flag system is what lets a non-specialist operator use the tool without producing misleading data. If they held the phone wrong, the tool says so. If they drove too slowly through a segment, the tool says so. If GPS coverage was thin, the tool says so. The engineer reviewing the output decides which segments to trust.

What this unlocks

Not every road authority can afford class-1 profilometers. Many of them settle for coarser instruments, or for visual inspection. A mobile survey tool that produces defensible, quality-flagged IRI per chainage interval — from a phone the field team already owns — lowers the threshold for systematic condition monitoring by an order of magnitude.

It's not a replacement for specialised equipment on projects where specialised equipment is mandated. It's a usable alternative for the much larger class of work where "no number at all" was the previous status quo. That's the gap worth closing.