2 How Sensors Work

sensors

fundamentals

analog

digital

specifications

2.1 Start With the Measurement Story

Imagine a plant probe that makes a bar on a screen move. Before choosing code or a chart, ask one plain question: what real change is the probe meant to measure?

Name the quantity, unit, useful range, and fastest change that matters. Put the sensor in two known conditions and record what it reports. Then try a bad case. Disconnect it, hold the input steady, or move it beyond its range. The system should show the fault instead of turning a doubtful number into a confident decision.

A sensor converts a physical change into a signal. The signal is evidence, not truth. Heat may take time to reach the sensing part. Mounting can bend a force reading. Noise can make the last digits wander. Reading a pin correctly does not prove that the right thing was measured.

Go deeper in two steps. The Practitioner section uses an Evidence-Fit Sensor Selection record. Under the Hood follows the full measurement chain and separates its failure boundaries.

Make a simple claim card. Write, “This sensor measures…” Fill in one physical quantity and one unit. Add the useful low and high value. Add the fastest change that the product must notice. Add the largest error that the action can bear.

Now make the claim fail. Use no input. Use a steady input. Use a known step. Use a value outside the range. Warm or cool the room. Record delay, offset, noise, and missing data. Make sure the screen can show doubt.

Choose the sensor only after the card and tests agree. Keep the part number, wiring, sample rule, mount, and test date. Recheck after any of them changes. This is how a moving dashboard becomes a bounded measurement claim.

A learner is handed a temperature sensor and a dashboard that moves when the room changes. The useful first question is not how the code reads a pin, but what real-world change the sensor converts into evidence and how much trust that evidence deserves.

The mathematical gist. A catalog-typical humidity element with a 30 s time-to-90% has $\tau=30/\ln10=13.0$ s and $f_c=1/(2\pi\tau)=0.0122$ Hz. Nyquist therefore asks for at least 0.0244 samples/s, or one sample every 41 s. Separately, this chapter’s catalog-typical 10-bit, 3.3 V ADC step is 3.22 mV: response bandwidth and voltage resolution are different limits.

2.2 Overview: What a Sensor Claim Means

A sensor is the first evidence boundary between the physical world and an IoT system. It converts a physical, chemical, biological, or human-context condition into an electrical or digital signal that software can record. The useful claim is not "we have a temperature sensor" or "we have an accelerometer." The useful claim is that a named condition can be measured accurately enough, often enough, and reliably enough for a specific decision.

That boundary matters because a reading is not the same thing as truth. Placement, range, resolution, noise, drift, calibration, response time, interface behavior, power state, enclosure, and data interpretation all shape what the reading can prove. A sensor can be electrically connected and still provide weak evidence for the real-world decision.

2.3 Ideal and Real Sensor Paths

Inspect Figure 2.1 to locate the physical dynamics that an ideal sensor abstraction omits before bandwidth or lag is specified.

Ideal pressure sensor path beside a real sensor body with mass m, spring kx, damper b x dot, inertia m x double dot, interface amplifier, and timestamped acquisition. — Figure 2.1: Physical input through an ideal sensor and a real mass-spring-damper sensor body before interface and acquisition electronics.

Read Figure 2.1 from IDEAL PATH, which maps pressure directly to output, to REAL BODY · MASS-SPRING-DAMPER, which inserts inertia, damping, and restoring force. INTERFACE and ACQUISITION only see the displacement after those dynamics have shaped bandwidth and lag. To test whether a sensor claim survives beyond the part name, use Figure 2.2 as the boundary map. It shows where the measurand changes representation and therefore where evidence can be lost or distorted.

Physical phenomenon passes through a sensing element, signal conditioning and data processing. Every stage can add limits; the output must preserve the physical change the application needs to distinguish. — Figure 2.2: Sensing application pipeline showing environment, sensor probe and body, signal-conditioning interface, and digital data acquisition.

