A phone is usually described by what it does — calls, photos, apps. Describe it instead by what it contains: a calibrated-enough microphone sampling at 48 kHz, two or three cameras, a bright LED torch, a vibration motor, an accelerometer, and a screen that can flash at a precise rate. That's not a phone. That's a small laboratory with a touchscreen.

Most apps use one of those parts at a time, for its intended purpose. The interesting measurements start when you use them off-label and in combination: the torch as a light source for the camera, the vibration motor as an exciter for the accelerometer, a second phone as the other half of an experiment. This post is a map of that territory, in three tiers of increasing ambition.

Tier 1: one sensor, listening passively

The simplest tools point one sensor at the world and analyze what comes back:

The unifying discipline: capture must be as raw as the platform allows. On Android that means requesting the unprocessed microphone path — no automatic gain control, no noise suppression rewriting the very signal you came to measure — and locking the camera's auto-exposure and white balance whenever the measurement depends on light levels staying honest.

Tier 2: the phone excites, then measures its own excitation

A phone also carries actuators, and pairing an actuator with a sensor turns passive listening into an active instrument:

Active tools have a property passive ones lack: the stimulus is known. When you control the excitation, you can build features from ratios and responses rather than absolute levels — which is what makes results comparable across phone models without calibrating each device.

Tier 3: two phones, one experiment

Some quantities are inherently two-sided: how much sound a wall blocks, how much light a window transmits. One phone can't be on both sides at once — but two can, and most households have two.

The trick that makes this work without lab gear is the same-receiver ratio. The emitting phone plays a self-identifying stimulus — a stepped tone sweep, or a screen blinking at a fixed rate. The measuring phone captures twice: once with a clear path to the emitter (the reference), once through the wall or window. Only the ratio of those two captures, taken on the same microphone or camera, is ever used as the answer. The emitter's loudness, the receiver's sensitivity, the room — all of it cancels. So the two phones need no clock sync, no cable, and no calibration against each other. (Full walkthrough in the sound insulation post.)

Design rule behind all three tiers: never trust an absolute level. Phone microphones and cameras vary between models; resonances, decay rates, order-domain patterns and same-receiver ratios mostly don't. Features built from relative quantities travel across devices; features built from absolute ones need per-device calibration forever.

From single readings to a catalog

A reading on its own is trivia. Readings become knowledge when they attach to things: this melon, this wheel, this wall, measured today and again next week. So every measurement can be filed under an object in a catalog — Category → Object → Use case → Measurement — and any measurement can receive a ground-truth label after the fact: you tapped the melon, then you cut it open, then you recorded what you found. That closed loop, repeated across many users and many objects, is how tap-test classifiers get trained on real fruit rather than lab samples.

And for jobs rather than readings — tuning a bike wheel, checking a room's insulation — guided activities chain several tools in the right order and tell you what to do between measurements, writing their results into the same catalog. The spoke tuning post walks through the first one.

Where this is going

The tool list keeps growing — and the architecture is built so that adding a tool is additive: a new entry in a registry, never a rework of what's already saved. Everything runs on the device, offline, with results in under a second; the offline-first post explains why that constraint is load-bearing rather than a feature checkbox.