3 Sensor Specifications
3.1 Start With the Measurement Story
Read Every Number With Its Conditions
Picture a freezer alarm set at minus 15 degrees. A sensor display changes in tiny steps, but its stated error is wider than the alarm gap. The extra digits do not make the decision safe.
A sensor specification is a claim about how a part behaves under stated conditions. Latency means the wait from a real change to a usable result. Start with the field decision. Write the needed range, error, speed, power, size, and environment. Then read the data sheet for the conditions attached to each number.
Keep different ideas separate. Resolution is the smallest shown step. Accuracy is closeness to a trusted value. Precision is how closely repeated readings agree. Response time is how soon the result settles after a change. A sensor can be strong in one and weak in another.
Test the installed part against a trusted reference. Include the real case, wire, power mode, heat, moisture, vibration, age, and mounting. Record the result and the change that will force a new check.
Use Practitioner to build the choice and test record. Use Under the Hood to study error, drift, noise, timing, and evidence limits.
A datasheet number looks precise until the device leaves the lab. Start with the field claim: what range, resolution, accuracy, latency, and operating conditions must hold before a reading can drive an IoT decision?
3.2 Specifications Need Conditions
Sensor specifications describe what a sensor can measure, how fine its output can be, how close readings may be to the true condition, how repeatable the readings are, and which conditions must be true for those claims to hold. They are not marketing labels. They are evidence claims that need units, limits, operating conditions, calibration context, and test records.
The first review habit is to separate the physical measurement from the displayed number. A sensor can report many decimal places and still be inaccurate. A sensor can be repeatable and still be biased. A sensor can work well in the lab and fail in the field because mounting, moisture, vibration, temperature, aging, or power mode changed the conditions.
No single headline specification proves field fit. Use Figure 3.1 to check which datasheet categories must be read together before a measurement claim is accepted.
In Figure 3.1, Electrical Parameters puts the 1.8–3.6 V supply range beside active and sleep current, tying compatibility directly to battery life. Performance Metrics then separates measurement range and resolution from accuracy, sensitivity, and linearity; those are different claims even when a display shows many digits. Move to Timing Characteristics for response, settling, and sampling rate, then test whether Mechanical Specs permit the required package and mounting. The Environmental Limits card closes the loop with operating temperature, storage, and humidity ratings. A candidate passes only when all five cards describe the same installed use case, which is the conditional reading discipline applied below.
Read those categories together, not as independent badges. A low-power sensor that fits the battery budget can still be wrong for the installation if its humidity limit is exceeded. A fast sensor can still be unusable if its package cannot be mounted where the physical condition actually occurs. A high-resolution sensor can still mislead a control rule if the accuracy and drift claims are weaker than the threshold being enforced.
A useful specification record therefore keeps the claim, condition, and evidence side by side. Write down the value being promised, the environment or calibration state where it applies, and the test or field observation that will prove it after installation. That habit turns the datasheet into an engineering decision record instead of a list of attractive numbers.
If you only need the core idea, use this rule: match sensor specifications to the decision the IoT system must make, then keep evidence that the sensor meets those specifications in the real installation.
3.2.1 The Core Specification Set
Measurement Fit
Range, span, operating conditions, and response time decide whether the sensor can observe the target condition where the device is installed.
Signal Quality
Resolution, sensitivity, noise, precision, hysteresis, linearity, and drift decide whether the reported change is meaningful or just measurement behavior.
Evidence
Accuracy, calibration records, reference checks, datasheet conditions, and field validation decide whether the reading can support an application decision.
3.2.2 Beginner Examples
Start by a temperature sensor with fine resolution can show small changes, but the reading is still limited by its accuracy and calibration evidence. Then a fast response time matters for alarms and control loops; slower response may be acceptable for trend logging. Next a wide operating range matters when the installation sees outdoor, refrigerated, heated, humid, or dusty conditions. Finally a low unit price is not enough if the sensor drifts quickly, corrodes, or requires frequent field replacement.
For timing claims, distinguish response time from a simple time constant. Response time is the time needed for the output to settle inside a named tolerance band after the input changes; a rising step and a falling step can have different settle or decay times. An RC-like time constant is usually shorter than the final response-time specification, so an alarm or control record should name the tolerance band, step direction, and test condition.
3.2.3 Overview Knowledge Check
3.3 Specification Record
A practical sensor review starts with the application decision. What condition must be detected? What threshold, trend, alarm, or control action depends on the reading? Once the decision is clear, specifications become filters: reject sensors that cannot support the decision under field conditions, and avoid paying for performance the decision cannot use.
The record should be short, explicit, and testable. It names the measured condition, required range, required accuracy, acceptable response time, expected noise, calibration method, power mode, installation condition, and the evidence that proves the sensor is still valid after deployment.
3.3.1 How It Works: Read the Specification Chain
Start by start with the decision. State the alarm, control action, trend, report, or diagnostic that depends on the measurement. Then set the measurement envelope. Record the physical range, operating environment, response-time need, and mounting constraint. Next separate accuracy, precision, and resolution. Ask which error is systematic, which variation is random, and which display step is merely output granularity. After that check calibration and drift. Identify the reference, calibration interval, offset or scale factor, repeatability check, and review trigger. Finally close with evidence. Keep datasheet conditions, bench checks, installation notes, field validation readings, and exceptions that would force re-selection.
3.3.2 Specification Review Ledger
A blood-pressure transducer might be specified with a range of -50 mmHg to +450 mmHg and a sensitivity of 10 mV/V/mmHg (10 millivolts of output per volt of excitation per mmHg of applied pressure). A bench check against a reference could show the installed part delivering closer to 7.8 mV/V/mmHg — a sensitivity error that the range and accuracy numbers alone would not reveal.
3.3.3 Intermediate Example
A greenhouse controller triggers irrigation from soil moisture readings. The selection record should not start with the cheapest part. It should state the irrigation threshold, soil type, installation depth, expected moisture range, acceptable uncertainty around the threshold, response-time need, corrosion risk, power budget, calibration method, and field-check schedule. A sensor that is inexpensive but drifts or fails after repeated wetting can be more expensive than a durable sensor once replacement visits are counted.
3.3.4 Practitioner Knowledge Check
3.4 Error Sources and Evidence Limits
Specifications are linked because every sensor is a measurement chain. The physical condition must reach the sensing element, the element must produce a signal, the circuit must condition it, the interface must transmit it, firmware must parse it, and the application must interpret it. A failure at any link can look like a sensor problem.
Under the hood, the strongest review separates uncertainty into categories. Offset and scale errors may be corrected by calibration. Random noise may need averaging, shielding, filtering, or different hardware. Hysteresis and drift may require replacement limits or regular reference checks. Response lag may require different placement, different sensing technology, or a slower control expectation.
3.4.1 Advanced Example
A cold-chain monitor needs more than a temperature value. The record should name the allowed storage window, sensor accuracy under that window, calibration reference, enclosure thermal lag, sampling interval, alarm rule, battery behavior at low temperature, data retention during connectivity loss, and evidence retained after a temperature excursion. A reading that appears valid on the dashboard is not enough if the sensor was mounted where it responds slowly to the product temperature.
3.4.2 Error-Boundary Checklist
Start by offset: The sensor is consistently high or low; calibration may subtract the bias if the reference is valid. Then scale: The output changes too much or too little across the span; calibration may need more than one point. Next linearity: The output departs from a straight-line fit to the ideal response; quoted as the maximum gap between the measured and ideal curve, expressed as a percentage of full-scale span rather than a single value, because the departure grows with how far the input swings from the calibration point — a nonlinearity that looks negligible near one operating point can still turn a fast-oscillating input, such as vibration on an accelerometer, into a steady false offset instead of averaging away. After that resolution: The output step is too coarse for the required change; software cannot invent missing measurement detail. Continue by noise: Repeated readings vary under stable conditions; averaging can help only when the process can tolerate delay. Continue by hysteresis: The reading depends on whether the condition approached from above or below; record direction-sensitive behavior. Continue by drift: The same condition produces a different reading over time; define recheck, recalibration, or replacement triggers. Finally response lag: The reading trails the physical event; test whether the delay is acceptable for the decision.
3.4.3 Response Time Beyond a Single Time Constant
A sensor whose output settles like a charging capacitor is a first-order system: one time constant, one exponential curve, no overshoot. Many sensors are not that simple. A sensor with moving mass or a resonant structure — an accelerometer proof mass, a pressure diaphragm, a thermal probe with a spring-loaded mount — behaves more like a mass-spring-damper system, and its step response depends on a natural frequency and a damping ratio rather than a single time constant. An underdamped sensor overshoots the final value and rings before settling, so a fast reading taken right after a step can briefly sit past the true value in the wrong direction. A critically damped sensor reaches the final value in close to the shortest possible time without overshoot. An overdamped sensor approaches the final value slowly with no overshoot, trading speed for stability.
This matters for the response-time specification because a datasheet's stated settle time and tolerance band assume one of these shapes. A control loop or alarm that samples a fast sensor immediately after a step can be fooled by overshoot into recording a value more extreme than the true one, and a system that only checks whether the reading is still moving can mistake ringing for real oscillation in the process being measured. Reviewing a fast sensor's actual step response, not just its published response-time number, is the only way to know which of these shapes applies.
3.4.4 Resolution, Noise, and Effective Bits
Resolution begins with span, not with the largest printed code. An ideal -bit ADC divides an input span into code bins, so one least-significant bit is
For a bipolar input, . With 16 bits,
That number is ideal code width, not yet trustworthy measurement resolution. If repeated readings at a constant input occupy a 16-count noise band, the bottom four bits are not stable because . A useful first estimate is therefore
This range-based estimate is intentionally conservative and is not the same as the sine-wave ENOB calculated from SINAD. State which method produced the number. Also check missing codes, INL, reference noise, and drift: averaging can reduce random variation, but it cannot repair a nonlinear transfer curve or a moving reference.
For independent, zero-mean samples with standard deviation , the mean of samples has
If the input noise is 8 counts RMS, averaging 64 independent samples gives count RMS. The price is time. At 1 ksample/s, a single result takes about 1 ms while a non-overlapping 64-sample mean spans 64 ms, an eightfold noise improvement for a sixty-fourfold observation window. Correlated noise, 1/f drift, mains pickup, or a changing measurand will not follow this square-root rule.
The workbench below turns that trade-off into a sensor specification decision. It opens on a 3.30 V, 12-bit converter with 2.00 count RMS independent noise, one sample per result, 1000 sample/s, and the LM35 sensitivity of 0.0100 V/deg C. Walk through the orange uncertainty band and live readouts first: the starting result is only 9.19 useful bits and 0.564 deg C effective resolution. Then change only Average count from 1 to 64. The useful result reverses to 11.6 bits and 0.107 deg C, but the acquisition window grows from 1.00 ms to 64.0 ms. That visible exchange is why a module specification must record both resolution and observation time instead of quoting nominal ADC bits alone.
Sensitivity must use the same count convention. For a 12-bit converter spanning to ,
A -count decision band is therefore about the mean. Its full lower-to-upper width is peak to peak. Calling the result simply “1.9 mV p-p” mixes a one-sided threshold with a peak-to-peak band; preserve the sign and count definition in the specification record. If a 0—1 V sensor represents 0—1000 engineering units, its scale is , so a threshold corresponds to roughly units before accuracy, nonlinearity, and drift are added.
3.4.5 Evidence That Makes a Specification Trustworthy
Datasheet Context
Record the exact conditions behind a specification, including supply range, temperature range, sampling mode, and calibration assumptions.
Bench Reference
Compare the sensor against a suitable reference before field deployment, then keep the raw readings and correction method.
Field Validation
Confirm mounting, airflow, moisture, vibration, shielding, cable length, enclosure behavior, maintenance access, and cross-sensitivity to variables such as temperature or humidity that are not the primary measurement.
Review Trigger
Define what forces a recheck: drift, firmware change, new enclosure, replaced sensor, failed reference check, or unexplained alarm behavior.
3.4.6 Under-the-Hood Knowledge Check
3.5 Resolve a Pressure Channel From Limits to Timing
A pressure sensor can fit the pipe thread and still fail the control loop because its supply, error, or response time is wrong. Read Figure 3.1 from electrical limits through performance, timing, mechanical fit, and environmental bounds. Then use Figure 3.1 to connect each specification group to the decision it constrains. In the pressure specification, range says what can be represented; accuracy says how close; resolution says how small a displayed step may be.
Under these sensor conditions, take a 0–20 V input measured by a 16-bit converter. One ideal code spans (20/65{,}536=0.000305\ \text{V}), or 0.305 mV. If the sensor itself is only accurate to ±20 mV, extra converter codes cannot make the installed pressure accurate to 0.305 mV. Timing creates a second limit: at 1,000 samples/s, one sample takes 1 ms, while a non-overlapping 64-sample mean covers (64\times1=64\ \text{ms}).
3.5.1 Predict Which Specification Wins
- Predict: A valve fault develops in 20 ms, but the displayed value uses the 64 ms mean. Can the display prove the peak was captured? Check: No. The averaging window can smooth or delay the brief pressure event.
- Predict: The package survives 85 °C storage but lists only 60 °C operating temperature. May it measure at 75 °C? Check: Not from the storage rating; operation and unpowered survival are different specification limits.
3.6 Summary
Sensor specifications are conditions-backed claims. Range, operating conditions, response time, accuracy, precision, resolution, sensitivity, noise, hysteresis, drift, power, and calibration evidence all shape whether a reading can support an IoT decision.
The safest selection workflow starts with the application decision, then builds a specification record that can be tested in the real installation. A trustworthy record distinguishes resolution from accuracy, repeatability from correctness, bench behavior from field behavior, and unit price from lifetime cost.
3.7 Key Takeaway
Read sensor specifications as evidence boundaries. A reading is useful only when the sensor, signal path, calibration, installation, and field conditions all support the decision being made.
3.8 See Also
Sensor Introduction and Fundamentals
Use this for the broader measurement chain before reviewing individual specifications.
Common Sensors and MEMS
Compare common sensor families after the key specification terms are clear.
Sensor Selection Guide
Turn specification requirements into a defensible sensor choice for a deployment.
Sensor Calibration Techniques
Connect specification claims to reference checks, offsets, scale factors, drift, and evidence records.
