Chapters

23 Sensor Selection: Requirements and Candidate Screening

design-methodology
spec
sheet
sensor

23.1 Start With the Decision

A sensor shortlist starts with limits for range, error, heat, and power. Write those limits before choosing a part.

23.2 Route Overview

This is part 2 of 2. Review Sensor Selection: Evidence Before Preference for the preceding evidence.

23.3 Learning Objectives

  • Test requirements before parts with a concrete scenario and pass criteria.
  • Validate references with a concrete scenario and pass criteria.

23.4 Chapter Roadmap

  • Requirements Before Parts
  • Mandatory Gates First
  • Build the Candidate Evidence Matrix
  • Incremental Examples
  • Weighted Scoring Is a Trade-off Tool
  • Keep Gates and Preferences Separate
  • Power Review Without False Precision
  • Try It Now
  • Pick the Non-Negotiable Gate
  • Interface and Firmware Checks
  • Application Snapshots
  • Selection Summary Template
  • Practice Checks
  • Match Sensor Evidence to Need
  • Order Sensor Selection Flow
  • Label the Sensor Selection Route
  • Knowledge Check: Gates Before Scores
  • Knowledge Check: Battery-Life Evidence
  • Common Pitfalls
  • 1. Selecting From a Feature List
  • 2. Scoring Before Rejecting
  • 3. Typical Values Are Not Claims
  • 4. Ignoring Firmware and Bus Behavior
  • 5. Treating Bench Evidence as Optional
  • Summary
  • References
  • See Also
  • What’s Next
  • Key Takeaway

23.5 Requirements Before Parts

Start with a requirements brief. The brief can be short, but it must be specific enough to reject a candidate.

The next Requirements Before Parts decision depends on the diagram Figure 23.1. Reading PIR sensor against Short range clarifies the practical meaning of A sensor shortlist should start from the measured quantity and interface constraints before comparing individual part numbers.

Sensor selection decision tree that starts from measurement type, filters candidate sensor families, checks analog or digital interface needs, and produces a decision summary.
Figure 23.1: A sensor shortlist should start from the measured quantity and interface constraints before comparing individual part numbers.

Start at the measurement question at the top of Figure 23.1, then follow the relevant branch to candidate sensors. The interface check separates analog and digital options before the decision summary combines range, accuracy, and connection needs. Validate the resulting choice against power, cost, and environmental conditions.

Requirement Area
Question
Evidence to Seek
Gate or Preference?
Measurement
What quantity, range, resolution, accuracy, noise, and response time are required?
Range, error, bandwidth, noise, drift, calibration, and condition rows.
Usually gate.
Power
What are the active, sleep, startup, peak, and fault-state limits?
Current by mode, conversion time, startup time, duty-cycle assumptions, and regulator limits.
Gate for peak and budget; preference for margin.
Interface
Can the host read the sensor reliably?
I2C, SPI, UART, analog, address options, timing, pullups, logic levels, and driver support.
Gate.
Environment
Where is the sensor installed?
Operating temperature, humidity, shock, vibration, contamination, EMC, enclosure, and mounting notes.
Gate.
Physical
Can the board, enclosure, and assembly process support the part?
Package, footprint, orientation, keepout, thermal path, cleaning, and hand-assembly risk.
Gate or preference.
Lifecycle
Can the product be built and serviced?
Lifecycle status, lead time, qualification notes, supplier notifications, and second-source options.
Gate for production programs.

23.6 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.

Gate
Pass Evidence
Fail Example
Follow-up
Supply and logic
Recommended supply and I/O ranges cover board rails with tolerance.
Host logic exceeds sensor I/O limit.
Add level shifting, choose a different part, or change rail plan.
Measurement range
Range covers normal, overload, and expected edge cases.
Sensor saturates before the required event is captured.
Select wider range or revise measurement method.
Accuracy floor
Worst-case error is within the required limit under relevant conditions.
Only typical accuracy meets the requirement.
Use a better sensor, calibration plan, or relax requirement with approval.
Power states
Average and peak current fit regulator, battery, thermal, and firmware assumptions.
Peak current browns out the rail during radio transmit.
Measure state current and update the power budget.
Interface
Bus speed, address, mode, timing, and firmware support are compatible.
Two fixed-address I2C devices conflict on the same bus.
Use address strap, mux, SPI variant, or different part.
Package and assembly
Footprint, orientation, soldering, inspection, and exposure needs are feasible.
Sensor opening is blocked by coating or enclosure.
Revise layout, enclosure, or sensor type.

