10 Lab: Mobile Web Sensor APIs
mobile web sensor labs, browser sensor lab, phone web sensors, geolocation lab, device motion lab, mobile sensor data quality
10.1 Start With the Browser Lab Story
A mobile web lab is useful when the browser record explains the question, support check, permission outcome, phone placement, reading fields, validation note, and interpretation limit. The live number is only the beginning of the evidence.
10.2 In 60 Seconds
A mobile web sensor lab is not complete because a page displays a live value. The lab is reviewable when it records what question the page answers, which browser access path was used, whether access was available, what the user allowed, how the phone was placed, what record was stored, how the reading was checked, and what the result does not prove.
This chapter focuses on browser-based mobile sensing workflows for motion, orientation, and location-style observations. The goal is not to teach a generic JavaScript tutorial. The goal is to produce evidence that a reviewer can inspect and retest.
10.3 Learning Objectives
By the end of this chapter, you will be able to:
- Plan a mobile web sensor lab around a clear measurement question.
- Record browser support, access state, user action, and permission outcome as evidence.
- Design a bounded motion or location lab record with source, units, timestamp, context, and validity state.
- Validate a web sensor reading with a known condition, repeated check, or comparison note.
- Interpret mobile web sensor results without unsupported platform, device, or continuous-collection claims.
- Decide when the lab needs troubleshooting, revision, or retest.
10.4 Quick Check: Web Sensor Lab Record
10.5 Minimum Viable Understanding
- A browser API path is part of the evidence, not just implementation detail.
- Permission denial, unsupported access, unavailable sensors, and interrupted readings are valid lab outcomes.
- A phone motion value describes the device first; placement determines what it can represent.
- A location-style record should preserve uncertainty or freshness when those fields are available.
- A lab report should include what was excluded, not only what worked.
- Retest is required when the browser path, permission flow, setup, record schema, or interpretation rule changes.
10.6 Prerequisites
Review these chapters first:
- Mobile Phone as a Sensor: phone signals, setup context, and evidence limits.
- Mobile Sensor APIs: API access paths, permission states, and support checks.
- Sensor Application Labs: lab records, validation notes, troubleshooting, and retest discipline.
10.7 Lab Scope
This chapter covers two mobile web lab patterns:
- Motion or orientation cue: the page records a bounded device movement, tilt, stillness, or placement observation.
- Location note: the page records a user-started location estimate or area note with uncertainty and freshness evidence when available.
Keep the result narrow. A browser lab can support a classroom observation or prototype evidence packet. It should not be presented as a general platform guarantee, device benchmark, compliance result, or long-running field measurement unless separate evidence is supplied.
10.8 Mobile Web Lab Flow
Start with the lab question and work toward a reviewable record. Do not start with a sensor feature list.
Use Figure 10.1 as a checklist:
- State the question and the phone signal needed.
- Identify the browser access path and support state.
- Start access through a visible user action.
- Record permission or access outcome.
- Collect a bounded reading with setup context.
- Store the record with source, units, timestamp, and validity state.
- Validate the reading against a known condition or comparison.
- Interpret narrowly and name the retest trigger.
10.9 Browser Support And Permission Evidence
A mobile web sensor lab should record access evidence before interpreting readings.
Include:
- Access path: which browser API or page feature was used.
- Support state: available, unavailable, unsupported, blocked, or not checked.
- User action: the button, page action, or lab step that requested access.
- Permission outcome: granted, denied, dismissed, interrupted, or unknown.
- Reading state: fresh, stale, missing, rejected, or accepted.
- Fallback: what the lab records when access does not produce a usable reading.
If the browser cannot expose a permission state directly, record the observed outcome and the user-facing state shown by the page. Do not infer that access is available just because the code path exists.
10.10 Motion Or Orientation Cue
A motion lab should answer a bounded question such as:
- Did the phone remain still during a short setup check?
- Did the phone tilt in the expected direction during a controlled movement?
- Did the page record a repeatable device-placement cue during the lab?
Evidence to capture:
- phone placement, such as hand-held, table, pocket, mount, or unknown;
- axis or orientation convention used by the record;
- source and units reported by the browser path;
- start and stop condition for the collection window;
- known condition, such as still on table or deliberate tilt;
- rejected readings and the reason they were rejected;
- interpretation limit, such as “device tilt was observed” rather than “the user performed an activity.”
Avoid fixed-rate or device-wide claims unless the lab records event timing and shows that the claim was observed in that run.
10.11 Location Note
A location lab should answer a bounded question such as:
- Where did the learner create this inspection note?
- Was the note created inside the named lab area, based on the available location estimate?
- Was the location estimate fresh enough for this lab decision?
Evidence to capture:
- user action that requested the location estimate;
- permission outcome and unavailable states;
- coordinate or area label used by the record;
- uncertainty, accuracy, or freshness field when available;
- timestamp and record identity;
- comparison note, such as expected area, map label, or manual location note;
- interpretation limit, such as “supports a location note” rather than “proves continuous presence.”
The lab should still produce a reviewable record when location access is denied. A manual area note, denial state, and timestamp can be better evidence than a blank report.
Phoebe’s Why
Every location fix starts life as a radio-power or radio-timing measurement, and both are corrupted by the same geometry. An isotropic transmitter spreads its power over a growing sphere, so received power falls as \(1/d^2\) – that is Friis’s free-space law, and it is the clean case: a satellite ranging signal in open sky. Indoors, the phone instead compares Wi-Fi and cell signal strengths against a location database, and there the \(1/d^2\) law breaks down – walls, floors, bodies, and reflections make power fall faster and less predictably than free space, which is why engineers replace the fixed exponent 2 with a measured exponent \(n\) that can run past 3. A bigger, less certain \(n\) turns a small distance error into a large power-reading error, and the database inverts that noisy power reading back into a distance – which is exactly why the browser hands back a big accuracy circle instead of a point.
The Derivation
Power spreads over a sphere of radius \(d\):
\[S = \frac{P_t}{4\pi d^2}\]
giving free-space path loss
\[\mathrm{FSPL} = \left(\frac{4\pi d}{\lambda}\right)^2\]
Real, obstructed paths are modelled by replacing the exponent 2 with a measured path-loss exponent \(n\), referenced to a close-in distance \(d_0\):
\[\mathrm{PL}(d) = \mathrm{PL}(d_0) + 10n\log_{10}\!\left(\frac{d}{d_0}\right)\]
A receiver only resolves a signal if received power clears its sensitivity floor by the fade margin \(M\):
\[M = P_t - \mathrm{PL}(d) - P_{\mathrm{sens}}\]
Because \(\mathrm{PL}\) climbs with \(n\), the same physical distance costs far more dB indoors than in free space – and every dB of unmodelled loss is read by the position solver as extra, uncertain distance.
Worked Numbers: GPS Versus the Indoor Fallback
- GPS ranging (free space, \(n=2\)): using \(c = 3.00\times10^{8}\) m/s and the L1 frequency \(f = 1575.42\) MHz, a satellite at the standard \(d \approx 20{,}200\) km GNSS altitude gives \(\mathrm{FSPL} = 20\log_{10}(4\pi d/\lambda) = 182.497\ldots\) dB, i.e. 182 dB to 3 s.f. – a huge but predictable loss, which is why GPS achieves the chapter’s “few metres” outdoors.
- Timing resolution, not power: GPS actually ranges on travel time, not received power. The C/A code chips at 1.023 Mchip/s, so one chip lasts \(T_{chip} = 1/1.023\times10^{6} = 0.978\ \mu\)s, corresponding to \(d_{chip} = cT_{chip} = 293\) m of range per chip. A correlator that resolves timing to about 1% of a chip – typical for a consumer receiver – reaches \(\approx 2.93\) m of ranging resolution, matching the chapter’s “few metres” claim directly.
- Indoor Wi-Fi/cell fallback (\(n\) unmodelled, typically 3-4 indoors): the chapter’s own examples – a 25 m accuracy circle against a 5 m question, and a 40 m circle against a 10 m distinction – are 5x and 4x too coarse respectively. That gap is the signature of the log-distance model: an indoor \(n\) of 3-4 (versus free space \(n=2\)) means the same physical distance change costs 1.5-2x more dB, so the position solver’s implied distance uncertainty grows well past “tens of metres” once walls and floors are added.
The physical takeaway matches the chapter’s own rule: an accuracy radius is not noise to discard. It is the fade margin and path-loss exponent talking – narrow and predictable for a free-space GNSS fix, wide and database-dependent for an indoor RF fallback.
10.12 Data Record For Review
The record schema should make the reading inspectable after the phone is no longer in front of the reviewer.
Use Figure 10.2 to check whether a submitted lab result can be reviewed later.
Every accepted record should include:
- Question: the lab decision or observation.
- API path: the browser access path or fallback.
- Access state: granted, denied, unavailable, unsupported, interrupted, or unknown.
- Source: motion, orientation, location, user note, or derived feature.
- Units: coordinates, acceleration units, angular units, relative value, or text note.
- Timestamp: collection time or record time.
- Setup context: placement, user action, page state, and collection window.
- Validation note: known condition, comparison, repetition, or plausibility check.
- Validity state: accepted, rejected, stale, missing, or needs retest.
- Interpretation limit: what the record supports and what it excludes.
10.13 Worked Review: Motion Setup Check
Scenario: a learner builds a phone page that records a short stillness check before a larger sensor exercise.
Question
Was the phone still on the table during the setup check?
Browser access evidence
The lab records the motion access path, observed support state, user action, and permission outcome. If motion readings are unavailable, the report stores an unavailable state instead of inventing a reading.
Setup context
The phone is placed flat on the table before collection. The report records placement, start condition, stop condition, source, units, and timestamp.
Validation note
The learner repeats the stillness check and compares the readings with a deliberate movement check. The report keeps both accepted and rejected states.
Interpretation
The record supports the narrow statement that the device was still during the setup check. It does not prove that the surrounding system was stable or that the user remained still.
Retest trigger
Retest if the browser path changes, the phone placement changes, the record schema changes, or the lab uses the same reading to support a broader claim.
10.14 Troubleshooting And Retest
Use troubleshooting to improve the evidence record, not to force a successful reading.
Review these states:
- Unsupported: the page explains that the browser path is not available and records the unsupported state.
- Denied: the lab preserves denial as an outcome and offers a manual note where appropriate.
- Interrupted: the record shows that collection started but did not finish.
- Stale: the timestamp or freshness evidence does not match the lab question.
- Ambiguous: setup context is missing or the validation note conflicts with the reading.
- Changed: browser path, permission flow, phone placement, or record schema changed after the last accepted run.
Retest after any changed state that affects interpretation.
10.15 Common Mistakes
- Treating a live value on a page as a complete lab result.
- Omitting browser support or permission outcome from the report.
- Ignoring denied, unavailable, interrupted, stale, or rejected states.
- Claiming that phone motion always represents the user’s activity.
- Reporting a location estimate without uncertainty, freshness, or fallback context.
- Turning the lab into a code listing instead of an evidence record.
- Reusing old readings after the setup, permission flow, or interpretation rule changes.
- Linking to broad web resources instead of documenting the lab result.
10.16 Practice Without a Phone
Before the exercises below, run the two lab patterns yourself. The explorer is a simulated phone: it produces every value from a stated model, so you can rehearse the deviceorientation and Geolocation workflows, and the permission flow, without a physical device.
Run it: Set the orientation angles and read the exact alpha, beta, and gamma a deviceorientation event would deliver, plus the static-gravity vector the same pose would place on the accelerometer. Then switch to Geolocation, request a fix, walk the permission prompt, and decide whether the metres accuracy radius is smaller than the distance your task must resolve. Use what you observe to answer the checks that follow.
10.17 Knowledge Check
10.18 Matching Quiz
10.19 Ordering Quiz
Sensors Arrive as Browser Events
In a mobile web lab, the phone's motion and location reach your code as events, not function returns. The deviceorientation and devicemotion events fire repeatedly with tilt and acceleration; the Geolocation API delivers a position with an explicit accuracy. Each is a real sensor behind a permission gate, and each reports in a specific frame with a specific uncertainty you must respect.
The two most useful facts about any of these readings are its frame (relative to what?) and its uncertainty (how sure?). A tilt angle is meaningless without knowing which axis it turns around; a location is useless without its accuracy radius. The Web APIs hand you both — if you read them.
Intuition: the browser is a translator between the phone's sensors and your JavaScript. It speaks in events and always attaches a "here is how sure I am" note — the accuracy — that beginners often ignore and experts always check.
A useful mobile web lab therefore records the browser pathway, not just the final number. For motion and orientation, the page should name the event type, the axis convention, the collection window, and whether the values were accepted or rejected. For location, it should name the permission outcome, the timestamp, the reported accuracy radius, and whether the fix was fresh enough for the lab question. The same physical phone can produce a valid classroom cue in one setup and an unusable record in another if that context is missing.
Motion readings also describe the device before they describe the user or the environment. A tilt event can support "the phone rotated around its left-right axis during this 3 second window" when the phone placement is known. It does not automatically support "the person performed this activity." The lab must connect the event stream to a bounded setup, such as still on table, tilted by hand, mounted on a cart, or placed at a named inspection point.
Overview Knowledge Check
Orientation Angles and a Location's Radius
Device orientation arrives as three Euler angles, and location as coordinates plus a radius:
deviceorientation event:
alpha : rotation about z (compass heading), 0..360 deg
beta : front-back tilt about x, -180..180 deg
gamma : left-right tilt about y, -90..90 deg
devicemotion event: acceleration, accelerationIncludingGravity,
rotationRate, and interval (actual period)
geolocation: coords.latitude, coords.longitude, coords.accuracy (metres)
Worked example: is this fix good enough?
A getCurrentPosition callback returns:
coords.accuracy = 25 (metres)
This means the true location is likely within ~25 m.
- Geotagging a neighbourhood observation? Fine.
- Deciding which side of a 5 m-wide path you are on?
Impossible: 25 m uncertainty dwarfs a 5 m question.
Gate the logic on accuracy: reject or re-request the fix
when coords.accuracy is larger than the task needs.
The same discipline applies to motion: use the interval field for the true sample period rather than assuming a fixed rate, because event delivery timing varies by device and browser.
For a motion setup check, the arithmetic is simple but important. If the browser reports an event interval near 40 ms, a 3 second window contains about 75 readings. If the lab accepts the setup only when the phone remains within a small tilt band, the report should say which angles were checked, the threshold used, and how many readings were inside or outside the threshold. A single screenshot of one live value does not prove stability; a bounded window with accepted and rejected readings does.
For a location note, compare the reported radius with the decision being made. A 25 m accuracy may be enough for "near the engineering building" but not for "which side of a 5 m-wide path." If the lab question needs a tighter distinction, the page can request a new fix, set enableHighAccuracy, reject stale values with maximumAge, and report a timeout or denied state instead of pretending the weak fix answered the question. The result should be an honest record of the browser outcome.
When students submit the lab, review the record fields in pairs: value plus units, timestamp plus freshness, placement plus axis convention, permission state plus fallback, and validation note plus interpretation limit. Those pairings prevent the common error of treating a moving display as evidence by itself.
Practitioner Knowledge Check
How the Position Is Actually Found
That single accuracy number hides two very different positioning technologies, and which one produced your fix explains almost everything about its quality.
GNSS trilateration
GPS, Galileo, GLONASS, and BeiDou satellites are located by the travel time of their signals. With a clear sky view this gives a few metres of accuracy outdoors, but it needs line of sight to satellites.
Wi-Fi and cell positioning
The device looks up nearby Wi-Fi access points and cell towers in a location database. This works indoors and returns quickly, but it is coarser — tens to hundreds of metres — and that is why an indoor fix has a large accuracy radius.
Multipath degrades GNSS
In urban canyons, signals bounce off buildings and arrive late, so the computed position wanders. A large accuracy value in a city street is often multipath, not a broken sensor.
Permissions and secure context
These APIs require HTTPS and user consent; on iOS, motion/orientation need an explicit requestPermission() call from a user gesture. Consent can be revoked at any time, so handle the denied and unavailable cases.
Browser APIs deliberately sit between the page and the hardware. The page may not know whether a position came from GNSS, Wi-Fi, cell towers, or a cached estimate, but it can read the fields the browser exposes: accuracy, timestamp, age policy, timeout behavior, permission outcome, and error code. A reviewable lab uses those fields as evidence. It does not reverse-engineer a hidden sensor path or claim precision that the browser did not expose.
Motion and orientation have a similar boundary. Browser vendors may rate-limit events, require a user gesture, pause events in background tabs, or quantize values to reduce fingerprinting risk. That is why a lab should record the observed interval and unavailable states instead of promising a fixed sample rate across phones. If the phone, browser, OS version, or permission flow changes, the retest trigger should fire because the event stream may change even when the code did not.
The strongest implementation treats failure states as data. Unsupported API, denied permission, timeout, stale cached location, coarse accuracy, interrupted tab, and rejected validation condition all belong in the same record schema as accepted readings. That makes the lab useful on real devices, where absence of a reading is often the most important result.
So the accuracy radius is not noise to be discarded — it is the API telling you whether it used satellites or a database lookup, and whether the sky was clear. A robust mobile-sensing lab reads that radius on every fix, sets enableHighAccuracy when it needs GNSS, and never treats a location as a point when it is really a circle.
Under-the-Hood Knowledge Check
10.20 Summary
Mobile web sensor labs are useful when they produce inspectable evidence, not just a working page. A good lab connects the measurement question to a browser access path, records permission and support state, captures setup context, stores a clear data record, validates the reading, and states interpretation limits.
The safest review habit is to preserve unsuccessful states. Denied, unsupported, unavailable, interrupted, stale, and rejected readings help the learner explain what happened and decide whether to fallback, revise, or retest.
10.21 Key Takeaway
Web API labs should prove the permission flow, sensor availability, sampling reliability, error handling, and user feedback across target devices.
10.22 Concept Relationships
- Measurement question determines which browser sensor path matters.
- Browser support state controls whether the lab can collect a reading through the chosen path.
- Permission outcome explains whether user-granted access exists for the run.
- Setup context determines what the phone reading can represent.
- Data record preserves source, units, timestamp, identity, and validity state.
- Validation evidence checks whether the reading is plausible for the question.
- Interpretation limit prevents overclaiming from a narrow phone reading.
- Retest trigger keeps the lab current after access, setup, schema, or interpretation changes.
10.23 What’s Next
Continue to Mobile PWA & Audio Labs for installable web app and microphone-based lab patterns. Use Mobile Sensors Labs to review the mobile lab sequence as a whole, or return to Participatory Sensing when many people contribute phone-based records.