7 Mobile Sensor APIs: Positioning and Filtering

7.1 Start With the Situation

A phone reports a location, but the number may combine several radios, cached state, and motion estimates. The team must identify where the fix came from and decide how filtering can reduce noise without pretending uncertainty disappeared.

An application programming interface is the software boundary that gives the mobile app a location result. For mobile positioning, this API result still needs a source, time, and stated uncertainty.

7.2 Overview

This route traces location sources and indoor techniques, then develops tracking and filtering evidence for a defensible API choice.

This is part 2 of 2. Review Mobile Sensor APIs: Measurements and Evidence when you need the first route.

7.3 Learning Objectives

By the end of this chapter, you will be able to:

• explain where a phone location fix comes from
• compare indoor positioning evidence and accuracy claims
• apply Kalman and particle-filter reasoning without hiding uncertainty

7.4 Chapter Roadmap

Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.

7.5 Where a Location Fix Actually Comes From

The Location family above treated position as a single API call: request, get a coordinate and an accuracy field, done. Underneath that call sits a whole taxonomy of physical techniques, and knowing which one is running changes what the accuracy field actually promises.

Device mobility is fundamentally about moving through space, so localisation sits at the core of far more than turn-by-turn maps: efficient evacuation, tracking equipment or children in a safety zone, smart-building energy savings, assessing whether an office layout is being used well, auto-locking doors and computers, navigating an unfamiliar building, "is X in yet" collaboration prompts, routing to the nearest free resource, in-store retail guidance, and activity-level monitoring for elderly care all reduce to the same question: where is this device right now?

Nearly every technique below reduces to one of three underlying measurements: how long a signal took to arrive (time of flight), which direction it arrived from (angle of arrival), or how well it matches a pre-recorded map (fingerprinting). A single time-of-flight range only draws a circle of equally-possible locations around one anchor; it takes several overlapping circles, a known angle, or a signal map to collapse that circle down to a point. Reflections make this worse: multipath happens when a receiver picks up a bounced copy of a signal instead of the direct path, which is harmless for communication but "kills us in positioning," because the reflected path is always longer than the true one and drags the estimated circle outward.

Outdoors: GPS/GNSS and Cellular

GPS satellites orbit roughly 12,500 miles up (deliberately not geostationary) and each carries an atomic clock so the whole constellation shares one time reference -- the one thing a handset cannot do on its own. A receiver collects at least four of these synchronized "pseudorange" signals and solves simultaneously for its own 3D position and its own clock offset from GPS time, which is why four is the minimum and not three. That 20W satellite signal has crossed 12,500 miles of space and atmosphere by the time a phone sees it, and several error sources chip into the result before any correction is applied:

Multipath and receiver noise are the hardest of these to correct away. Assisted-GPS (A-GPS) does not change that physics; it just fetches the roughly-20-second-per-satellite ephemeris data over the phone's 3G/WiFi link instead of waiting for the satellite to broadcast it, which is why a phone gets a first fix in a couple of seconds instead of tens of seconds. Carrier-phase positioning goes the other direction, measuring the phase of the ~20cm-wavelength carrier itself instead of the coarser pseudorange code, which can reach centimeter-level positioning -- but only with an accurate initial location and a period of observing satellite movement first. When GPS is unavailable, cellular positioning falls back to whatever the phone network already has: coarse cell-of-origin registration from the handset's mandatory base-station registration (often kilometer-scale, and coarser in rural cells than dense urban ones), or network-side time-difference-of-arrival between GPS-synced base stations (U-TDoA), good for roughly 30-400m depending on multipath.

Indoors: Why It's Harder, and the Technique Menu

GPS signals do not penetrate buildings well enough to be useful indoors, which would not matter much if people spent most of their time outdoors -- they do not. Two things make indoor positioning a genuinely different problem rather than a smaller version of the outdoor one: there is no way to cheaply deploy one ubiquitous signal the way GPS blankets the sky, and the accuracy bar is far tighter. Three meters of error is more than adequate outdoors; three meters indoors does not reliably put someone in the correct room, and ten meters is close to useless. Every wall, desk, and person indoors is also a reflector, so multipath is the default condition rather than an edge case.

