How does RidePal track jumps and hangtime?

RidePal estimates airtime (hangtime) from how your phone’s accelerometer responds when you leave the ground and land. It does not rely on GPS altitude alone for the air phase—GPS is mainly for where the jump happened and how fast you were moving at takeoff.

Platform note: Live jump detection while recording is implemented on RidePal for iOS using Apple’s background-capable accelerometer recording APIs. The Android app can show jump stats on rides that include jump data (for example rides recorded on iOS). This article describes the iOS detection pipeline that produces those events.


The physics (simple version)

The app looks at the accelerometer’s combined magnitude (how strong acceleration feels in total, including gravity and motion).

SituationWhat the sensor tends to show
Phone riding normallyA steady “riding” signature while the bike and phone move together
Phone in freefall / airborneMagnitude drops compared to normal pedaling or rolling
Hard landing / impactA sharp increase around the impact

That pattern—reduced magnitude for a stretch, then a distinct landing signature—is what the detector looks for. Exact thresholds and timing are tuned inside the app and can change with updates.


How recordings are captured (iOS)

On supported iPhones, RidePal uses system-supported background accelerometer recording so data can continue when the app is not in the foreground for short stretches.

  • Each recording session uses a hardware-backed time window; very long rides can renew that window so capture stays continuous.
  • The app does not process every sample in real time on the main screen. It works through the timeline in batches (tied in part to location updates) to balance accuracy, battery, and platform behavior.

So jumps usually appear in the UI shortly after the event, not necessarily the instant you land.


Detection stages (what “a jump” means in concept)

Processing walks the accelerometer timeline through a few stages:

StageIdea
Normal ridingWatch for a sustained stretch where magnitude looks like airtime, not a single glitch
AirborneTreat the start of that pattern as takeoff; stay in this state until a landing signature or a safety timeout
LandingDetect a landing spike and lock in end-of-airtime for timing
Post-landingBrief follow-up window so rebound and chatter don’t register as a second jump

If the “airborne” phase runs too long without a plausible landing, the segment is discarded as a false trail (for example long smooth descents or sensor patterns that aren’t a jump).


What gets saved for each jump

When a candidate passes validation (see Why didn’t my jump register?), RidePal stores a jump event with:

FieldMeaning
AirtimeTime from takeoff to landing
CoordinateMap location from GPS aligned to takeoff
Speed at takeoffFrom GPS, using recent speed samples around takeoff (must look like real motion, not standing still)
Landing intensitySummary of how hard the phone registered the landing
Distance estimate (optional)A simple horizontal estimate from speed and airtime (flat-ground shorthand—not a full physics simulation)

Your unit settings (imperial vs metric) control how speed and distance are displayed.


Tips for cleaner data

Jump tracking is tested and is intended to work with your phone in a pocket (shorts or jersey—something that keeps the phone on you without flopping around). Many riders get reliable results that way.

Bike mounts (stem, bar, out-front, etc.) can work, but we’ve seen more missed or inconsistent jumps in some mount setups—often tied to stiff brackets, vibration isolation, or the phone moving differently from your body in the air. If jumps look wrong only when mounted, try a pocket run for comparison.

  • Keep the phone from slapping or bouncing freely in a loose bag or jacket; that blurs air and landing signatures whether it’s pocket or mount.
  • On iOS, turn on Track jumps (beta) on the ride start screen before you go (if it’s off, that ride won’t record accelerometer data for jumps). It’s on by default for most users.
  • After a jump, give the app a moment and keep GPS updating so the next processing batch can include the full sensor segment.

Related