One question. One clear answer.

Normal ride recording with iPhone GPS, live values and ride statistics remain free, as does the 0–100 km/h or 0–60 mph sprint measurement. One Garage vehicle, the Apple Watch remote, optional Race Training with heart rate, Live Activity, naming and deleting rides, the map view, Race Summary and importing existing Track4Facts backups are also free. The lock never deletes previously saved data.

The Full Version unlocks the complete lap/racing mode with tracks, start/finish, sectors, live delta and lap times. It also includes distance timing, custom sprint ranges, external Bluetooth GPS receivers, the other charts, Replay, GPX/CSV export, complete backup export and additional Garage vehicles. It is a one-time purchase with no subscription; earlier customers who bought the paid app keep the Full Version automatically.

After you start recording, Track4Facts continues in the background, including while the screen is locked. Valid GPS samples are used for speed, top speed, distance and average speed. The app also determines ride duration, stops and, when vertical accuracy is sufficient, elevation difference.

Sprint timing runs alongside the normal ride recording; in the Full Version this also applies to enabled distance targets. The measurement page currently visible does not change what is measured for the active ride. In Lap mode, completed laps and their sector times—when captured completely—are stored as well. When optional Race Training is enabled on a paired Apple Watch and Health access is granted, time-aligned heart-rate values are stored too.

No. A normal ride may begin while the vehicle is already moving. As soon as several coherent, plausible GPS samples confirm motion, speed, distance, top speed and the other ride statistics update.

Only measurements that require a real standing start—such as 0–100 or distance from zero—remain locked until the app observes a stable standstill during the same recording.

iPhone GPS needs no extra hardware and reaches Track4Facts through Core Location. It provides position, GPS speed and normally horizontal, vertical, speed and course accuracy. Its update rate is controlled by the system and is typically lower or more variable than that of an external performance receiver. Core Location does not expose satellite count or pDOP to the app.

Supported Bluetooth receivers are XGPS150, XGPS160 and Dragy Lite. XGPS provides a 2D/3D fix, speed, course, battery and, where available, WAAS/DGPS. The XGPS SDK used here does not expose per-sample accuracy values, satellite count or pDOP in every update, so those diagnostics may show “–”. Dragy Lite additionally provides horizontal and vertical accuracy, speed and course accuracy, satellite count and pDOP. Its update rate can be set to 10, 20 or 25 Hz in GPS diagnostics.

The configured position- and speed-accuracy limits apply to iPhone and Dragy because both provide those values. For XGPS, Track4Facts instead validates the fix, age, continuity and plausibility of the samples. A higher rate can resolve threshold and line crossings more finely in time, but is not automatically more accurate: reception, antenna position, satellite geometry, reflections and fix quality remain decisive.

External GPS receivers require the Full Version. XGPS150 or XGPS160 must be connected to the iPhone; the app automatically searches for a powered-on Dragy Lite and reconnects it after an interruption. If a Dragy has not yet been prepared for performance operation, its one-time GNSS configuration and restart can take about 45 seconds. Use only one external receiver at a time.

The source is fixed when a ride starts. If a supported receiver is connected then and the Full Version is active, Track4Facts uses its GPS; otherwise iPhone GPS remains active. A receiver that connects during a ride deliberately takes over only on the next recording. If the active external receiver drops during a ride, ordinary ride recording falls back to iPhone GPS; a running sprint or distance attempt is interrupted so no time is interpolated across two different sensors.

The source label below the record button shows which source is actually active before and during the ride. Apple Watch is only a display and remote and does not change that selection.

The GPS indicator below the record button remains active even when no recording is running. Tap it to inspect source, sample age, position, accuracy values, speed, course, fix quality and—when using an external receiver—its battery. Only Dragy Lite also shows its selectable update rate and the satellite and pDOP values it supplies.

Green means a current position and speed fix suitable for the active source is available. Yellow indicates an existing but limited or not yet current fix. For iPhone GPS the indicator can be red or unavailable when location permission is missing or no fix exists; for a connected external receiver the compact source label remains limited while waiting for a fix. The detail view identifies whether position, speed, accuracy or freshness is missing.