7.6 Reading the Fine Print on Two Indoor Techniques

Two of the indoor techniques above reward a closer look, because their headline pitch ("reuses hardware you already have" and "no clock sync needed") hides real engineering cost.

WiFi Fingerprinting: Free Hardware, Expensive Ground Truth

Fingerprinting has two phases. Offline, someone walks the space with a survey tool, manually recording signal strength from every visible access point at a grid of known positions -- building a "signal map." Online, a phone scans WiFi and builds an observation vector of (access point, signal strength) pairs, for example ((AP1,-40), (AP2,-60)). The position estimate is then whichever surveyed point is nearest to that observation in signal space, most simply by Euclidean distance:

D_i = sqrt( sum_j ( m_j - s_hat_i_j )^2 )

  m_j       = the phone's observed signal strength from AP j
  s_hat_i_j = the surveyed signal strength from AP j at surveyed point i

Return the surveyed point i that minimises D_i.
Easy to upgrade to k-nearest-neighbours (k = 3 or 4 is typical)
instead of taking only the single closest surveyed point.

The appeal is real: you are reusing signals that already exist, so there is no hardware to deploy -- "opportunistic positioning." The practical problems are just as real. Access points are placed for communications coverage, not positioning geometry, so their density and layout are often poor for triangulation. The human body absorbs 2.4GHz reasonably well -- bodies are mostly water -- so who is standing where shifts the reading (body shadowing). Environments change, so radio paths drift over time and stale survey data quietly degrades. Devices are heterogeneous, so the same physical signal reads differently on different radios. Scanning costs battery and disrupts a phone's normal radio behaviour. And there is a bootstrapping problem baked into the whole method: surveying the map requires already knowing where you are standing while you survey it, which is itself an indoor positioning problem.

Angle of Arrival: Triangulating a Bearing

If a receiver can sense direction rather than only distance, measuring the bearing to a transmitter from two or more places is triangulation. A phased array -- multiple antennas at a fixed, known spacing -- measures angle of arrival from the phase delay between antennas: a signal reaching one antenna slightly before its neighbour arrives with a measurable phase offset, and that offset gives the angle unambiguously only when the antenna spacing is half the signal's wavelength (λ/2). Get the spacing wrong and the same phase delay can map to more than one angle.

7.7 The Bat System: What a “3cm Accurate” Indoor Fix Actually Requires

The Bat system (developed at Cambridge/AT&T Research) is worth walking through in full because it shows exactly how much infrastructure sits behind a single accurate indoor fix. A base station starts a clock and emits a 433MHz radio pulse; every Bat tag in range receives that pulse at essentially the same instant (radio is fast enough that propagation delay is negligible over room distances) and immediately emits a 50Hz ultrasonic pulse in response. A dense grid of surveyed ceiling receivers times how long the ultrasonic pulse takes to reach each of them, and because the radio trigger gives every receiver the same start time, no device-to-device clock sync is needed -- only the receivers' positions have to be known in advance. The result: about 3cm accuracy, 95% of the time, in 3D.

Ultrasound earns that accuracy precisely because it is slow and stays contained by room walls -- the same property that made outdoor time-of-flight useless (nothing outdoors can afford to wait for a synced mobile clock) makes it a feature indoors, since the timing math is forgiving and a room's walls naturally bound the coverage area you have to worry about. The cost column is just as real: ultrasound needs line of sight to work at all, its slow propagation caps how often a position can be refreshed, it demands a dense grid of pre-surveyed receivers, it is not silent to everything in the environment, it is easy to jam, and dense receiver coverage across a real building is ultimately too expensive to deploy at the scale WiFi or BLE reach almost for free.

A single fix from any of these techniques -- GPS, WiFi fingerprint, Bat pulse -- is a snapshot with its own error bar. A sequence of raw fixes taken a few seconds apart, plotted for someone walking a corridor, looks jagged and physically implausible: real people do not teleport sideways and back between samples. Turning noisy snapshots into a believable, continuously updated position is a separate problem from getting any single fix -- the subject of the next section.

