Part I: Foundations of Sensory AI
Chapter 2: Sensor Physics and Measurement Models

Direct and indirect observables

"They asked me for the temperature. What I actually held in my hand was a resistance, a wiring diagram, and a promise."

A Literal-Minded AI Agent

Prerequisites

This chapter assumes the smudged-pane intuition and the forward measurement model \(x = h(s) + \eta\) from Chapter 1, plus first-year calculus and a little algebra. Nothing here needs statistics yet; the machinery for inverting a noisy model and attaching a margin of doubt is built from scratch in Chapter 4, and the physical constants and unit conventions used in the worked examples are collected in Appendix A (Math and Signal-Processing Reference) and Appendix C (Sensor Hardware Guide). Read this section for the vocabulary that the rest of Chapter 2 will quantify.

The Big Picture

A sensor almost never responds to the quantity you actually want. It responds to something physically next door, a resistance, a voltage, a light intensity, a time-of-flight, and you recover the thing you care about by pushing that raw response through a model. This section draws the line between the direct observable the transducer genuinely couples to and the indirect observable you infer from it. That line decides which of your errors are honest measurement noise and which are your own modeling assumptions quietly failing. Every chapter that follows is either measuring a direct observable more cleanly or inverting toward an indirect one more carefully.

The measurand is rarely what the transducer touches

Name the quantity you are trying to learn: air temperature, blood oxygen, altitude, the speed of the car ahead. That target is the measurand. Now name the physical effect the sensing element actually produces at its terminals. For a thermistor it is electrical resistance; for a thermocouple it is a small voltage; for a pulse oximeter it is two light intensities; for radar it is a shift in the frequency of a returned wave. That terminal effect is the direct observable: the one quantity to which the transducer couples through a single, well-characterized physical step, and the only thing your electronics ever really digitizes.

The gap between the two is the whole subject. A thermistor does not measure temperature; it is a resistor whose resistance happens to depend on temperature, and you read that dependence in reverse. This matters because the coupling, not your intention, sets what the raw number means. When the datasheet says a device measures temperature, it is compressing a longer and more honest sentence: this device produces a resistance, we have characterized how that resistance varies with temperature, and if you trust our characterization you may call the result a temperature. Keeping the direct observable in view is what lets you tell a broken instrument (its resistance genuinely changed) from a broken assumption (the resistance is fine, your conversion is wrong), a distinction we will return to throughout the chapter.

Indirection: computing what you wanted from what you got

An indirect observable is any measurand you never touch directly and must reconstruct by applying a physical model to one or more direct observables. The reconstruction runs a known forward relationship backward. Resistance to temperature, pressure to altitude, round-trip photon time to distance, frequency shift to velocity: each is a small inverse problem, the same shape as the perception loop from Chapter 1, now made concrete for one sensor. Figure 2.1.1 lays out the chain that every indirect reading travels.

measurand (what you want) coupling + transduction direct observable x indirect estimate ŝ physics runs forward invert the model ←

Figure 2.1.1. The measurand couples to a sensing element, which transduces it into a direct electrical observable \(x\). A direct-observable sensor stops there; an indirect-observable sensor inverts a known physical model to recover the estimate \(\hat{s}\), inheriting every assumption that model carries.

Indirection also stacks. A pulse oximeter recovers blood oxygen saturation from a ratio of two light absorptions, and each absorption was itself inferred from a raw photodiode current. Heart-rate variability sits one level above that again, computed from beat intervals that were computed from the oxygen-modulated waveform. The count of layers between the photon and the reported number is a good rough gauge of how much modeling you are trusting, and therefore how many ways the reading can be quietly wrong while the hardware works perfectly. Radar makes the same point in one clean step: the antenna sees only a frequency shift, and radial velocity falls out of the Doppler relation, a technique Chapter 44 builds AI on top of.

Key Insight

A direct observable can be wrong only through noise and hardware fault. An indirect observable can also be wrong because its conversion model was invoked outside the conditions it was derived for. That second failure mode is invisible in the raw signal: the numbers look clean, the electronics are healthy, and the answer is confidently, systematically off. Learning to name your observables is learning where to point suspicion when a reading lies without any sensor breaking.

Every layer of indirection ships a hidden assumption

The model that turns a direct observable into an indirect one is valid only inside a domain, and that domain is a specification as real as any voltage range. A barometric altimeter recovers height from air pressure through the hydrostatic equation, assuming a standard atmosphere. Let a weather front roll in and drop the sea-level pressure, and the altimeter reports a climb the aircraft never made; the pressure sensor is flawless and the altitude is fiction. A pulse oximeter's ratio-of-ratios calibration assumes only oxygenated and deoxygenated hemoglobin are present; carbon monoxide poisoning violates that premise, and the device reads a reassuring high number over dangerously starved blood. A radar Doppler estimate assumes motion along the line of sight; a target crossing sideways registers almost no shift and is reported as nearly stationary.

None of these are noise, and none are cured by a better or more expensive part, exactly the trap Chapter 1 warned about. They are the conversion model applied where it does not hold. The practical discipline is to write down, for every indirect observable in your pipeline, the assumptions its model rests on and the conditions that break them, and to treat those conditions as failure modes to detect rather than footnotes to ignore. When a learned model later consumes this signal, it inherits the validity domain whether or not anyone told it; a network trained only on sea-level flights has never seen the altimeter's front-passage lie and will trust it blindly, a leakage-of-context problem that returns in Chapter 4 when we reason about uncertainty formally.