A “–” means the active source does not provide that value; it is neither a numerical zero nor automatically a fault. This is normal for satellite count and pDOP on iPhone and for several individual accuracy values on XGPS. Dragy Lite supplies them when they are present in its fix. The source-specific fix check—not the sheer number of populated rows—is what decides usability.

GNSS positions are statistical estimates. Even with a stationary receiver, satellite geometry, atmospheric propagation errors and reflected signals alter the calculated position. Small position changes can therefore produce an apparent speed of a few km/h. This applies to iPhone and external receivers alike.

Track4Facts uses hysteresis: one low value does not determine standstill or motion. With iPhone GPS, consecutive speeds, displacement, horizontal accuracy and available motion information are classified together. XGPS and Dragy Lite use short time-based confirmation windows for their faster sample streams; Dragy accuracy values are additionally checked against the configured limits. Confirmed standstill is normalised to zero for display and 0–X logic, while original timestamps remain available for later interpolation.

With iPhone GPS, genuinely reported low speeds remain visible while braking even before the stop is confirmed. External receivers buffer the short transition sequence before changing state. This keeps sources with very different rates stable without treating one noisy value as a start or stop.

The 3 km/h tolerance is the same for every source, but confirmation reflects its data type and rate. With iPhone GPS, at least two low, positionally stable samples confirm the transition from motion to standstill; genuine low speeds remain visible meanwhile. XGPS and Dragy Lite confirm low values over a short time window containing several plausible samples. Only that confirmed transition increments the stop counter, produces canonical standstill and may arm another attempt.

Track4Facts requests positions continuously during recording, including at standstill. If Core Location exceptionally reports no speed, several tightly clustered iPhone positions over at least two seconds may infer standstill. This fallback may re-arm distance timing but never a 0–X sprint. External receivers instead require a valid speed fix.

Confirmed iPhone standstill points remain in the route and exports as diagnostic evidence. For high-rate external receivers, “Save every point from external receivers” controls how densely valid points are persisted; live measurement still processes the incoming stream independently.

In Settings you can follow the iPhone system units or choose Metric or Imperial. Inputs, speedometer, routes and result lists then use km/h and metres/kilometres or mph and feet/miles.

Track4Facts always stores speeds internally in km/h and distances in metres. Changing units later therefore changes presentation only, never the recorded measurements.

The quality grade describes confidence in the input data, not driving performance. Green means accuracy, sample intervals and plausibility checks remained in the good range. Yellow marks a numerically valid result with increased uncertainty due to a larger sample gap or limited fix quality. The least favourable segment quality determines the overall attempt grade.

A missing value is not a numerical zero. It means the measurement conditions were incomplete—for example target not reached, no confirmed standstill, start threshold not approached from below, data gap, rejected fix or implausible jump. Status and failure reason are stored with the ride.

Measurement uncertainty has at least two components: spatial uncertainty of position and temporal uncertainty caused by sampling rate. Plausibility filters reduce gross outliers, confirmation windows stabilise state transitions, and linear interpolation reduces the systematic rounding error that would arise if only the next GPS sample counted as the threshold. These methods improve the estimate but cannot create information the receiver did not measure.

Results still depend on reception, antenna placement, sky visibility, device and update rate. Tunnels, urban canyons, reflections and long gaps increase uncertainty. The app is not an officially calibrated instrument. For comparable attempts, keep source and mounting position constant, use similar conditions and consider the stored quality grade.

Secure the smartphone before driving without obstructing view, controls or airbags. Do not operate the app while driving. Perform performance measurements only on private property, on closed courses, or in areas expressly permitted for such driving.

Never force a measurement: safety, traffic laws, visibility, weather and traffic conditions always come first.

Start recording while stationary and wait for “Ready”. You do not need to drive first, and the stop counter does not have to show 1. It counts a later detected transition from motion to standstill and is independent of sprint readiness.