7.8 From One Fix to a Track: Why Filtering Matters

Every sensor measures its quantity with some accuracy, and noise creeps in no matter what is done about it. The fix is not a better sensor; it is fusing multiple measurements -- from the same sensor over time, from different sensors, and from known constraints on the system -- through a fusion algorithm that outputs a state estimate and its error, not just a number.

The naive approach of just plotting each raw position fix as it arrives fails visibly: a series of positions taken a few seconds apart for a walking pedestrian looks like an unrealistic zig-zag, doubling back and jumping sideways in ways no walking route actually does. The fix is to stop treating each reading as the truth and start treating it as evidence about an underlying state that evolves smoothly over time. Formally, a recursive filter maintains a belief -- a probability distribution over where the device is -- and updates that belief using every measurement seen so far: Bel(x_t) = p(x_t | z_1, ..., z_t), the probability of being at state x at time t given all the measurements z up to time t. Two implementation choices dominate practice: the Kalman filter, when the belief can be well approximated by a Gaussian, and the particle filter, when it cannot.

7.9 The Kalman Filter, Worked

The Kalman filter is the simplest recursive Bayesian filter, and it is used everywhere a linear, Gaussian-noise system needs tracking. It requires that the system's dynamics can be written in linear algebra (matrices), and it boils down to three equations run in a propagate-then-correct cycle:

Propagation:  x_t  = F_t x_(t-dt) + w_t     (current state, from motion model)
              P_t- = F_t P_(t-dt) F_t^T + Q_t (uncertainty grows with no new info)
Correction:   z_t  = H_t x_t + v_t          (relate the state to a measurement)

The reason this reduces to clean linear algebra is a property of the Gaussian distribution: multiply two Gaussians together and the result is another Gaussian. So every propagate-correct cycle starts with a Gaussian position estimate and ends with a new Gaussian estimate, representable by just two numbers (mean and covariance) at every step. Visually, propagation widens the estimate -- no new information has arrived, so uncertainty grows -- and correction narrows it again by multiplying in a new, sharper measurement Gaussian. That narrow-then-widen-then-narrow rhythm is the whole filter.

The Kalman filter has a real limit: it assumes the belief distribution stays Gaussian, and some constraints simply are not. Constraining a walking route to a building floorplan is the standard example -- there is no way to write "the person cannot walk through this wall" as a linear motion-model matrix. When the constraint is not linear or the belief is not Gaussian, the practical answer is the particle filter, covered next.

7.10 The Particle Filter: Propagate, Correct, Resample

Picture tracking someone walking through a building using only their phone's sensors and a floorplan. Steps are easy to spot as peaks in the accelerometer's magnitude signal, and integrating the gyroscope gives the direction change between steps -- so the raw evidence at each moment is a step event: a length and a direction.

A particle filter represents the belief about position as a cloud of weighted particles -- guesses, each with a probability -- and runs three steps every update:

Propagate:  move every particle by the measured step length and
            direction, each with its own added noise (L + noise,
            theta + noise) representing how imperfect that
            measurement is.

Correct:    given a measurement -- a GPS fix, or a floorplan wall
            a particle has walked through -- reassign the particle
            weights. Six particles starting at equal weight 0.2 each
            might become 0.4 / 0.1 / 0.3 / 0.1 / 0.1 / 0.1 after one
            particle's position agrees best with a GPS fix.

Resample:   pick particles in proportion to their new weights, using
            a cumulative-weight ("roulette wheel") selection so
            heavier particles are more likely to be kept and lighter
ones are more likely to be dropped.

Early on, with no prior knowledge of position, the filter needs many particles spread across the whole building -- the localisation phase. Once the particles converge on the right area, far fewer are needed to keep tracking -- the tracking phase -- because the problem has gotten easier. A phone- and shoe-sensor implementation of exactly this approach reached about 0.75m accuracy 95% of the time once converged: markedly less precise than the Bat system's dedicated 3cm ultrasonic infrastructure, but achieved with sensors already in a shoe and a phone rather than a room full of surveyed receivers. Particle filters are easy to implement and highly flexible -- they can absorb constraints, like a floorplan wall, that a Kalman filter cannot express -- but every particle added costs computation, results are not deterministic run to run, and too few particles gives bad or failed results while too many wastes CPU cycles for no accuracy gain.