In Practice: the clinical pulse oximeter

A finger-clip \(\mathrm{SpO_2}\) monitor in a hospital shines red (about \(660\ \mathrm{nm}\)) and infrared (about \(940\ \mathrm{nm}\)) light through the fingertip and measures how much of each a photodiode receives. The direct observables are two light intensities; the indirect observable, oxygen saturation, comes from the pulsatile ratio \(R\) of those absorptions fed through an empirical calibration curve baked in at the factory. That curve was fit on healthy adult volunteers breathing controlled gas mixtures. Everything the device reports is only as true as the match between your patient and that reference population. Strong ambient light, nail polish, low perfusion, motion, or a skin tone underrepresented in the calibration cohort all move \(R\) without moving true saturation, and the number drifts from the truth while every wire stays intact. Clinicians are taught to distrust an \(\mathrm{SpO_2}\) reading that disagrees with how the patient looks, which is precisely the direct-versus-indirect distinction turned into bedside practice. The signal-processing side of this sensor is developed in Chapter 30.

Because the conversion is just arithmetic on a known relationship, it is also the kind of thing a library encodes once and reuses forever. Consider the workhorse example: turning a thermistor's resistance (direct) into temperature (indirect) through the Steinhart-Hart equation,

\[ \frac{1}{T} = A + B \ln R + C (\ln R)^3, \]

where \(T\) is absolute temperature in kelvin, \(R\) is the measured resistance, and \(A, B, C\) are coefficients from calibration. Listing 2.1 evaluates it directly so you can see the whole inversion in one place.

import numpy as np

def thermistor_temperature_c(resistance_ohms, A, B, C):
    """Steinhart-Hart: direct observable (resistance) -> indirect observable (temperature)."""
    lnR = np.log(resistance_ohms)
    inv_T = A + B * lnR + C * lnR**3       # 1 / T, with T in kelvin
    return 1.0 / inv_T - 273.15            # convert kelvin to Celsius

# Typical 10k NTC coefficients (from a calibration sheet):
A, B, C = 1.129e-3, 2.341e-4, 8.775e-8
for R in (32650, 10000, 3600):            # cold, nominal, warm
    print(f"{R:6d} ohm -> {thermistor_temperature_c(R, A, B, C):5.1f} C")
Listing 2.1. The full direct-to-indirect conversion for a negative-temperature-coefficient thermistor: the resistance is what the hardware gives you, the temperature is what you infer. Notice that the coefficients \(A, B, C\) are the model, and a reading is only as trustworthy as the calibration those three numbers came from.

As Listing 2.1 shows, the physics of the inversion is a three-term polynomial in \(\ln R\); the risk is entirely in the coefficients and their validity range, not in the arithmetic.

The Right Tool

Written from scratch, a robust converter also has to clamp resistances to the calibrated range, handle sensor-specific coefficient tables, interpolate a lookup curve when no closed form fits, and flag out-of-range inputs, easily 30 to 40 lines of fiddly guard code per sensor family. A hardware abstraction library collapses that to a single object:

import board, adafruit_thermistor
t = adafruit_thermistor.Thermistor(board.A1, 10000, 10000, 25, 3950)
temperature_c = t.temperature      # resistance read, model inverted, range-checked
Listing 2.2. A driver library reads the divider, inverts the model with the sensor's own beta coefficient, and returns a temperature in one property access, replacing roughly 30 to 40 lines of per-sensor conversion and range-guarding. What it cannot do is decide whether the calibration applies to your operating conditions; that judgment stays yours.

The library removes the arithmetic, not the responsibility for the validity domain, the same division of labor Listing 2.1 makes explicit.

Why the distinction organizes the rest of this book

Sort any sensing task by how deep its measurand sits below the transducer and the book's structure appears. Shallow, nearly-direct observables (a thermocouple voltage, a raw accelerometer force) need clean acquisition and good calibration, the concerns of the rest of Chapter 2 and of Chapter 3. Deep, heavily-modeled observables (position from satellite timing, activity from motion, oxygenation from light) need estimation, fusion, and learned inversion, the concerns of Parts III onward. The design question for any new sensor is always the same two-parter: what is the direct observable I truly measure, and how many modeling assumptions stand between it and the number I report. Answer both plainly and you know where your errors will come from before you collect a single sample.

Exercise

Pick three sensors from your own life: a car's fuel gauge, a smartwatch step counter, and a smart-home carbon-dioxide monitor. For each, write down (1) the direct observable the transducer actually produces, (2) the indirect measurand reported to the user, and (3) at least one real-world condition under which the conversion model breaks while the hardware stays healthy. Rank the three by depth of indirection, and predict which will be hardest to trust in the field.

Self-Check

1. State the difference between a measurand and a direct observable, and give one sensor where they coincide and one where they do not.

2. Why can an indirect observable be systematically wrong while the raw signal looks perfectly clean? Name the failure mode this section calls out.

3. In Listing 2.1, which part of the pipeline is "the model," and why does replacing the thermistor with a better one not fix a bad calibration?

What's Next

In Section 2.2, we stop asking what a sensor observes and start asking how well: resolution, the smallest change it can distinguish; sensitivity, how strongly its output moves per unit of input; and dynamic range, the span from the faintest signal it can register to the loudest it can survive. Those three numbers decide whether the direct observable you just learned to name carries enough information to invert at all.