Inside Road Monitor: route replay and vibration on the iPhone

After a drive, remembering that the car shook somewhere along the route is only a starting point. Useful review means returning to the moment, seeing the recorded position and examining the motion around it.

That workflow now exists in Xinexis Road Monitor. The current native iPhone prototype records journeys and lets a user explore route, time and vibration together. It is a measurement and investigation tool; it does not label a phone jolt as a confirmed pothole.

Record first, review later

The app records motion and location to local storage, with timestamps and recording context. Capture does not depend on a server connection. Users can return to saved journeys and inspect the original recordings on the phone; map imagery may still require internet access.

Recording controls are intended to be set before driving, with the phone securely mounted. Detailed review belongs after the vehicle is safely parked. The prototype also supports an explicit upload workflow to the local review setup. Public internet access for a multi-user cloud service is a separate implementation stage.

Use time as the connection

Saved journey review combines a map, a timeline and playback. Moving the time cursor lets the user examine where the phone was recorded at that point in the journey. The vibration review shares the selected time, so a route observation and a motion observation can be explored together.

Recent work made slider movement more responsive by reusing map overlays, caching analysis and looking up the selected point efficiently. This improves the review experience without changing the underlying recording. It also makes short events easier to revisit than searching an entire trip by eye.

Understand the vibration readings

The live and saved views describe eligible four-second windows. The useful distinction is between the size of the response, its timing and any repeating pattern within it.

• Vertical acceleration: the signed motion trace over time. Positive and negative values preserve the oscillation rather than folding it into a one-sided shape.
• RMS: a summary of vibration magnitude across the selected window after its mean is removed. A sustained response and a brief spike can therefore look different.
• Peak: the largest absolute vertical sample in that window. It highlights a strong instant, but does not explain its cause.
• Dominant frequency: the strongest sufficiently clear repeating component in the inspected band, expressed in cycles per second. A broad jolt may have no clear frequency peak.

The spectrum displays how signal power is distributed across frequency. Our implementation uses a windowed periodogram; the SciPy periodogram reference (opens in a new tab) provides the underlying definitions. The prototype's display thresholds are our engineering choices, not externally validated pothole criteria.

Sensor sampling rate and vibration frequency describe different things. Samples per second tells us how often measurements arrive. Vibration frequency describes a pattern within those measurements. Neither number, by itself, gives road-defect severity.

Inspect jolts without inventing precision

Threshold-based jolt markers help a user find stronger responses. A listed jolt carries its time and strength. It receives a map marker only when there is a suitable nearby recorded GPS fix, whose timestamp is shown separately.

Missing motion, unsuitable timing or excessive rotation can make a window unavailable. These states prevent a clean-looking chart from implying that every part of a drive was measured successfully. Likewise, the absence of a marked jolt does not establish that the road was smooth.

What this version can support

The prototype supports short exploratory recordings, with a ten-minute or record-count limit. Foreground capture is the baseline; the optional background drive mode remains experimental and needs further physical-device continuity and battery testing.

Today, users can collect, replay and describe an observation. Comparing repeated passes from different vehicles, resolving road direction and evaluating likely causes belong to the next server stage. If that investigation workflow could support your operation, talk with Xinexis about a bounded pilot.