A 0–X measurement is a state machine with Waiting, Ready, Running and Result phases. It reaches Ready only after a confirmed stationary sequence within the 3 km/h tolerance. A displayed 0 km/h alone is not sufficient: a current speed fix reliable enough for the active GPS source must also be available. If “Waiting for standstill” remains visible despite 0 km/h, open GPS diagnostics. For iPhone, inspect sample age, horizontal accuracy, speed and speed accuracy; for XGPS or Dragy, also inspect source, 2D/3D fix and continuity. Individual XGPS accuracy values that are not supplied may legitimately show “–”.

On transition from the last stationary point to the first valid moving sample, the 3 km/h crossing is linearly interpolated. This t₀ is the computational start anchor, while the user-facing start remains zero. The target crossing time is estimated in the same way. Their difference is the sprint time, and the fastest valid attempt for each range is retained within the ride.

An X–Y range does not require complete standstill. It only arms after the active ride has observed a valid speed below X. This prevents a recording started above X from producing a false 50–100 result.

Timing starts when X is crossed and ends at Y. Both times are interpolated between valid GPS samples. Slowing below X later rearms the range for another attempt.

Open the range settings at the top right of the Sprint page. You can add start and target speeds, remove values and reorder the list. Start must be lower than target; duplicates and implausible ranges are rejected.

In the Full Version, every range in the list is measured on each new ride. Up to three selected ranges appear live on Sprint in list order. Without the Full Version, only 0–100 km/h or 0–60 mph is measured, depending on the selected unit; additional saved ranges remain intact and return after unlocking. Changes apply to the next ride and never alter an active or historical recording.

A range can be completed several times during one ride. Track4Facts retains the fastest valid time for each range; a slower later attempt does not replace it.

When the ride ends, every range configured for that ride is stored, including ranges whose target was never reached. This preserves what was intended to be measured.

A receiver produces discrete pairs (t₁, v₁) and (t₂, v₂). If threshold v* lies between v₁ and v₂, Track4Facts uses a linear model within that short interval: t* = t₁ + (v* − v₁) / (v₂ − v₁) × (t₂ − t₁). Using t₂ unconditionally would make threshold times systematically late depending on sampling phase.

Interpolation estimates under the assumption that speed changes approximately linearly between neighbouring, already validated samples. It reduces sampling error but removes neither GPS noise nor model error during strongly nonlinear acceleration. Large or invalid time gaps are therefore not treated as ordinary intervals.

Common causes are no stable standstill for 0–X, X not previously undercut for a rolling range, target not reached, slowing during an attempt, insufficient GPS accuracy, a sampling gap or an implausible speed jump.

Open History → ride → Acceleration times to see every range from that ride together with time, quality level or stored failure reason.

The complete lap/racing mode is part of the Full Version. After unlocking, you can capture a new course most accurately by driving a survey lap, or draw its shape with your finger. The start/finish line has a direction; only crossings in that direction count.

After saving, you can name and select the course directly next time, and edit start/finish and sectors. A saved course means you do not need another survey lap at your next track day.

The first valid crossing of the start/finish line starts timing. It is not yet a completed lap. Every following crossing in the configured direction finishes the current lap and immediately starts the next one.

Crossings less than ten seconds apart are ignored as manoeuvring or GPS artefacts. GPS gaps longer than five seconds are not bridged either, preventing a position jump from inventing a lap.

Sectors divide a saved course into sections. Place sector lines on the recorded course; the app automatically aligns each line across the direction of travel. The lines must be crossed in their configured order. The final sector runs from the last sector line back to start/finish.

While driving, the cards wrap onto additional rows whenever one row is too narrow. Green marks a new or matching sector best; red indicates time lost.

The large number is the running lap time. You also see current speed, lap count, active sector, best and last lap, and the most recently completed laps.

Once a reference lap exists, the delta compares your current time at the same point of the driven route with the best lap so far. A negative green delta means faster; a positive red delta means slower. Portrait and landscape rearrange the sector cards for the available space.