Dead reckoning -- integrating the gyroscope to estimate heading change step by step -- has its own failure mode worth knowing: gyros carry a bias error, a small bogus offset reported even when the device is not rotating, and that bias bends the estimated heading further from the true path the longer the device runs, even though the true path is never directly observable. Periodically correcting only the position (an occasional GPS fix, say) does not fix this -- the heading keeps bending again right after the correction, because the bias itself was never addressed. The fix is to add the bias as an explicit state the filter estimates and corrects, the same way the one-axis rotation filter earlier in this chapter treats gyro rate as part of its state rather than trusting it blindly. It is the same lesson twice: a recursive filter should estimate and correct the error sources it knows exist, not just the quantity it ultimately wants.

7.11 Knowledge Check

7.12 Matching Quiz

7.13 Ordering Quiz

7.14 Solve a Noisy Station-Platform Fix

A mobile phone waits on a rail platform beside glass, steel, and a roof. Its mobile location dots jump between the track and the road. Satellite paths reflect from the station walls. Wi-Fi signals change as trains arrive. The mobile positioning API still returns one point, but that sensor reading is an estimate, not a pin in the floor.

Start with the outdoor position error table. Square each listed error before adding it. The six squared terms for mobile positioning are 2.25, 2.25, 9.00, 0.49, 1.00, and 0.25 m². Their sum is 15.24 m². The root is (\sqrt{15.24}=3.90\ \text{m}). During mobile filtering, that matches the table’s rough 4.0 m total. Simply adding the sensor errors gives 8.2 m. The stated positioning model instead uses root-sum-square.

The mobile fix also has an age. A position from 20 seconds ago can be stale. The mobile system must treat that moving-train fix as old. The filtered location record should keep its measurement time. It should also keep the named sensor source. A satellite fix and a Wi-Fi fix can have unlike errors, and one mobile filter setting should not hide that switch.

For mobile positioning, a simple position filter can calm random jumps. It cannot remove a steady map bias. During mobile filtering, if every location dot sits 12 m east, averaging keeps it east. If dots scatter on both sides, filtering may help. A walking model can reject a sudden one-kilometre leap. It must not reject a real train departure just because the speed rose.

The Bat example uses radio to start the clock. Its one-way sound pulse differs from an echo that travels out and back. A 5.83 ms sound trip covers (343\times0.00583=2.00\ \text{m}), or about 2.00 m in room air.

7.15 Summary

Mobile sensor APIs turn phones into useful IoT sensing tools when the API choice is tied to a clear measurement question. Browser APIs are valuable for visible, permissioned, scoped collection. Native mobile paths are considered when the measurement requires platform behavior or sensor access that the browser path cannot support.

A clean review record names the API, permission state, units, timestamp, accuracy or uncertainty, phone placement, validation evidence, failure handling, exclusions, and retest trigger.

7.16 Key Takeaway

Mobile phone APIs are sensor interfaces with permissions, sampling limits, privacy implications, browser support, and device-variation constraints.

7.17 Concept Relationships

The measurement question determines which phone signal matters, and the API family exposes that signal through a controlled path. Platform support and permission state together decide whether collection can proceed on a target device. Data-quality evidence then explains what the resulting reading can support. Lifecycle requirements distinguish when browser access is sufficient from when native integration is justified. The final decision record preserves exclusions, failure handling, and retest triggers, connecting an implementation choice back to the measurement claim.

7.18 What’s Next

Continue with Participatory Sensing to review contributions from many users, then practise browser workflows in Mobile Web Sensor Labs. Mobile PWA & Audio Labs extends the path into offline and audio-oriented patterns, and Mobile Sensors Assessment checks the resulting sensor and access choices.

Previous: Mobile Sensors Intro

Return to: Mobile Phone as a Sensor