Gyroscope Tester

Gyroscope failures are common after drops, water exposure, or solder fatigue on the sensor's BGA pads, and they often show up first as buggy AR apps, drifting maps, or auto-rotate that no longer reacts. Testing confirms whether all three axes respond, whether the values are noisy or stuck, and whether the bias (zero-rate output) is within spec. For VR headsets and drone IMUs, gyroscope health directly affects motion-to-photon latency and flight stability. For phones, a degraded gyroscope can ruin OIS (optical image stabilization), video stabilization, and pedometer accuracy. Running this tester before buying a used device or after a repair takes 30 seconds and saves expensive returns.

The browser DeviceOrientationEvent returns orientation angles in degrees (alpha 0–360°, beta −180 to 180°, gamma −90 to 90°), while DeviceMotionEvent.rotationRate gives angular velocity in degrees per second on most browsers (rad/s on some older Safari versions — always check). For a phone sitting still on a desk, rotationRate should hover near 0 ±0.5 dps; anything larger means bias drift. When you flick the phone fast, peaks of 500–1500 dps are typical. Industrial-grade gyros are quoted in milli-degrees per second (mdps) for bias and noise specs, while consumer MEMS specs are usually given in dps.

Drift comes from two sources. First, bias instability: the zero-rate output of every MEMS gyro slowly wanders due to temperature changes, mechanical stress, and electronic noise — typical consumer parts drift 10–50 dps per hour without correction. Second, integration error: if you integrate angular velocity to get angle, even a tiny constant bias accumulates linearly into a large angle error within minutes. This is why phones fuse gyroscope data with accelerometer and magnetometer readings (sensor fusion via complementary filter or Kalman filter) to anchor the orientation estimate. If you see steady non-zero readings when the device is still, that is the raw bias — apps usually subtract a calibration offset captured at startup.

The W3C DeviceOrientation spec defines alpha as rotation around the Z axis (compass heading, 0° = north), beta as rotation around the X axis (front-back tilt, +90° = screen facing up vertically), and gamma as rotation around the Y axis (left-right tilt, ±90° = laid on side). Aerospace conventions call these yaw, pitch, and roll respectively — but watch the sign and axis order, they differ between standards. For Tait-Bryan ZXY (W3C order), gimbal lock occurs at beta = ±90°, causing alpha and gamma to become coupled. For continuous rotation tracking, quaternions are preferred over Euler angles for exactly this reason. Most browser apps use Euler for simplicity since gimbal lock is rare in handheld use.

Gimbal lock happens when two of the three rotation axes align, collapsing your three-dimensional orientation to two degrees of freedom. In W3C's ZXY Tait-Bryan order, this occurs when beta approaches ±90° — the alpha and gamma rotations become indistinguishable, and small device tilts cause huge jumps in either alpha or gamma. You see this when tilting the phone fully vertical (portrait mode pointing up): the compass heading goes haywire. It is not a bug in your sensor; it is a mathematical artifact of Euler angles. Robust apps detect proximity to ±90° beta and switch to quaternion math, or simply lock the alpha value when beta is extreme. AR frameworks like ARKit and ARCore use quaternions internally for exactly this reason.

Two web APIs are used. DeviceOrientationEvent provides absolute orientation (alpha/beta/gamma in degrees) via fused gyroscope + accelerometer + magnetometer data, fired ~60 Hz. DeviceMotionEvent provides raw angular velocity (rotationRate.alpha/beta/gamma in dps) and linear acceleration. Since iOS 13, both APIs require explicit permission via DeviceOrientationEvent.requestPermission() called from a user gesture — without it, Safari silently emits zeros. Android Chrome grants access automatically on HTTPS pages. The newer Generic Sensor API (Gyroscope, AbsoluteOrientationSensor) offers higher precision but is not yet supported on iOS Safari. This tool falls back gracefully when the API is missing.

