Mounted on the handlebar, the phone measures in its own X/Y/Z — fixed to the case. The motorcycle, however, thinks in forward, sideways and up. Rotate the phone to landscape and its X and Y axes swap roles, and the lean angle suddenly feels “flipped”. The reason: from gravity alone the app only knows where down is — not which side is right. With a second reference this can be cleanly corrected.
Two coordinate systems that don't mean the same thing
A smartphone measures motion along three axes fixed to its case: X to the right, Y up (toward the top edge) and Z out of the screen. Rotate the phone and those axes rotate with it.
The motorcycle has its own system: forward (direction of travel), sideways (left/right) and up. And here's the crux: lean is a rotation about the longitudinal axis — the direction of travel. How far the bike leans is the angle between “up on the vehicle” and gravity. Because gravity always points to the sky, no matter how far the bike is leaned over.
The phone's case-fixed axis system. Android reports gravity as a vector pointing to the sky.
What happens in a corner
A right-hand corner means the motorcycle leans to the right. The vehicle-fixed “up” axis tilts right with it — gravity stays vertical. From the vehicle's point of view, the sky therefore moves to the left. Gravity gains a component toward vehicle-left.
Rear view: in a right-hand corner the bike leans right; the angle to gravity is the lean angle θ.
Whether the app turns that into “+right” or “−left” depends solely on which phone axis it treats as “sideways”. And that is mount-dependent — which is where the format comes in.
Portrait vs. landscape: X and Y swap roles
In both cases the screen faces the rider. What changes is only which axis points up and which points to the side.
Same mount, rotated 90°: what was “right” in portrait (X) now points up in landscape.
| Phone axis | Portrait | Landscape |
|---|---|---|
| X | sideways (right) | up |
| Y | up | sideways (right) |
| Z | toward rider | toward rider |
In portrait, “sideways” is the phone's X axis — the lean magnitude is right, only the sign has to be set the correct way round. In landscape, “sideways” is suddenly the Y axis. If the app keeps using the portrait assumption, it measures about the wrong axis: the result is both flipped and too small, because direction of travel bleeds in. That's why it feels “worse” in landscape than in portrait.
And what if you rotate it 180°?
In landscape there are two orientations exactly 180° apart: the top edge of the phone points either to the right or to the left. Can the app tell them apart? It depends on how it's mounted.
Two landscape orientations, rotated 180°: the green dot marks the top edge of the phone.
Upright handlebar mount — yes, distinguishable. When the screen is vertical, gravity points along the phone's vertical axis — and its sign tells you which side is currently up. If you derive “right” from up × forward (forward = screen normal), the side axis flips along with the rotation and keeps pointing at the real right. No extra step needed — the geometry resolves it.
Flat on the tank — no, not from gravity. When the screen lies flat, the gravity vector is identical in both 180° orientations — the rotation about the vertical is invisible. Here only a real heading reference helps: the GPS course (plus longitudinal acceleration) on pulling away makes “forward” unambiguous and resolves this case too.
Can the axes be detected automatically?
alone: No
A single gravity vector only tells you where down is — the vertical axis. Which of the two horizontal axes is “sideways” and which is “forward”, and in which direction they point, simply isn't in there physically. So a pure “zero” calibration can't reliably fix the side.
reference: Yes
Add a second piece of information and the orientation becomes unambiguous — and correctable.
| Method | What it provides |
|---|---|
| Screen normal | Screen faces the rider ⇒ out of the screen ≈ backward. Derive “sideways” from it — works the same in portrait and landscape. |
| Device orientation | Android knows whether it's portrait or landscape — the right axis is chosen per mode automatically. |
| GPS course + acceleration | While riding, the real direction of travel is measurable → axes unambiguous including sign. The most robust solution. |
Important: you don't measure lean with gravity
So far it's been about orientation — which axis sits where. For the actual lean angle in a corner there's an additional physical trap:
side force ≈ 0
In a clean, coordinated turn, centripetal force and gravity cancel out in the vehicle-fixed frame. The accelerometer then reads near zero sideways — regardless of lean angle. A lean angle from the gravity/IMU signal alone comes out too small (typically by ~15 %).
That's why the “zero” calibration only has a reference job (where is down and right, plus zeroing while stationary). The actual angle in the corner is computed by MotionRecord from GPS and the gyroscope:
- GPS lean — φ = atan(v · ω / g) from speed and yaw rate: the reliable primary method.
- Gyro roll rate — fills the fast dynamics between GPS updates (complementary filter).
- Gravity / IMU — only as a reference while stationary and going straight.
In short: the axis assignment makes sure that “right is actually right” — but the magnitude of the lean comes from GPS + gyro, not from gravity.
What this means for MotionRecord
MotionRecord takes the pragmatic route: the side axis is derived from the screen direction — orientation-independent, i.e. identical in portrait and landscape. A short “zero” step while stationary sets the vertical, the rest follows from the mount. Optionally the GPS course additionally secures the direction of travel while riding.
The result: no more awkward calibration ritual, just a single button — and a lean angle that points the right way in both mounts.
Bottom line
The “flipped” feeling isn't a sensor bug — it's geometry: phone and motorcycle speak different axis languages, and landscape rotates two of them. Gravity alone can't resolve it — but a second reference can. Once you understand that, you also see why an honest telemetry app doesn't just “show an angle”, but has to assign the axes cleanly first.