Gyroscope vs Accelerometer in Phone Shake Games
The accelerometer and the gyroscope sit side by side on every modern smartphone motherboard, often inside the same Bosch BMI270 or InvenSense ICM-42688 chip package. They sample different physics, fire at different rates, and produce different errors. A phone shake game that treats them as interchangeable will miss inputs on Android and false-fire on iPhone within the first ten rounds of a party. The pair only behaves predictably once you understand which one answers which question, and how their outputs get fused into a single shake decision. Our sensor fusion layer rides on top of both signals, calibrated against 412,000 motion events from the public beta in May 2026.
What the Accelerometer Measures
The accelerometer reports linear acceleration along three axes in meters per second squared. At rest, a phone face-up on a table reads roughly 0, 0, 9.81 because gravity pulls down through the Z axis. Shake the phone and the magnitude spikes between 15 and 40 m/s² depending on wrist snap intensity. The chip itself is a MEMS device, a tiny silicon proof mass suspended on flexures that flex under acceleration and change capacitance against a fixed plate. Bosch's BMI270 in the Pixel 8 samples at up to 1.6 kHz, while Apple's custom IMU in the iPhone 15 publishes to Core Motion at a default 100 Hz with a 400 Hz ceiling. The cost of polling at the top rate is battery draw of about 0.8 mW, which is why our shake threshold tuning build log keeps polling high even on three-hour party sessions.
What the Gyroscope Measures
The gyroscope reports angular velocity in radians per second around the same three axes. A phone tilted from flat to vertical sweeps through roughly 1.57 rad/s if the motion takes one full second to complete. The MEMS gyro uses a vibrating mass that experiences Coriolis force when rotated, and the chip translates that force into a voltage signal. Gyroscopes drift: bias error accumulates at 0.5 to 2 degrees per second over a five-minute session if you integrate the raw readings naively. The gyroscope's value comes from catching rotational flicks that the accelerometer underreports by design. A wrist twist around the long axis of the phone moves the device only 3 cm linearly but rotates it 120 degrees, an event the accelerometer logs at maybe 6 m/s² and the gyro logs at a clean 6 rad/s spike.
Accelerometer alone catches the magnitude. Gyroscope alone catches the twist. Fused together they catch the shake and ignore the couch drop.
Why Shake Games Need Both Sensors
A pure accelerometer trigger fires on any axis crossing a magnitude threshold, which means dropping the phone on a soft couch from waist height produces a 22 m/s² spike and a false shake. A pure gyroscope trigger ignores translation entirely, so a player pumping the phone up and down in a straight piston motion logs almost no rotation and never registers a round input. Fusing the two readings cuts both error modes at once. The combined rule reads as: count a shake when accelerometer magnitude exceeds 11 m/s² AND gyroscope magnitude exceeds 2 rad/s within a 120 ms window. That AND gate dropped the false-positive rate in our beta telemetry from 14% on accelerometer-only logic to 0.8% on the fused trigger across 41,200 rounds.
The fusion layer still has to resolve these edge cases without dropping legitimate inputs:
- Phone flat on a table during music playback: subwoofer vibration spikes the accelerometer to 18 m/s² at frequencies between 40 and 80 Hz, but the gyro stays under 0.3 rad/s, so the AND gate rejects it cleanly.
- Player handing the phone across a table: linear motion of 6 m/s² over 800 ms with rotation of 1.2 rad/s, both readings below thresholds, correctly ignored.
- Genuine wrist-snap shake: 28 m/s² peak paired with 4.5 rad/s rotation inside a 90 ms window, both above thresholds, counted as one input.
Hardware Differences Between iPhone and Android
Sensor specs split the market in two ways that matter for round design. Apple ships a single IMU package across each generation, so an iPhone 13, 14, and 15 all behave within 4% of each other on shake magnitude readings. Android ships 47 different IMU part numbers across the top 30 devices by market share in 2026. The range runs from the InvenSense ICM-20690 in the Galaxy A15, which defaults to 200 Hz with a 4 mg noise floor, to the Bosch BMI323 in the Pixel 9, which defaults to 1.6 kHz with a 0.7 mg noise floor. That spread shows up in real games: an Android phone with the cheaper IMU sees its first shake registered 28 ms later on average than an iPhone 15 in the same player's hand. Our iPhone vs Android comparison has the full per-device latency table. The shake-detection layer reads the IMU model on app start and applies per-chip calibration offsets pulled from a 612-row lookup table.
What This Means for Round Design
Round timing has to account for the slowest device that might join the lobby. We cap the per-shake decision window at 180 ms, which leaves 60 ms of headroom above the slowest IMU we have profiled in production. Round length scales with player count: a 6-player round runs 9 seconds of active shake time, and a 12-player round runs 14 seconds, both numbers picked so the median shake count lands between 18 and 24 inputs. Haptic confirmation fires 12 ms after the shake-detect callback, a tight loop documented in our haptic feedback post, which keeps the player's perceived latency under the 100 ms threshold where humans start to feel input lag. The fused sensor model also opens game modes the accelerometer alone could not support. Rotation-only mini-rounds, where players twist the phone without lifting it from the table, run cleanly on the gyro signal with the accelerometer demoted to a noise gate role.
Stop reading. Start shaking.
Five stages. One climax. Free in your browser, free on Android — voice packs optional.
Play ShakeGasm now
