Compass Calibration

The phone's magnetometer is sensitive to two error sources. Hard-iron bias comes from permanent magnets within the phone (speakers, vibration motor) and metal cases — these add a constant offset to all three magnetic axes. Soft-iron distortion comes from ferromagnetic materials that warp the field around them when the phone rotates — these scale and tilt the apparent field. Both errors accumulate as the phone is jostled and as nearby magnetic environment changes. Without calibration, your compass may point 20–60° off true heading. Phone operating systems run continuous background calibration but only succeed when you rotate the device enough. This tool gives you a deliberate check rather than waiting for ambient motion to do it.

Practical interpretation of the deviation between magnetometer and gyroscope heading after a figure-8 calibration motion: under 3° is excellent, the kind of accuracy needed for AR navigation and surveying apps; 3–7° is good and acceptable for hiking, geocaching, and casual navigation; 7–15° is mediocre and will cause noticeable drift in outdoor route-finding; over 15° means your phone needs immediate recalibration via OS settings or a stronger figure-8. The standard outdoor compass needs about 2° accuracy to be useful at 10 km distance — a 2° heading error projects to 350 meters of position uncertainty. Magnetic declination (the difference between true and magnetic north) varies by location and adds 0–20° on top depending on where you are, so most compass apps apply a declination correction from a World Magnetic Model lookup.

The Earth's magnetic field is about 25–65 μT depending on latitude. Any nearby ferromagnetic mass distorts that field locally. A laptop on the desk, a metal lamp, a refrigerator, the steel rebar in a concrete floor, or even a kitchen knife in a drawer can shift your magnetometer reading by 5–50 μT at close range. Moving across the room moves you between these distortion zones, changing your apparent magnetic heading even though your gyroscope correctly reports no actual rotation. This is why phones often instruct you to calibrate "away from electronics and metal objects" — the calibration only works well if it averages over many orientations in a roughly uniform field. Outdoor calibration in open ground always produces tighter deviation than indoor calibration.

The figure-8 motion in the air sweeps the phone through three-dimensional orientations that span all six "octants" of orientation space (the sphere of all possible phone attitudes). Hard-iron bias appears as a constant offset on the magnetic vector — the figure-8 lets the calibration algorithm fit a sphere to your magnetometer readings, and the center of that sphere is the hard-iron offset that needs subtracting. Soft-iron distortion is more complex — it warps the sphere into an ellipsoid, and the algorithm fits an ellipsoid then computes the linear transform that re-spheres it. Without a 3D motion, calibrating only by spinning around the vertical axis cannot find the vertical hard-iron component or the soft-iron tilt. The figure-8 typically takes 5–10 seconds of relaxed wrist movement.

Magnetometer readings are absolute (always referenced to Earth's field) but noisy and slow to update because the field is small. Gyroscope readings are relative (only measure rotation rate) but very fast and clean. Sensor fusion algorithms — Mahony, Madgwick, and Kalman filter variants — combine them with complementary filtering: at high frequencies (fast motion), trust the gyroscope; at low frequencies and over seconds, drift the gyroscope estimate back toward the magnetometer reading to prevent unbounded drift. The fusion runs at 100–400 Hz and produces a smooth, low-latency heading that handles both rapid turns and slow long-term stability. iOS and Android both run this fusion at the OS level using the Apple A-series motion coprocessor or Qualcomm Sensor Hub respectively.

Yes, but only with strong magnets. A typical refrigerator magnet (around 5 mT field at the surface) is too weak to permanently affect the sensor, though it will obviously throw off readings while nearby. Neodymium magnets used in phone cases or VR headsets (50–500 mT) can permanently magnetize the iron components inside the phone, creating a permanent hard-iron bias that calibration must work around. MRI machines (1.5–7 T) will absolutely destroy a magnetometer's calibration and may damage other sensors — never bring a phone into an MRI suite. Apple's MagSafe magnets (around 30 mT) are tuned to be just under the threshold for permanent magnetization. If your phone permanently shows a 50–100 μT bias even after careful calibration, a magnet has likely passed too close.

The World Magnetic Model (WMM) is the joint product of the US National Geophysical Data Center and the British Geological Survey, updated every five years (current edition WMM2025 valid through 2029). It models the geomagnetic main field as a degree-12 spherical harmonic expansion and provides declination, inclination, total intensity, and horizontal intensity at any location and date. Aviation and marine compass standards (ISO 25862 for marine compasses, FAA TSO-C-46a for aircraft) require ±2° accuracy after calibration. Phone magnetometers typically meet ±5° after calibration when far from metal. The MEMS chips themselves (Bosch BMM150, ST LIS3MDL, AKM AK099xx) follow industrial sensor standards like JEDEC JESD22 for shock survival. The Web Generic Sensor API exposes calibrated magnetometer readings already corrected by the OS for hard-iron offsets.

Heading data comes from two browser APIs. On Android, Chrome and Edge expose the Generic Sensor API (the Magnetometer, Gyroscope and AbsoluteOrientationSensor interfaces) and the tool reads a tilt-corrected, hard-iron-corrected bearing from the OS. On iOS, Safari has no Magnetometer interface but does expose webkitCompassHeading through the DeviceOrientationEvent; iOS 13 and later additionally require a one-time permission prompt via DeviceOrientationEvent.requestPermission(), which only appears after you tap Start calibration (it must be triggered by a user gesture). Desktop browsers usually have no magnetometer at all, so the tool will report that no heading source is available. All of these APIs only work in a secure context: the page must be served over HTTPS. On plain HTTP the sensor constructors throw a SecurityError and orientation events never fire, so the tool shows a clear 'requires HTTPS' message instead of silently doing nothing.

No data leaves your device. Every heading sample, statistic and export is computed in your browser using the local sensors; nothing is uploaded and there is no server-side processing. The permission prompt appears because motion and orientation sensors can theoretically be used for fingerprinting, so the browser requires your explicit consent. If you previously denied the prompt, re-enable it in settings: on iOS go to Settings > Safari > Motion & Orientation Access (or the per-site permission), then reload the page; on Android Chrome tap the lock icon in the address bar, open Permissions / Site settings, allow Motion sensors, and reload. The export files (CSV/JSON) are generated locally with a Blob download and never touch the network.

All headings are degrees on a 0–360 compass scale where 0° is north, 90° east, 180° south and 270° west, and they are magnetic headings (not corrected for declination, so they differ from true north by your local declination). The 'Sensor fusion' row is the OS compass heading that drives the needle. The 'Magnetometer' row is the raw, non-tilt-compensated atan2 of the magnetometer vector and is only an honest reference when the phone is held perfectly flat. 'Reference north' is the heading you captured by tapping Set north reference. The deviation card shows the angular difference between the live heading and your captured reference: under 3° is excellent, 3–10° acceptable, over 10° needs work. The Session statistics panel records every sample during a run and reports the sample count, the minimum, maximum and circular-mean (average) heading, and the angular spread — the spread is the single best indicator of compass noise or instability, and the whole session can be exported as CSV or JSON for a QA log.