A lap receives a complete sector set only when every sector line was detected in the intended order. If a line is missed because the car deviated from the course, the line is too narrow, GPS accuracy is limited or there is a sampling gap, Track4Facts keeps the valid lap time but deliberately stores no partial sector sequence.

Check the route and gate width in the course editor. Wider gates can help with variable GPS, but should not cut across a neighbouring part of the course.

Above the list are the best lap, the theoretical best assembled from the quickest sectors, and consistency as the spread of the lap times; tapping a lap opens its comparison with the best one.\n\nThe fastest completed lap is highlighted in green. Every other lap's delta shows its deficit to that best time. Its sectors appear underneath as individual cards.

The quickest recorded time for each sector is green – it may come from a different lap than the overall best lap. A sector delta compares that card with the quickest time for that particular sector. If no complete set exists, the lap explicitly reports incomplete sector data.

Distance timing requires the Full Version and arms automatically after confirmed standstill. Time and distance begin at the interpolated standing-start anchor. A recording begun in motion therefore obtains a comparable distance attempt only after the next confirmed standstill.

For every valid interval, distance is numerically integrated from speed. In simplified terms, the app uses the area below the speed-time curve between two samples after converting speed to m/s. If a target lies within an interval, target time and target speed are determined proportionally, so 100 m or 400 m need not coincide exactly with a GPS timestamp. Returning to standstill before the target interrupts the active attempt.

All distances enabled in Distance settings are measured in parallel, regardless of the row currently selected. Selection only controls which target is shown in the large card with time, finish speed and progress.

Enabled distances beyond the selected target remain part of the ride. Timing finishes when the largest active distance is reached or the attempt is interrupted.

After each newly confirmed standstill another attempt can start automatically. For every enabled distance Track4Facts retains the fastest valid time within the active ride. Finish speed, exact clock time and GPS quality are stored with that best result.

Stopping recording writes the complete set of reached and unreached distances to the ride as a snapshot.

Open distance settings at the top right of Distance. Switches decide which split and target distances are measured in parallel on the next ride. Tap an active distance to select it for the large target card.

Under Manage custom distances you can add names and lengths. Input follows the unit chosen in general Settings and is stored safely in metres. Changes during an active recording do not alter its frozen configuration.

A time over distance is only comparable when its start is unambiguous. If ride recording begins in motion, normal trip data continues, but distance timing waits for the next confirmed standstill. It then shows Ready and starts automatically at launch.

The large card shows the fastest time for the selected target, speed at the finish and current attempt status. While driving, the bar fills according to integrated distance.

The list below shows all active split and target distances. Once reached, best time and finish speed appear; a dash means that distance has not yet been reached validly during this ride.

The Watch app can start and stop a normal ride recording on the paired iPhone. When you stop, the iPhone saves the ride without a naming dialog; you can rename it later in History.

The Watch does not currently start a configured lap-timing session. Course, start/finish and sectors are selected and started from Lap timing on the iPhone.

Before starting, the Watch shows the latest saved ride with distance, duration and top speed. While recording, speed, duration, top speed and distance take priority. A newly completed sprint from the live ranges selected on the iPhone appears as a large result card for a few seconds. When Race Training is enabled, current heart rate appears too.

After stopping, the Watch confirms that the ride was saved and shows distance, duration, top speed, average speed, completed sprint times and—when measured—average and maximum heart rate. On iPhone, History shows the heart-rate curve and, for a lap race, average and maximum heart rate per lap.

No. The iPhone remains the sole measurement and storage source. The Watch receives values from it and sends start/stop commands, so it follows the iPhone's unit and speedometer scale. The GPS source is either the iPhone itself or—with the Full Version and already connected before the ride starts—an XGPS150, XGPS160 or Dragy Lite on the iPhone. The Watch does not pair directly with the receiver.

The Watch shows “No iPhone” while there is no direct connection. A start or stop command can be queued and delivered when the iPhone becomes reachable again. Until the iPhone confirms it, do not assume recording has already started or ended.