Figure 2.2 starts with the ENVIRONMENT and its Measurand, then crosses into the SENSOR, where the Probe and Body perform physical-to-electrical Transduction. The output can still be resistance or another analogue quantity; the INTERFACE must provide Signal Conditioning to amplify and filter it before DATA ACQ performs ADC Conversion. The numbered pipeline ends at Digital Output, not at truth. Software can only interpret what survived those earlier boundaries, which is why the review below asks separately about placement, transducer behaviour, conditioning, calibration, and decision use.

A useful first review therefore separates what is sensed from how it becomes data. The condition might be temperature, light, force, gas concentration, motion, distance, or touch. The transducer might change resistance, capacitance, voltage, current, frequency, pulse timing, or a digital register. The interface might amplify, filter, divide, excite, sample, timestamp, or validate the signal before the application ever sees a value.

That separation prevents common beginner mistakes. A dashboard can show stable numbers while the probe is mounted in the wrong airflow. A digital bus can return checksummed messages while the sensing element is saturated. A high-resolution ADC can report many digits while the reference voltage, calibration source, or enclosure makes the last digits meaningless. The sensor claim is only strong when the physical condition, conversion path, and decision boundary are reviewed together.

If you only need the intuition, this layer is enough: approve a sensor from the measurement decision and evidence boundary, not from the part name. Name what is measured, where it is measured, how it is converted, how it is calibrated, and what retest would be needed after a change.

2.3.1 The First Sensor Evidence Boundaries

Physical condition

State the condition, location, expected range, response speed, environment, and decision that will use the measurement.

Transducer and signal

Explain how the condition becomes voltage, current, resistance, capacitance, pulse timing, frequency, or a digital message.

Specification fit

Check range, resolution, accuracy, precision, repeatability, drift, response time, noise, interface, and power behavior against the requirement.

Evidence and operations

Record calibration, installation, validation, fault handling, maintenance owner, replacement rule, and retest trigger.

2.3.2 Beginner Examples

Start by a room temperature sensor near a vent may measure airflow effects more than room comfort. Then a digital sensor still needs evidence; a bus message can be valid while the physical placement is wrong. Next a high-resolution reading is not useful if accuracy, calibration, noise, or drift makes the last digits meaningless. Finally a battery-powered sensor may trade sample rate, radio schedule, and heater use against lifetime and measurement quality.

2.3.3 Overview Knowledge Check

2.4 Evidence-Fit Sensor Selection

A practical sensor selection workflow starts with the decision that needs evidence. The sensor is then chosen because it can observe the needed condition under real installation constraints, not because it appears first in a parts list. The review should preserve the path from condition to transducer, signal conditioning, interface, firmware parsing, data quality checks, and downstream decision.

The most useful early artifact is a measurement record. It names the sensing goal, expected range, tolerated error, required response time, environment, power budget, interface, calibration method, and evidence source. It also names what the chosen sensor is not allowed to prove.

2.4.1 Selection Sequence

Start by name the decision. State whether the reading supports display, logging, alerting, closed-loop control, diagnosis, billing, safety, or model input. Then bound the physical condition. Record expected range, worst expected environment, installation location, response speed, and interfering conditions. Next compare specifications. Check accuracy, precision, resolution, sensitivity, drift, response time, interface, power behavior, and operating limits against the requirement. After that plan calibration and validation. Identify reference checks, installation checks, self-test behavior, maintenance interval, and failure indicators. Finally document unsupported claims. State conditions, placements, environments, or decisions that the chosen sensor has not proven.

Review Question

Useful Evidence

Common Failure

Retest Trigger

What is measured?

Condition, location, units, range, sample interval, response time, and decision owner.

The sensor is selected before the team knows what decision the reading supports.

Decision, threshold, unit, location, mounting, enclosure, or sample interval changes.

How is it converted?

Transducer principle, signal conditioning, ADC or digital interface, timing, filtering, and firmware parsing.

