22 Sensor Selection: Evidence Before Preference
22.1 Start With the Decision
A sensor wins only if its data sheet supports the product claim. Reject any part that fails a limit or test.
22.2 Route Overview
This is part 1 of 2. Continue with Sensor Selection: Requirements and Candidate Screening.
22.3 Part Objectives
- Test select for claims, not favorites with a concrete scenario and pass criteria.
- Validate turn sensing need into shortlist with a concrete scenario and pass criteria.
22.4 Chapter Roadmap
- Start With the Requirement That Cannot Move
- Phoebe’s Field Notes: What a MEMS Accelerometer’s Sensitivity Row Is Actually Made Of
- Select for Claims, Not Favorites
- Compare Real Part Rows
- Datasheet Is Not Measurement
- In 60 Seconds
- Prerequisites
- What This Chapter Adds
- Do Not Average Away a Must-Have Failure
- Selection Evidence Route
- Turn Sensing Need Into Shortlist
22.5 Start With the Requirement That Cannot Move
22.5.1 Reject a Part Before Scoring It
A cold-store team compares two temperature parts. Both look accurate on the first page of their data sheets. Only one can work beside a freezer door, wake on the available power, speak to the chosen board, and be replaced by a field worker. A high score is useless if one fixed need has already been missed.
Write those fixed needs first. Name the lowest and highest temperature, supply limit, connection type, space, response time, upkeep plan, and acceptable error. Keep desirable features in a separate list. The buyer, circuit designer, software owner, and service worker should be able to point to the same boundary before anyone assigns weights.
Now try to reject each part. Start it at both temperature limits. Use the real cable and enclosure. Remove power during a reading. Compare it with a trusted reference. Repeat the run after warm-up and after several days. Record the test condition beside every result, because a bare headline number cannot carry that meaning.
This first pass does not replace detailed error work or a long field trial. It prevents a weak candidate from hiding behind a neat table. The deeper sections show how to read test conditions, combine trade-offs, check the bench result, and preserve the reason for the final choice.
Before approval, ask a few plain questions. Does the part fit the real board? Does it work at both heat limits? Can the power source start it? Can the cable carry its signal? Is the stated error tied to our test case? Can a worker fit and replace it? Is the part still sold? Do we know when to check it again?
Write each answer beside its proof. Use a data-sheet row only with its stated conditions. Use a bench result only with the board, cable, code, and room state. Mark an unknown as unknown. Reject a fixed miss at once. Score only the parts that remain. That order keeps the table honest and keeps a cheap early check from becoming an expensive field fault.
Picture two sensors with similar headline accuracy, but only one survives the enclosure temperature, power budget, interface voltage, calibration method, and maintenance plan. Sensor selection starts by separating must-have requirements from trade-offs, then using datasheet evidence and bench checks to reject weak candidates before any weighted score is trusted.
The mathematical gist. With a 30 ng proof mass, 8 N/m spring, and 2 µm gap, a 2 g input deflects the mass 73.6 nm, or 3.68% of the gap. That changes a 2 pF capacitance by 0.0736 pF and produces 73.6 mV through the stated 1 pF, 1 V readout—an internal 36.8 mV/g teaching estimate whose constants all carry tolerance.
22.6 Learning Objectives
By the end of this chapter, you will be able to:
- Translate an IoT sensing need into measurable sensor requirements.
- Separate mandatory gates from weighted preferences.
- Build a datasheet evidence matrix for candidate sensors.
- Review average current, peak current, interface, package, environment, lifecycle, and firmware evidence before selecting a part.
- Write a selection summary that explains why the selected sensor is acceptable and what must still be validated.
22.7 Select for Claims, Not Favorites
Sensor selection starts with the job the product needs the data to do. A wearable fall detector, freezer temperature monitor, indoor air-quality node, and vibration-maintenance sensor can all use "small, low-power sensors," but they need different range, noise, drift, response time, power-state, interface, package, and calibration evidence.
The Select for Claims, Not Favorites argument uses Figure 22.1 to compare claim. Look next for quantity, range, before accepting Sensor selection starts with the sensing claim, rejects hard failures at mandatory gates, and records the bench evidence and selection summary that make the choice auditable as a design claim.
Start with the sensing claim in Figure 22.1: quantity, range, context, and decision. Mandatory gates reject hard failures before datasheet evidence supports scoring the remaining candidates. Bench checks then feed a selection summary that records the choice, risks, owners, and retest needs.
The first pass should reject candidates that fail mandatory gates before any scoring table appears. If the host is 1.8 V and the sensor I/O cannot tolerate it, the part fails. If a humidity sensor cannot recover from condensation in the enclosure, the part fails. If an accelerometer saturates before the event of interest, a lower price or nicer driver cannot rescue it.
The route above keeps that discipline visible. The sensing claim names the measured quantity, the deployment context, and the decision that will be made from the data. Mandatory gates then remove parts that cannot support the claim under recommended operating conditions. Only after that does the team compare datasheet evidence, score allowed trade-offs, and schedule bench checks on the final board.
For a classroom comfort node, the claim may be "report temperature and relative humidity every five minutes so the building team can detect uncomfortable rooms." That does not require a high-rate accelerometer or the lowest possible sleep current. It requires humidity and temperature range, accuracy over the expected room band, enclosure airflow, condensation recovery guidance, I2C or SPI fit, package exposure, and a power budget that includes measurement bursts and radio transfers.
- Measurement claim: The sensor range, resolution, accuracy, noise, drift, and response time fit the physical event.
- Integration claim: Supply, I/O voltage, bus timing, address plan, package, placement, and firmware configuration fit the board.
- Release claim: Final hardware measurements confirm power, calibration, timing, environmental exposure, and failure behavior.
Keep those claims separate in the review packet. A candidate may pass the measurement claim but fail integration because two fixed-address I2C devices collide. Another may pass integration but fail release evidence because the final enclosure traps humidity or the firmware cannot enter the advertised sleep state. Selection is therefore a controlled evidence route, not a shopping exercise.
22.8 Compare Real Part Rows
Use named candidates early so the comparison cannot hide behind generic labels. A motion shortlist might compare LIS3DH and ADXL345 rows for +/-2 g to +/-16 g range choices, output data rate, FIFO behavior, interrupt support, I2C/SPI access, package size, operating temperature, and supply/I/O requirements. An environmental shortlist might use BME280 rows for humidity, pressure, temperature, package, I2C/SPI modes, 1.71 V to 3.6 V sensor supply, 1.2 V to 3.6 V interface supply, sleep current, forced-mode current, and operating range.
Then separate gates from preferences. A gate answers "can this part support the claim at all?" A preference answers "which viable part gives more margin or lower integration risk?" Do not mix them. Range, normal operating conditions, I/O tolerance, address conflict, package exposure, required accuracy, and production lifecycle are usually gates. Lower active current, easier calibration, stronger driver ecosystem, FIFO depth, interrupt flexibility, and lead-time margin are usually preferences after the gates pass.
A practical evidence matrix should include the candidate part number, datasheet revision or date, row name, value, unit, test condition, and reviewer note. Copying only the headline number is not enough. A humidity accuracy row may apply at a particular supply voltage, temperature, and humidity band. A current row may describe one-shot forced mode rather than the firmware's actual oversampling, warm-up, interface, and sleep pattern.
Use the same column names for every candidate so reviewers can audit the decision quickly. Mark each gate pass, fail, or investigate before assigning preference scores. If the BME280 pressure capability is not needed, it should not win points unless the product actually uses pressure. If an SHT31-DIS-style humidity sensor has better package exposure for the enclosure, that belongs in the package and environmental evidence rows rather than a vague "better fit" note.
- Write the sensing claim. Include quantity, range, update rate, required confidence, environment, and the downstream decision.
- Build the gate table. Mark each candidate pass, fail, or investigate using datasheet rows with conditions and revision.
- Score only survivors. Use weighted scoring for allowed tradeoffs, then run a sensitivity check to see whether small weight changes flip the winner.
Finish the review with a short selection summary. Name the selected sensor, the alternatives rejected, the gates that blocked them, the preferences that decided among survivors, and the bench checks still required. That summary is what manufacturing, firmware, purchasing, and later maintainers will read when a supplier change, enclosure change, or field failure forces the decision to be revisited.
22.9 Datasheet Is Not Measurement
The selected sensor does not measure alone. The board rail, pullups, bus capacitance, enclosure vent path, conformal coating, mechanical stress, thermal mass, sampling firmware, compensation math, timestamp source, and calibration fixture can change what the system reports. That is why a datasheet row becomes release evidence only after the final system reproduces the relevant condition.
Power claims are a common failure point. A BME280-style environmental node may look excellent from sleep-current rows, but the battery-life claim also depends on measurement mode, oversampling, warm-up, I2C/SPI transaction time, pullup leakage, regulator quiescent current, radio transmit bursts, temperature derating, and whether firmware really enters sleep. A motion node has the same pattern around output data rate, FIFO watermark, interrupt threshold, host wake time, and false-wake rate.
Timing claims fail in similar ways. An accelerometer may support a data rate that looks adequate, but the product still depends on anti-alias filtering, FIFO depth, interrupt latency, MCU service time, timestamp alignment, and whether radio or flash operations block sample handling. A vibration-monitoring design using an ADXL355-class low-noise accelerometer needs fixture resonance checks and real sampling traces, not only a low noise-density row.
Mechanical and environmental coupling matter as much as electrical fit. A humidity sensor behind a poor vent path can lag the room condition. A pressure sensor under enclosure stress can report offset shifts. A motion sensor mounted on a flexible board edge can measure board resonance instead of machine vibration. These are not datasheet mistakes; they are system-design effects that the selection process must catch before release.
Lifecycle and substitution also live under the hood. A production program should record lifecycle status, package options, approved alternates, firmware register differences, calibration changes, and supplier notification requirements. Replacing a sensor later can alter noise, timing, compensation, interrupt polarity, default register states, and package wetting behavior even when the new part uses the same bus and broad measurement category.
The hidden engineering boundary is ownership. The sensor owns raw measurement and some internal compensation state. Firmware owns configuration, timing, filtering, calibration constants, fault handling, and data quality flags. The product team owns the requirement, installation assumptions, acceptable residual risk, and sourcing plan. A good selection summary keeps those ownership boundaries visible.
That boundary is why the final artifact should connect datasheet evidence to validation tasks. Every release-critical row should have a planned check: current waveform, bus trace, register dump, thermal or humidity exposure, calibration fixture result, mounting test, or fault-injection result. Without that link, the selected part is only plausible. With it, the team has an auditable chain from requirement to component to measured system behavior.
22.10 Prerequisites
You should already be comfortable with:
- Specification Sheet Fundamentals: finding limits, conditions, timing, package, and interface rows.
- Network Traffic Analysis: keeping evidence, limits, and validation records tied to real behavior.
- Accelerometer Datasheet Case Study: reviewing one real sensor datasheet from requirement to bench evidence.
22.11 What This Chapter Adds
Datasheet reading asks “what does this part say?” Sensor selection asks “which candidate best supports this system claim?” That shift adds gates, trade-offs, and evidence discipline.
Start from the system
Name what must be measured, where it will be installed, and what decision the data supports.
Reject hard failures early
Supply, range, interface, package, temperature, and lifecycle can disqualify a part before scoring.
Score only valid trade-offs
Weighted scoring is useful after mandatory requirements have been satisfied.
Bench evidence closes the loop
Power, accuracy, timing, noise, mounting, and firmware behavior must be checked in the final context.
A sensor that cannot survive the temperature range, fit the package, talk to the host, or meet a required safety limit should be rejected. A high weighted score in other categories does not make that acceptable.
22.12 Selection Evidence Route
Use the route introduced in the overview as the chapter’s evidence spine: sensing claim, mandatory gates, datasheet evidence, trade-off scoring, bench checks, and selection summary.
22.13 Turn Sensing Need Into Shortlist
Use sensor selection as a filtering route, not a search for the most popular part.
First: Write the sensing claim. Name the measured quantity, target range, update rate, installation context, downstream decision, and the cost of a wrong reading.
Next: Apply mandatory gates. Reject candidates that fail supply, I/O voltage, range, accuracy floor, package exposure, operating environment, lifecycle, or firmware support.
Then: Compare only the survivors. Build a compact datasheet matrix, score allowed preferences, run a weight sensitivity check, and then measure power, timing, bus behavior, noise, mounting, and calibration on the target board.
22.14 Continue to the Next Part
Carry this evidence into Sensor Selection: Requirements and Candidate Screening, which begins with Requirements Before Parts.