16 Selecting the Right Sensor
From Requirements to Evidence-Backed Choice
16.1 Start With the Requirement That Cannot Move
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.
Phoebe’s Why
This chapter names the LIS3DH and ADXL345 as its worked accelerometer examples and insists that a datasheet row is only useful with its test condition attached. A capacitive MEMS accelerometer’s “sensitivity” figure is not an arbitrary calibration constant – it is the end of a short mechanical-then-electrical chain: acceleration deflects a spring-mounted proof mass by a tiny distance, that distance changes a capacitance by an even tinier fraction, and a charge-sensing circuit turns that capacitance change into the voltage a reviewer eventually reads as “mV per g.” Knowing that chain is what lets a reviewer ask the right follow-up question – which stage’s tolerance dominates the datasheet’s stated error band – instead of copying the summary number.
The Derivation
Spring-mass proof-mass deflection under acceleration \(a\):
\[x=\frac{ma}{k}\]
Parallel-plate gap perturbation converts displacement to a fractional capacitance change:
\[\frac{\Delta C}{C_0}\approx\frac{x}{d_0}\]
A charge-transfer readout against a reference capacitor \(C_f\) turns that into a voltage:
\[V_{out}=V_{ref}\,\frac{\Delta C}{C_f}\]
Combining the mechanical and electrical stages inverts a reading back to acceleration:
\[a=\frac{k\,d_0\,C_f}{m\,C_0\,V_{ref}}\times V_{out}\]
Worked Numbers: A Catalog-Typical MEMS Comb Structure
- This chapter names no specific die parameters, so these are catalog-typical MEMS-comb values: proof mass \(m=3.0\times10^{-8}\) kg, spring constant \(k=8.0\) N/m, comb gap \(d_0=2.0\,\mu\)m, rest capacitance \(C_0=2.0\) pF.
- Deflection at a \(\pm2g\) full-scale input (\(a=2\times9.81=19.6\) m/s\(^2\)): \(x=3.0\times10^{-8}\times19.6/8.0=73.6\) nm – about 3.7% of the 2.0 \(\mu\)m gap, small enough for the linear \(\Delta C/C_0\approx x/d_0\) approximation to hold.
- Capacitance change: \(\Delta C/C_0=73.6\text{nm}/2.0\,\mu\text{m}=3.68\%\), or \(\Delta C=0.0736\) pF on a 2.0 pF rest value.
- Front-end voltage (catalog-typical charge-amp, \(C_f=1.0\) pF feedback, \(V_{ref}=1.0\) V bias): \(V_{out}=1.0\times0.0736/1.0=73.6\) mV at full scale, a sensitivity of \(73.6/19.6=3.75\) mV per m/s\(^2\), or 36.8 mV per g – an internal analog-front-end figure, not the published digital LSB/g count, but the right order of magnitude for the physical chain a real datasheet sensitivity row is built on.
- Why this matters for the evidence matrix: every constant in that last equation (\(m\), \(k\), \(d_0\), \(C_0\), \(C_f\), \(V_{ref}\)) is a separate manufacturing tolerance – exactly why this chapter insists a single sensitivity number needs its test condition, temperature, and supply voltage attached rather than being trusted as a fixed constant.
16.2 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.
16.3 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 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.
16.4 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.
16.5 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.
16.6 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.
16.7 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.
16.8 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.
16.9 Turn Sensing Need Into Shortlist
Use sensor selection as a filtering route, not a search for the most popular part.
- Write the sensing claim. Name the measured quantity, target range, update rate, installation context, downstream decision, and the cost of a wrong reading.
- Apply mandatory gates. Reject candidates that fail supply, I/O voltage, range, accuracy floor, package exposure, operating environment, lifecycle, or firmware support.
- 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.
16.10 Requirements Before Parts
Start with a requirements brief. The brief can be short, but it must be specific enough to reject a candidate.
16.11 Mandatory Gates First
Use hard gates before scoring. A gate has a pass, fail, or investigate result. Do not assign a numeric score until every gate is resolved.
16.12 Build the Candidate Evidence Matrix
After the gates, compare candidates using rows that matter to the project. Keep the matrix short enough that reviewers can audit it.
16.13 Incremental Examples
16.13.1 Room Temperature/Humidity Node
A classroom comfort sensor needs temperature and humidity updates every few minutes, not pressure or high-rate motion. A BME280 can be a viable candidate if the product also needs barometric pressure; a Sensirion SHT31-DIS-style humidity sensor may be a better-focused candidate when pressure is irrelevant. The first gate is not brand preference. It is whether the sensor’s humidity and temperature ranges, supply/I/O levels, interface, package exposure, condensation recovery guidance, and calibration plan fit the enclosure and the required confidence.
16.13.2 Motion Wake for Wearables
A wearable fall-detection prototype might compare LIS3DH and ADXL345-style accelerometers. The gate table should check selectable range, output data rate, interrupt behavior, FIFO support, I2C/SPI access, supply/I/O limits, package orientation, and current by mode. Weighted scoring can then compare driver ecosystem, integration effort, interrupt flexibility, and power headroom, but only after both candidates can capture the required motion without saturating or waking the host too often.
16.13.3 Vibration Monitoring Asset
A predictive-maintenance node needs more than “an accelerometer with high resolution.” The selection review should check sensor bandwidth, noise, dynamic range, mounting stiffness, temperature exposure, connector/cable behavior, sampling jitter, timestamp alignment, and whether the MCU can move samples without dropping data. An ADXL355-class low-noise accelerometer may be appropriate for some vibration tasks, but the release claim still depends on target-machine measurements, fixture resonance checks, and firmware traces from the actual sampling path.
16.14 Weighted Scoring Is a Trade-off Tool
Weighted scoring is useful when the remaining candidates all meet the gates. It should not pretend to be more precise than the evidence supports.
Example gates: supply range, measurement range, required accuracy, bus compatibility, package fit, operating temperature. Example preferences: extra margin, lower current, stronger ecosystem, easier calibration, better availability, lower integration effort.
16.15 Power Review Without False Precision
For battery systems, record every state that the firmware can enter. Average current is only meaningful when the duty cycle is realistic.
I_avg = (I_state_1 x time_1 + I_state_2 x time_2 + ... + I_state_n x time_n) / total_time16.16 Try It Now
Rewrite this weak selection claim into a gate-based review note:
“Use the cheaper humidity sensor because it has low power and good accuracy.”
A stronger answer should name the measured quantity, required range, deployment environment, supply/I/O constraints, package exposure, accuracy condition, power states, interface checks, and the bench measurement that must confirm the choice.
16.17 Pick the Non-Negotiable Gate
For each project, write the first gate you would check before scoring candidates:
- A refrigerated medicine cabinet that must alert before contents warm beyond the allowed storage band.
- A soil-moisture node installed outdoors for a full growing season.
- A wrist-worn gesture controller that must wake the host only on deliberate movements.
16.18 Interface and Firmware Checks
The selected sensor must match both hardware and firmware, not just the block diagram.
16.19 Application Snapshots
Treat these as patterns. The best sensor depends on the project requirements and final evidence.
Accelerometer or IMU
Gate on range, output data rate, current states, package, interface, interrupt behavior, and mounting orientation. Score power margin, motion features, driver support, and availability.
Pressure, humidity, temperature
Gate on operating range, accuracy over temperature, recovery from condensation, enclosure airflow, supply, current, and calibration needs.
Proximity or vibration
Gate on environmental exposure, EMC, mechanical mounting, cable length, supply transients, response time, and service lifetime.
Decision-support sensors
Gate on diagnostics, failure state, documentation, supplier control, and validation plan. A scorecard cannot replace safety analysis.
16.20 Selection Summary Template
16.21 Practice Checks
16.22 Common Pitfalls
Feature-rich sensors can be poor choices if the deployment needs low power, a specific interface, simpler calibration, or a more robust package.
Apply hard gates first. A failed supply, range, package, or interface requirement is not a low score; it is a blocker.
Use guaranteed min/max values and stated conditions for release decisions. Typical values can support early estimates and sensitivity checks.
The datasheet may support I2C or SPI, but the final product still needs address planning, timing traces, reset behavior, driver tests, and fault handling.
Breakout-board demos and datasheets are not release evidence. Measure the final board under realistic power, timing, mounting, and environmental conditions.
16.23 Summary
Sensor selection is a controlled, evidence-led process. Start from the sensing claim, define mandatory gates, build a datasheet evidence matrix, score only viable trade-offs, verify the selected candidate on the bench, and publish a selection summary that names assumptions and residual risks. This keeps weighted scoring useful without letting it hide requirement failures.
16.24 References
- STMicroelectronics LIS3DH Product Page - official product page and datasheet access for a low-power digital accelerometer example.
- Analog Devices ADXL345 Product Page - official product page and datasheet access for a digital accelerometer example.
- Bosch Sensortec BME280 Data Sheet - official environmental sensor datasheet used as an example of range, interface, and power evidence.
16.25 See Also
- Specification Sheet Fundamentals: review the datasheet rows and conditions that feed the gate table.
- Accelerometer Datasheet Case Study: apply the selection route to a concrete motion-sensor datasheet.
- Simulation-Driven Testing and Validation: plan the bench checks that confirm the selected part in context.
- Testing and Validation: turn the selection summary into repeatable validation evidence.
16.26 What’s Next
| If you want to… | Read this |
|---|---|
| Review datasheet vocabulary and limits | Specification Sheet Fundamentals |
| Walk through a real accelerometer datasheet | Accelerometer Datasheet Case Study |
| Apply selection evidence to automotive constraints | Automotive Datasheet Qualification |
| Verify selected parts before hardware release | Simulation-Driven Testing and Validation |
| Turn selected parts into validation records | Testing and Validation |
| Previous | Current | Next |
|---|---|---|
| Specification Sheet Fundamentals | Sensor Selection Process | Accelerometer Datasheet Case Study |
16.27 Key Takeaway
Sensor selection should compare the measurement need with range, accuracy, resolution, drift, response time, power, interface, calibration, and environmental limits. Price alone is not a selection criterion.