Consumer MEMS gyros are characterized by four key specs: full-scale range (typically ±125 to ±2000 dps), sensitivity (LSB/dps), noise density in mdps/√Hz (lower is better, 4–10 is consumer-grade, 0.01 is tactical-grade), and Allan variance bias instability (the floor on long-term drift, typically 10–50 dph for consumer parts, 0.01 dph for navigation-grade). IEEE 1554 and IEEE 952 define standard test procedures. The Allan deviation plot shows angle random walk (ARW) at short tau and bias instability at longer tau — this is how a hobbyist can rank two IMU chips. For comparison, an iPhone 15 gyro has roughly 0.005 dps/√Hz noise and ~10 dph bias instability, sufficient for AR but far below ring-laser gyros used in commercial aviation (0.001 dph).

Android phones and tablets in Chrome, Edge or Samsung Internet work automatically as long as the page is served over HTTPS — no prompt appears, data starts flowing the moment you press Start. iPhone and iPad on iOS/iPadOS 13 and later work in Safari but require an explicit permission grant: tapping Start triggers DeviceOrientationEvent.requestPermission() (and DeviceMotionEvent.requestPermission() for the raw rotation-rate readout), which must be answered Allow. Desktops and laptops almost never have a gyroscope, so DeviceOrientationEvent exists but only emits null values; this tool detects that within ~1.5 seconds and shows an honest 'no sensor data received' message instead of a fake 0°. In-app browsers (Facebook, Instagram) sometimes block motion permission — open the page in the real Safari or Chrome app if Start does nothing.

No. Every reading is processed entirely in your browser using the DeviceOrientation and DeviceMotion Web APIs. Nothing is sent to a server, logged, or stored — there is no account, no upload, and no analytics on the sensor stream. When you use the Record feature, the timestamped samples live only in your browser tab's memory; the Download CSV and Download JSON buttons build the file locally with a Blob and hand it straight to your device's downloads. Close the tab and the captured data is gone. This makes the tester safe to run on customer devices in a repair shop without privacy concerns.

A healthy gyroscope responds smoothly and independently on all three axes. To test alpha (Z), keep the phone flat and rotate it like a steering wheel — the alpha value and compass heading should sweep through 0–360°. For beta (X), tilt the top edge up and down — beta should swing roughly −90° to +90°. For gamma (Y), tilt left and right — gamma should move ±90°. A PASS means each value tracks your motion in real time and returns near its resting value when you stop. A FAIL looks like: an axis frozen at one number while you rotate (stuck/dead axis), an axis jumping erratically while the device is still (noisy axis), or a large non-zero rotation rate on the desk (bias drift). Press Record while you run a full flick-and-rotate sweep, then read the per-axis Range — a near-zero range on an axis you actually moved is the clearest sign of a dead axis.

Because the machine has no gyroscope. The DeviceOrientation API is implemented in desktop Chrome, Edge and Firefox for compatibility, but with no physical sensor behind it the browser only ever delivers null readings. Older or naive testers coerce those nulls to 0 and show a confident but meaningless 0°; this tool instead runs a 1.5-second watchdog and, if no real (non-null) reading arrives, stops and tells you plainly that no sensor data was received. To actually test a gyroscope you need a device that has one — virtually every modern phone and tablet — opened over HTTPS. A USB or Bluetooth external IMU will not appear here; the Web APIs only expose the built-in motion sensors.

Pressing Record while the sensor is live logs a timestamped sample on every orientation event: elapsed time in milliseconds, the three orientation angles (alpha, beta, gamma in degrees) and, when DeviceMotion is available, the raw rotation rate of each axis in degrees per second (dps). When you stop recording the tool computes per-axis min, max, average and range plus the peak absolute rotation rate, and enables Download CSV and Download JSON. The CSV (one row per sample) drops straight into Excel, Google Sheets or a Python/pandas notebook for plotting noise and bias; the JSON additionally embeds the computed stats and unit metadata. QA labs and repair techs use this to attach objective proof to a repair ticket, compare a device before vs after repair, and batch-test units numerically instead of eyeballing a needle.