Location permission and storage remain on the iPhone. If location is disabled there, the Watch cannot start a recording.

Race Training is optional and off by default. When enabled in Settings, the Watch starts a genuine workout alongside a normal ride recording, keeps the live view active and records your pulse. It can read heart rate and save the workout to Apple Health only after you grant Health access. Because Apple does not offer a motorsport workout type, Health lists it as an “Other” workout with the name Track4Facts Race Training. If the ride is discarded, no workout is saved either.

Timestamps align pulse values with the matching Track4Facts ride and, during a lap race, with each lap. The values stay local in the app and are excluded from exports by default. They are included in future backups and waypoint CSV files only after your separate explicit consent under Settings → Backup & Export. GPX and motion CSV always remain heart-rate free. Ride recording and the Watch remote remain fully usable without enabling it or granting Health access; there is simply no heart-rate recording and watchOS may leave the app after its usual interval. A workout uses noticeably more Watch battery.

During an active recording, the Live Activity shows recording duration, current speed, distance and top speed. It automatically follows the unit selected on the iPhone and ends with the recording.

Live Activities must be allowed for Track4Facts in iOS. If a ride is started from Apple Watch while Track4Facts is not in the foreground, iOS may initially refuse the Live Activity; opening the iPhone app adds it to the already active ride.

Enable “Announce results” in Settings. Underneath it, each kind can be switched on its own - top speed, acceleration times and lap times - and “Play a sample” speaks one example sentence for every kind that is enabled, in the current voice, without needing a drive. In lap mode, Track4Facts speaks every valid lap time, followed by whether it is the first or a new best, whether it matched the best, or how many seconds it was behind. Each lap is compared with the best time that had already been set before it.

In sprint mode, new top speeds and best times for the up to three selected acceleration ranges are still announced. Other audio is only ducked while the message is spoken. Voice and pronunciation come from iOS. A high-quality voice downloaded under Settings → Accessibility → Spoken Content will usually sound more natural.

Garage lets you create vehicles with a photo, technical specifications, colour and registration plate. One complete vehicle entry is free; additional vehicles require the Full Version. Existing or backup-restored vehicles remain visible. New recordings are assigned to the active vehicle; you can change the choice before starting. Existing rides can later be assigned to another vehicle or no vehicle.

A vehicle page combines its rides, total distance, drive time, top speed, and acceleration and distance bests. Deleting a vehicle never deletes its rides; it only removes their assignment.

Open a ride in History. The 4:5 Race Summary image and shareable vehicle card are directly available. Raw GPX, waypoint CSV and motion CSV export requires the Full Version and is only useful when the corresponding data exists.

Heart-rate data is excluded by default. If, after the warning, you explicitly enable “Heart rate in backup & waypoint CSV” under Settings → Backup & Export, only waypoint CSV receives matching time-aligned heart-rate values. GPX and motion CSV remain heart-rate free. Nothing is uploaded automatically. Data leaves the device only when you explicitly select a share or export action.

Under Settings you can save all rides including GPS and motion data, lap results, Garage and supported app settings in one .track4facts file. Heart-rate data is excluded by default and is included in future backups only after your separate explicit consent. That consent itself is neither backed up nor restored on another device. On import, included heart-rate values are stored locally with the ride; existing rides are recognised and skipped. Older backup formats remain readable.

Saved course layouts for Lap timing are not currently part of the backup file. Backup export is included with the Full Version, while an existing backup can always be imported.

Stored data includes start and end, route, valid GPS samples, speed, distance, top speed, stops and elevation values. Sprint and distance snapshots add the ride's ranges, results, quality and failure reasons. A lap-timing ride also stores completed laps and any available sector times.

All canonical values remain metric in the database. History converts them to the currently selected unit when displayed.

Tap a ride in History. Map, naming, Race Summary, acceleration times and available lap times remain directly accessible. Speed, elevation and acceleration charts, Replay, distance times, and GPX, waypoint CSV and motion CSV exports require the Full Version. The action sheet only offers meaningful analysis for data that exists in that ride.

