Each team measures the three vertices — sensitivity, dynamic range, bandwidth — of its own phone
Design note · v0.3 (draft) · 2026-06-17 · CC BY 4.0 · Local Stewardship: U. Warring, Freiburg
Identity card. A working design for the first tutorial of a two-part metrology arc in Sensing 2026 (https://uwarring82.github.io/sensing-2026/) — the prequel to the consensus-g capstone (tutorial-consensus-g.md). Before trusting the phone to measure anything, each team characterises its own accelerometer: it measures the three vertices of Anchor 1 · the trade-off triangle — sensitivity (resolution), dynamic range, and bandwidth — shows they trade against one another, and the cohort compares a population of the same sensor type. Same sensor type, same phones, same self-assessed ethos. This is a deliberation record, not a student brief. Follows the Stele Blueprint document patterns.
- Consolidated: for a single live slot, the triangle and consensus-g are merged into tutorial-merged.md (which uses the vendor calibration to read g from the static accelerometer). This note remains the detailed characterisation background and the two-slot prequel.
- Resolved: this is Part 1 of a sequence (characterise → measure → consensus), the prequel to consensus-g; sensor = accelerometer; "sensitivity" = resolution/noise floor (not responsivity); ≥2 distinct devices per team; self-assessment, no rubric; cohort deliverable = agreed protocol + device-population scatter (device- and method-defined values, no shared external constant); bandwidth = required sample-rate/jitter + aliasing attempt, −3 dB sweep a shared-hardware stretch; dynamic range = declared full-scale (OS/datasheet) by default, live saturation optional and gentle-only; one shared driver for any quantitative sweep.
- Open: only the prep-vs-live split under the one-slot contingency (mirrors the capstone's open split — see Place in the arc).
- Not built: student brief, an adapted result-card schema. (The consensus-g schema and self-assessment transfer with edits.)
Each team measures where its own accelerometer sits on the trade-off triangle — its smallest resolvable acceleration, its largest before clipping, and the frequency band over which it responds faithfully — demonstrates that pushing one vertex costs another, and the cohort confronts how much "an accelerometer" actually varies across nominally-similar phones and how much each number depends on how you chose to define it.
This is Anchor 1, made real on a device in the student's hand — arguably the tightest anchor-to-tutorial fit in the course. It also pulls in:
- Anchor 2 · noise & Allan — the sensitivity floor is a noise measurement (PSD / noise density / Allan deviation), and the sensitivity↔bandwidth trade is the averaging story.
- Anchor 3 · SQL 1/√N — averaging improves resolution as 1/√N until the floor.
P3 Greek band: the same phone everyone is already holding — now turned on itself.
A two-week metrology arc: Part 1 — characterise the instrument (this) → Part 2 — measure a shared quantity and reach consensus (consensus-g). The order is the point. Having felt that the accelerometer's amplitude is calibration-limited, noisy, and definition-dependent, students arrive at Part 2 understanding why it routes the measurand onto the clock (timing) and uses the accelerometer only as a phase marker — the design choice is earned, not told. They also carry real knowledge of timestamp jitter, delivered sample rate, the noise floor, aliasing, and app settings instead of a black box, so the inter-team spread in Part 2 reads as continuation rather than ambush.
One-slot contingency. If only one live tutorial slot exists, keep consensus-g as the live event (it has the stronger cohort drama) and compress Part 1 into prep / a pre-lab — at minimum the aliasing attempt and the noise-floor measurement, so the black box is still opened.
1 · Sensitivity = resolution (smallest detectable acceleration). Record the accelerometer at rest and quantify two floors:
- Quantisation (LSB): the discrete steps in the static trace — the least-significant bit.
- Noise: the RMS scatter, better its noise density (µg/√Hz) from the PSD, or the Allan deviation vs averaging time. Report the resolution over a stated bandwidth — it is meaningless without one.
Boundary [P4]. "Sensitivity" has two meanings: (a) responsivity / scale factor (output per unit input) and (b) smallest detectable signal / resolution. The trade-off triangle means (b). Declare which you report; this tutorial means (b).
2 · Dynamic range. Default to the declared full-scale from the OS / sensor datasheet for
a_max (phone MEMS is often ±2 g, sometimes ±8 g, frequently OS-fixed), and
DR = a_max / a_floor, reported linearly and in dB (20·log₁₀). Optionally, observe live
saturation if it appears — the reading flat-tops at a_max — using only gentle, standardised
impulses (a soft object dropped from a fixed low height, e.g. 10 cm, onto the phone resting on foam).
Safety boundary. No phone-throwing, no hard-surface drops, no tools, no destructive testing. Required hard tapping was the most fragile part of the first draft — hence full-scale-by-declaration is the default and live clipping is optional. Reproducibility, not violence.
3 · Bandwidth. The band over which the sensor responds faithfully — bounded by the delivered
sample rate (Nyquist = f_s/2) and any internal anti-alias filter. Three probes, increasing in
hardware cost:
- Sample rate + jitter (required, universal) — from the timestamps, measure the actual
delivered rate and its stability; the requested rate is often not what you get. Nyquist (
f_s/2) caps the band. - Aliasing attempt (required, universal, no special hardware) — drive a vibration above Nyquist and look for a fake low-frequency tone. Both outcomes are results: a fake tone shows the bandwidth limit directly; suppression (no alias appears) shows the anti-alias filter did its job. Cheap, vivid, and the result students remember.
- Frequency response −3 dB sweep (stretch, shared hardware) — rest the phone on the one shared loudspeaker / shaker playing a sine sweep and find the −3 dB roll-off; or impulse (tap) → FFT → read the flat passband. Run as a shared/room resource so bandwidth scatter reflects devices, not who had the loudspeaker.
Students must demonstrate at least one edge, not merely assert it:
- Sensitivity ↔ bandwidth. RMS floor = (noise density)·√(bandwidth). Halve the band (lower sample rate, low-pass, or average) → resolution improves by √2. Show resolution falling as 1/√N with averaging window, flattening at the Allan floor. Note this demonstrates the readout (acquisition) bandwidth vs resolution trade you control in software — not necessarily an on-chip MEMS design trade-off; say which you mean.
- Range ↔ sensitivity. For fixed ADC bits, a larger full-scale → coarser LSB → worse
resolution; ideal
DR(dB) ≈ 6.02·N_bits + 1.76, noise-limited in practice. Teams that can switch full-scale can show this directly. - Bandwidth ↔ range. Wider band → more in-band noise → smaller noise-limited dynamic range.
All three edges run through the noise floor — which is why you cannot max all three.
This is the structural difference from the capstone task, and the reason it is a genuine complement rather than a reskin:
| consensus-g (sibling) | sensor triangle (this) | |
|---|---|---|
| measurand | one external constant (local g) | the instrument itself |
| is there a true value? | yes — the cohort converges on it | no shared external constant — each device has a real transfer function under a declared method |
| cohort lesson | combining discrepant estimates → key comparison, dark uncertainty | reproducibility & method-dependence of a characterisation → round-robin / method validation |
Both are core metrology; they are complementary. Here the deep lesson is that "bandwidth" is not a property until you fix a definition and a method — three teams measuring the same phone three ways get three numbers, and that is not error, it is under-specification.
Each team has ≥2 distinct phones. Characterising both in prep already shows device spread: same-model units should agree; different models should differ in ways the datasheets predict. The "agreement ≠ accuracy" trap from the sibling task maps to a sharper one here: your method choices (which −3 dB convention, which clip threshold, which noise bandwidth) may drive your numbers more than the device does — and that is invisible until another team measures differently.
Prep (spaced week): build + validate the measurement/analysis routine on the team's own phones; arrive with a measured triangle per device and the method used to define each vertex.
| min | activity |
|---|---|
| 0–10 | each team posts its measured triangle and the definition/method per vertex — pre-registered, before seeing others |
| 10–30 | where definitions diverge (especially bandwidth), agree a common protocol; re-measure in the defined environment |
| 30–45 | assemble two cohort scatters — one from the universal probes (device spread), one from the shared-hardware sweep (method/hardware spread) — so the two are separable |
| 45–55 | explain each spread: datasheet (manufacturing) vs OS/driver config (sample-rate caps, fixed full-scale) vs measurement method — which dominates where? |
| 55–60 | compare to datasheet specs; debrief → one cohort logbook entry |
Characterising a sensor means stating the conditions of the characterisation: the ambient vibration floor (a static "noise" trace also captures footsteps, HVAC, traffic — so sensitivity is environment-limited unless you isolate on foam / a quiet surface; measuring the room's own vibration is part of the task), the drive rig (which speaker/shaker, how mounted), the agreed sample-rate setting, and temperature. Pinning these is metrology, not bookkeeping.
Self-assessed, like the sibling task. Five honest logbook checks, each marked solid / partial / not-yet with one line of evidence:
- Consistency. Do your two phones' triangles agree where they should (same model) and differ where expected (different model)? Can you explain each difference?
- Declared method. Did you state how you defined each vertex (the −3 dB convention, the clip threshold, the noise bandwidth)? A bandwidth number without a method is not a result.
- The limiting physics. For each vertex, what physically sets it — ADC bits, intrinsic noise, the anti-alias filter, an OS sample-rate cap, the ambient vibration? Can you point to it in your data?
- A demonstrated trade-off. Did you show an edge of the triangle (e.g. resolution improving as 1/√bandwidth), not just assert it?
- Calibrated surprise. Did you see aliasing above Nyquist, and did it match prediction?
Well done if every vertex carries a stated method and a named limiting cause, and you demonstrated at least one trade-off. Poorly if you report three numbers with no method and no mechanism.
Typical phone MEMS accelerometer (Bosch / STMicro / InvenSense class): full-scale ±2 g (often
OS-fixed; sometimes ±8 g), noise density ~100–300 µg/√Hz, app-delivered sample rate
~100–500 Hz (→ Nyquist ~50–250 Hz), noise-limited dynamic range ~60–70 dB. Distinguish the
theoretical DR from bit depth (≈ 6.02·N + 1.76 — ~96 dB for 16-bit) from the noise-limited
DR you actually measure: they can differ by 20–30 dB, and which one a spec sheet quotes matters.
These are indicative; Android can report the sensor vendor/part — look up the actual datasheet
before treating any number as authoritative.
- Sequence, not alternatives — this is Part 1 (prequel). Characterise the instrument here; measure & reach consensus in consensus-g. One-slot fallback: consensus-g stays live, Part 1 compresses to prep (keep at least the aliasing attempt + noise floor).
- Sensor = accelerometer, same type across teams (preserves the device-population comparison).
- "Sensitivity" = resolution / noise floor, over a stated bandwidth — not responsivity (dual meaning flagged as a boundary, not left ambiguous).
- ≥2 distinct devices per team — seeds the device-population spread directly.
- Self-assessment, no rubric (transfers from the capstone).
- Cohort deliverable = an agreed protocol + a populated triangle scatter (two scatters: device spread vs method/hardware spread) — values are device- and method-defined, so there is no single consensus number.
- Bandwidth method: required sample-rate/jitter + aliasing attempt (a fake tone and suppression are both results); the −3 dB sweep is a stretch on one shared driver, so scatter reflects devices not rigs.
- Dynamic range: default to declared full-scale (OS/datasheet); live saturation optional and gentle-only (≤10 cm soft drop onto foam); no destructive testing.
None load-bearing. Residual: the exact prep-vs-live split under the one-slot contingency — this mirrors the capstone's still-open prep/live split and is best fixed for both at once.
Drafted 2026-06-17 as the prequel (Part 1) to tutorial-consensus-g.md. Conforms to the Stele Blueprint document-level patterns.
- v0.3 (2026-06-17) — noted the single-slot merge into tutorial-merged.md (vendor-calibration static read), where this note becomes the characterisation background; status pointer added.
- v0.2 (2026-06-17) — resolved to a sequence: reframed from "alternative" to Part 1 / prequel (title, identity card, new Place in the arc section with the one-slot contingency); softened "no true value" to "no shared external constant — device- and method-defined"; made dynamic range declared-full-scale by default with live clipping optional and gentle-only; reframed the aliasing probe so tone and suppression are both results, made it required and the −3 dB sweep a shared-hardware stretch; clarified the sensitivity↔bandwidth edge as a readout trade, not on-chip; split the cohort scatter into device vs method/hardware; added the theoretical-vs-noise-limited DR distinction; resolved all four open decisions per review.
- v0.1 (2026-06-17) — first deliberation record: three vertices + measurement routes, the triangle-edge couplings, the round-robin (vs key-comparison) framing, benchmark, 60-min session, self-assessment, and four open decisions.
Sensing 2026 · design note · University of Freiburg (group of T. Schaetz). Text © 2026 U. Warring · CC BY 4.0 · v0.3.