23.7 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.

Evidence Row
Candidate A
Candidate B
Review Note
Range and overload
Copy min/max range and overload condition.
Copy min/max range and overload condition.
Reject parts that saturate before required events.
Error and drift
Copy worst-case error and temperature condition.
Copy worst-case error and temperature condition.
Use worst-case rows for release claims.
Noise and bandwidth
Copy noise density, bandwidth, filter, or output data rate.
Copy noise density, bandwidth, filter, or output data rate.
Check whether filtering adds unacceptable latency.
Current by state
Copy active, sleep, startup, and interface current with conditions.
Copy active, sleep, startup, and interface current with conditions.
Estimate duty-cycle current, then measure it.
Interface
Copy protocol, address, timing, voltage, and reset behavior.
Copy protocol, address, timing, voltage, and reset behavior.
Confirm firmware and bus traces before release.
Package and lifecycle
Copy package, footprint, lifecycle status, and supplier notes.
Copy package, footprint, lifecycle status, and supplier notes.
Check manufacturing, sourcing, and service risk.

23.8 Incremental Examples

23.8.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.

23.8.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.

23.8.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.

23.9 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.

The Weighted Scoring Is a Trade-off Tool argument uses Figure 23.2 to compare Mandatory Gates. Look next for reject hard failures before accepting Weighted scoring belongs after mandatory gates and before bench validation, not before basic fit is proven as a design claim.

Scorecard gate showing mandatory requirements before weighted preferences and sensitivity review.
Figure 23.2: Weighted scoring belongs after mandatory gates and before bench validation, not before basic fit is proven.

Read Figure 23.2 downward from mandatory gates, which reject hard failures before comparison. The evidence matrix supplies rows and conditions for a weighted score covering valid trade-offs. Sensitivity review checks weights and assumptions before bench validation.

Scoring Practice
Good Use
Risky Use
Criteria
Score margin, integration effort, ecosystem, availability, and power headroom.
Score a must-have requirement instead of treating it as a pass/fail gate.
Weights
Explain why each weight matters for the product.
Pick weights after seeing which candidate you already prefer.
Scores
Use documented scales and evidence rows.
Use vague labels such as "good", "better", and "best" without source values.
Sensitivity
Check whether the winner changes when plausible weights move.
Report one total score as if it were a physical measurement.
Decision
Pair the score with bench checks and residual risks.
Use the score as a substitute for validation.

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.

23.10 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_time
Power Item
Datasheet Evidence
Design Evidence
Release Risk
Active current
Current during measurement, conversion, transmit, or heater operation.
Firmware state log and measured current waveform.
Short bursts can exceed regulator or battery pulse limits.
Sleep current
Sleep, standby, shutdown, or retention current with conditions.
Measured current after final board leakage and pullups are included.
Board leakage can dominate the sensor datasheet value.
Startup time
Power-on, reset, warm-up, stabilization, or first-valid-sample timing.
Boot sequence, warm-up policy, and first-read discard rules.
Duty-cycle estimates can be wrong if warm-up dominates.
Peak current
Maximum conversion, heater, RF, or interface current.
Rail capture during worst-case system activity.
Peak current can brown out the rail even if average current is low.
Battery model
No single sensor datasheet proves battery life.
Battery chemistry, derating, temperature, self-discharge, and cutoff voltage.
Nominal capacity can overstate field life.

23.11 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.

23.12 Pick the Non-Negotiable Gate

For each project, write the first gate you would check before scoring candidates:

First: A refrigerated medicine cabinet that must alert before contents warm beyond the allowed storage band.