At ride start, Track4Facts creates an immutable snapshot of the semantically relevant configuration: sprint ranges, order and selection of live values, and active target and split distances. On completion, results, quality grades and failure states are stored on the ride together with that configuration.

This snapshot principle versions the measurement definition. Later global setting changes cannot retroactively alter the semantics of historical data. Units are separate: canonical values remain metric in storage and are converted only for the current presentation.

Older rides remain readable. Existing legacy sprint values for 0–30, 0–50 and 0–100 are adapted to the new results view; unreached values stay visible as dashes.

An old ride without a distance snapshot cannot gain reliable distance times after the fact because its targets and splits were not stored. The app explicitly explains this instead of inventing values.

Replay follows the stored GPS samples along the map over time and synchronises speed and available sprint information. Marker heading is derived from a stable direction towards subsequent points. At standstill or between nearly identical points, the last plausible heading is kept so the marker does not spin erratically.

Tap a ride and choose Name ride to assign a useful title. Full Version raw-data exports are in the same action sheet. In portrait, swipe a History row to the left to delete it.

Deletion permanently removes the ride and its related GPS and motion data from the app. You can first export a complete Track4Facts backup from Settings with the Full Version; importing an existing backup always remains available.

"Theoretical" is the sum of the quickest time recorded for each individual sector of the session, regardless of which lap it came from. It is therefore not a lap that was driven but a lower bound assembled from parts already demonstrated: every sector was covered that quickly, just not in the same lap. The line under the card names the lap each best sector came from, which can be checked against the green sector tiles.

It appears only when at least two laps carry complete sector sets. A lap that missed a sector line carries no sector times at all, so it neither contributes nor blocks.

"Consistency" is the sample standard deviation of the session's lap times, given as a plus-minus figure in seconds. It describes spread, not level: two drivers with the same best lap differ here when one hit it once by chance and the other repeated it.

Two laps are plotted against distance covered, not against time. That is the only axis on which they are comparable: at 800 m both are in the same corner, at 40 s they are not. Both charts are pinned to the same span and label width so that the same metre sits at the same position in each.

The time difference at a point is the elapsed time of the compared lap minus the interpolated elapsed time of the reference lap at the same distance. That interpolation is the same one feeding the live delta while driving, so the review cannot contradict what was shown in the car.

The worst-stretch hint measures over a sliding 100 m window. Between neighbouring samples it would be a metre-and-a-half window at 25 Hz and would find noise rather than braking points; fixed tiles would split a braking zone straddling a boundary into two harmless halves.

Nothing extra is recorded for this: every lap carries its start and end time and every waypoint a timestamp, so laps are rebuilt from what is already stored - which is why sessions recorded long before this feature existed can be compared too.

A corner is not read from a track layout the app does not know, but from what the driver did: a drop in speed of at least 12 km/h that comes back up. The trace is first resampled onto a five-metre grid and smoothed over 25 metres, so the windows mean the same at 10 Hz and at 25 Hz. Corners are matched between laps by distance from the start line.

"Slowing starts" is deliberately not called a braking point. What is measured is where the smoothed speed first falls 2 km/h below the straight before it. Lifting off, drag, engine braking and gradient all slow the car as well, and smoothing plus receiver latency shift the detected onset by several metres. What is dependable is the difference between two laps, because both traces are processed identically and the systematic part cancels.

Only corners worth 0.05 s or more are listed, largest first. Differences under five metres and under 1 km/h are left out - they sit inside the noise of a GPS trace.

On a closed circuit standing still does not happen; on public roads it happens at every junction and then dominates everything else. Forty seconds at a light is not a driving mistake, and an analysis that charges it to the nearest corner is worse than none.

A standstill is fundamentally invisible in speed plotted against distance: standing still produces time but no distance, and on a distance axis it is a single point. It is therefore read out of the elapsed times. Corners and the worst-stretch search skip anywhere either lap stood still.