The electrical signal is trusted without checking noise, scaling, timing, or interface error behavior.

Sensor part, circuit, ADC reference, pull-up, cable length, interface speed, or firmware parser changes.

How good is good enough?

Accuracy, precision, resolution, repeatability, drift, calibration evidence, and tolerance for false alarms or misses.

Resolution is mistaken for accuracy, or lab precision is treated as field evidence.

Environment, calibration, reference source, tolerance, threshold, aging, or replacement rule changes.

How is it operated?

Power state, warm-up needs, self-test, fault flags, missing-data behavior, maintenance owner, and audit trail.

The reading is accepted even when the sensor is warming up, saturated, disconnected, stale, or outside range.

Power mode, duty cycle, battery, update, maintenance interval, fault policy, or owner changes.

2.4.2 Practitioner Knowledge Check

2.5 Measurement Chain Failure Limits

Under the hood, a sensor reading is a chain of transformations. A physical condition affects a sensing element. The sensing element produces a raw signal. Circuits condition that signal. An ADC, timer, counter, or digital interface captures it. Firmware scales and filters it. Software timestamps and stores it. The application interprets it. Each link can introduce error, delay, saturation, stale data, or unsupported meaning.

Good reviews keep those links separate. A stable I2C transaction does not prove the sensor is placed correctly. A precise ADC count does not prove the calibration reference is valid. A smooth dashboard chart does not prove the physical condition is changing smoothly. The evidence trail should say which link was proven and which claim remains unproven.

2.5.1 Failure Boundaries to Separate

Start by physical boundary: placement, contact, airflow, light path, vibration, contamination, enclosure, self-heating, and environmental exposure. Then transducer boundary: range, sensitivity, saturation, hysteresis, cross-sensitivity, drift, warm-up, and aging. Next circuit boundary: excitation, reference voltage, impedance, filtering, shielding, grounding, cable length, and noise pickup. After that interface boundary: ADC configuration, bus timing, address conflicts, missing acknowledgements, checksum behavior, stale registers, and parser errors. Finally application boundary: units, timestamps, filtering, thresholds, data quality flags, fault handling, and decision ownership.

Chain Link

What It Proves

What It Does Not Prove

Retest Trigger

Condition to element

The target condition can affect the selected sensing element at the reviewed location and mounting.

Electrical accuracy, interface reliability, long-term stability, or dashboard interpretation.

Placement, enclosure, contact, airflow, lighting, vibration, contamination, or environment change.

Element to signal

The sensing element produces a signal within the expected range under reviewed conditions.

That the signal is scaled, digitized, filtered, or interpreted correctly downstream.

Sensor part, operating range, excitation, warm-up, calibration, aging, or contamination change.

Signal to value

The circuit, ADC or interface, firmware, and scaling path can turn the signal into a readable value.

That the value is physically accurate, fresh, calibrated, or useful for every decision.

Circuit, ADC reference, bus, firmware, filter, scaling, unit conversion, or timestamp change.

Value to decision

The application can use the value with thresholds, quality flags, owner rules, and exception handling.

That the sensor will stay valid after drift, replacement, maintenance, or environmental change.

Threshold, alert policy, calibration interval, replacement, owner, data quality rule, or decision change.

2.5.2 Under-the-Hood Knowledge Check

2.6 Summary

Start by sensor approval starts with a measurement claim, not with a readable value or part name. Then the review must connect physical condition, placement, transducer behavior, signal path, interface, firmware, data quality, and application decision. Next accuracy, precision, resolution, drift, response time, range, calibration, and operating environment answer different questions and should not be collapsed into one score. After that digital interfaces still need physical measurement evidence; communication success is not the same as sensing correctness. Finally every sensor claim needs an owner, calibration or validation method, fault behavior, unsupported-claim boundary, and retest trigger.

Key Takeaway

Approve a sensor only when the measured condition, conversion chain, specification fit, calibration evidence, operating owner, and retest boundary are explicit.