Next: A soil-moisture node installed outdoors for a full growing season.

Then: A wrist-worn gesture controller that must wake the host only on deliberate movements.

23.13 Interface and Firmware Checks

The selected sensor must match both hardware and firmware, not just the block diagram.

Interface Item
Check
Evidence
Common Failure
I2C address
Address options and existing bus devices.
Address map and bus scan on target hardware.
Two fixed-address devices conflict.
Logic level
Sensor I/O voltage and host I/O voltage.
Schematic review and absolute maximum pin limits.
Host drives a pin above sensor tolerance.
Timing
Bus speed, setup, hold, conversion, and interrupt timing.
Logic analyzer trace and firmware timeout settings.
Driver reads before data is valid.
Reset and startup
Reset state, default mode, first sample timing, and configuration sequence.
Boot log and register dump.
Firmware assumes a default mode that the part does not use.
Library support
Driver maturity, license, platform support, and test coverage.
Driver review, version pin, and integration test.
Prototype works with breakout library but production firmware does not.

23.14 Application Snapshots

Treat these as patterns. The best sensor depends on the project requirements and final evidence.

Wearable motion

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.

Environmental node

Pressure, humidity, temperature

Gate on operating range, accuracy over temperature, recovery from condensation, enclosure airflow, supply, current, and calibration needs.

Industrial sensing

Proximity or vibration

Gate on environmental exposure, EMC, mechanical mounting, cable length, supply transients, response time, and service lifetime.

Safety-adjacent use

Decision-support sensors

Gate on diagnostics, failure state, documentation, supplier control, and validation plan. A scorecard cannot replace safety analysis.

23.15 Selection Summary Template

Section
Include
Reviewer Question
Requirement summary
Measurement, range, accuracy, update rate, environment, power, interface, package, lifecycle.
Is the selection judged against the real system need?
Gate results
Pass/fail/investigate status for each mandatory requirement.
Was any failure hidden inside a weighted score?
Evidence matrix
Datasheet rows, units, conditions, revision, and source links.
Can another engineer audit the copied evidence?
Trade-off score
Criteria, weights, score scale, candidate scores, and sensitivity notes.
Would the decision change under plausible weight changes?
Bench plan
Power, accuracy, timing, interface, environmental, mounting, and firmware tests.
What must be tested before release?
Decision
Selected part, rejected alternatives, risks, owners, and approval date.
Is the decision reproducible and reviewable?

23.16 Practice Checks

Label the Sensor Selection Route

23.17 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.

23.18 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.

23.19 References

First: STMicroelectronics LIS3DH Product Page - official product page and datasheet access for a low-power digital accelerometer example.

Next: Analog Devices ADXL345 Product Page - official product page and datasheet access for a digital accelerometer example.

Then: Bosch Sensortec BME280 Data Sheet - official environmental sensor datasheet used as an example of range, interface, and power evidence.

23.20 See Also

First: Specification Sheet Fundamentals: review the datasheet rows and conditions that feed the gate table.

Next: Accelerometer Datasheet Case Study: apply the selection route to a concrete motion-sensor datasheet.

Then: Simulation-Driven Testing and Validation: plan the bench checks that confirm the selected part in context.

After that: End-to-End Test Strategy: turn the selection summary into repeatable validation evidence.

23.21 What’s Next

If you want to…Read this
Review datasheet vocabulary and limitsSpecification Sheet Fundamentals
Walk through a real accelerometer datasheetAccelerometer Datasheet Case Study
Apply selection evidence to automotive constraintsAutomotive Datasheet Qualification
Verify selected parts before hardware releaseSimulation-Driven Testing and Validation
Turn selected parts into validation recordsEnd-to-End Test Strategy
PreviousCurrentNext
Specification Sheet FundamentalsSensor Selection ProcessAccelerometer Datasheet Case Study

23.22 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.

23.23 Continue Your Route

This final part closes the route from Requirements Before Parts through Key Takeaway. Return to Sensor Selection: Evidence Before Preference or continue from the design-methodology module index.