The header splits the gap - "36.9 s, of which 32.5 s standing, 4.4 s driving" - and a toggle takes the waiting out of the delta curve as well. It appears only when a lap actually stood still. The split can reverse the sign: a lap can be slower overall and quicker on the move than the best one, when that one simply had a shorter red light.

A tyre's grip is limited and direction-independent: whether it is spent on braking, accelerating or turning makes no difference to it. The limit is therefore approximately a circle, and longitudinal and lateral load add as vectors. Every dot is one moment of the drive; its distance from the origin is the combined demand on grip.

The shape of the cloud is the actual reading. Braking in a straight line, then turning, then accelerating out occupies only the axes - the diagonals stay empty although grip was available there. Turning while still braking and accelerating while still turning fills the circle. The app puts a figure on that as the share of loaded moments in which longitudinal and lateral load occur together.

On public roads a cross-shaped cloud is normal and no shortcoming; on a circuit the empty diagonal marks unused potential.

From the GPS track alone. Longitudinal acceleration is the time derivative of speed. Lateral acceleration follows from the curvature of the path: exactly one circle passes through three recorded positions, its radius r following from the side lengths and the triangle area (r = abc / 4A); with the speed v the centripetal acceleration is v²/r. The sign of the cross product separates left-hand from right-hand corners.

Three conditions bound the method. The three points must be at least six metres apart - a quarter second at 30 km/h is two metres, and a metre of positional noise across that describes a three-metre radius, a corner that did not exist. At low speed the time window is therefore widened rather than the sample discarded. Nothing is computed across a hole in the recording. And because real cornering load persists while wandering positional noise changes sign, the series is median-filtered over a window.

From Core Motion on the iPhone. New drives capture device acceleration, gravity direction and rotation rate. Track4Facts requests 100 Hz; the rate the device really delivers is calculated from sensor timestamps. Every 40 ms all incoming values are averaged and saved at no more than 25 Hz. This reduces high-frequency vibration and uses far less storage than the full stream, but it is not a calibrated reference measurement for individual impact peaks.

The car's longitudinal axis is estimated rather than assuming a phone orientation. In the horizontal plane it is the direction whose sensor acceleration agrees with the smoothed time derivative of GPS speed. Smoothing adapts to the actual GPS rate: repeated iPhone speed values, genuine 10 Hz data and a 25 Hz receiver are treated differently. The app also searches for up to 1.5 seconds of timing offset between motion and GPS. The relationship must meet a minimum strength and the drive must contain enough real acceleration or deceleration; a merely plausible chance fit is not enough.

For older recordings containing only total acceleration, gravity is still reconstructed per segment from the long-term average. A segment that fails the gravity, density, excitation or agreement checks is discarded; if too few segments remain, the sensor view is deliberately not shown.

New drives save a compact 25 Hz sensor series independently of the g threshold. Only older drives still depend on the storage threshold used at the time; below about three readings per second there is not enough density for a measured curve.

Missing entirely, first reason: the phone was not rigidly attached to the vehicle. If its orientation changes within a segment, the gravity and axis checks fail; a loose phone or one used during the drive would otherwise create apparent longitudinal and lateral forces.

Missing entirely, second reason: the motion trace contains too little usable acceleration, or GPS speed changes are too incomplete to establish forward direction and timing offset reliably. If fewer than six segments in ten produce a plausible axis, the app prefers to show only “Derived” rather than a chance sensor fit.

Because they are independent. One reads the path driven, the other measures what the car experienced; beyond the drive itself they share no assumption. Agreement is therefore a real check rather than self-confirmation.

The comparison is made moment by moment rather than figure against figure: the two run at different rates and pass through different filters, so their percentiles are not the same quantity. The app pairs the readings in time and states how far they vary together.

A difference is not automatically an error. Measured cornering load comes out systematically lower because the car leans in a corner and the phone leans with it, leaving part of the load in that lean. Conversely, derived cornering load becomes unreliable with weak reception. A large difference points at a phone that moved or at poor reception - which is exactly why it is named rather than hidden.