Limits Protect Hardware
Absolute maximum ratings, recommended operating conditions, pin limits, and package notes define what can damage the part or invalidate performance claims.
6 How to Read Sensor Datasheets
sensors
sensor
types
datasheets
6.1 Start With the Measurement Story
Picture a team choosing a sensor from one bold number on a sales page. The number may change with heat, power, wiring, time, or the way the part is fixed.
First, name the decision the reading must support. Then find the limit, unit, test state, and note that apply to that decision.
A part with a wide range may be less exact where you need it. A fast part may draw more power or need a cleaner signal path.
That is the simple story, but it cannot replace the full sheet or a field test. The review map later in the chapter links each claim to its bounds.
Use the Practitioner section to build and check the part record. Use Under the Hood to study timing, drift, limits, and test claims in more depth.
Plain check
- Find the exact part. Find the exact table. Read each footnote. Save the test state.
- Use Practitioner to record. Use deeper limit checks. Test the real build. Reopen on change.
A datasheet is a promise with conditions attached. Before copying a headline accuracy number, trace the test conditions, limits, pin behavior, timing, calibration notes, and warnings that decide whether the promise applies to your device.
Phoebe’s Field Notes: Why the Sample-Rate Line Isn’t a Suggestion
The mathematical gist. Sampling and ADC resolution are separate information limits. With the chapter’s catalog-typical 400 Hz sampling, a 350 Hz component sits above the 200 Hz Nyquist ceiling and folds to 50 Hz. Its 3.3 V, 12-bit channel has 4096 levels, a 0.806 mV step, 0.233 mV RMS quantisation noise, and an ideal 74.0 dB ceiling; the stated 10 kΩ/5 pF front end settles to half an LSB in about 451 ns.
6.2 Overview: A Datasheet Is an Evidence Map
A sensor datasheet is the starting evidence for whether a part can support an IoT measurement claim. It describes the electrical limits, operating conditions, output behavior, accuracy terms, timing rules, interface requirements, package details, and test conditions for the sensor. It is not proof that the sensor will work in every enclosure, climate, cable run, firmware schedule, or maintenance process.
Read the datasheet against the decision the system must make. A reading for a comfort dashboard, safety warning, battery-powered field node, or calibration lab can require different evidence even when the same sensor family is used. The review should connect datasheet claims to installation conditions and field validation records.
Physical scale and construction are part of that evidence map, not decoration. The IMU photograph makes the multi-sensor breakout and its scale reference visible, while the thermistor photograph shows the bead and leads whose dimensions, coating, and installation method must agree with the datasheet.
Do not read those sections as a checklist of isolated facts. A voltage table can constrain the interface circuit, a timing diagram can constrain the firmware schedule, a package drawing can constrain the enclosure, and an environmental table can narrow the validity of an accuracy claim. The useful record links these sections together.
If you only need the intuition, use this rule: never copy a headline specification into a design until you know its units, operating conditions, min/max limits, interface assumptions, calibration needs, and retest trigger.
Specifications Shape Evidence
Range, accuracy, resolution, noise, response time, drift, and calibration notes decide whether a reading can support the application decision.
Timing and Power Shape Firmware
Startup time, sample interval, conversion time, sleep modes, bus timing, and current draw affect schedules, battery budgets, and stale-data handling.
Conditions Limit Claims
Footnotes and test conditions matter. A value may apply only for a stated supply, temperature range, output load, averaging setting, or calibration state.
6.3 Datasheet Review Record
A datasheet review record prevents selection work from becoming scattered notes. It captures the values that matter, where each value came from, which condition applies, and how the deployment will prove the sensor still behaves acceptably after wiring, firmware, enclosure, and environment are considered.
1. Name the decisionWrite the system decision the sensor reading supports, such as alert, control, trend, diagnosis, billing, or maintenance.
2. Locate the limitsFind operating range, supply limits, interface levels, pin limits, package notes, and environmental constraints.
3. Capture the evidenceRecord accuracy, resolution, response time, drift, noise, calibration, and the datasheet conditions for each value.
4. Check integrationVerify pull-ups, bus timing, addressing, ADC input needs, filtering, startup timing, and firmware sample schedule.
5. Define retestName the change that reopens review: new supplier, firmware mode, enclosure, cable, calibration rule, or installation environment.
Accuracy and precision are different datasheet claims. A sensor is accurate when the average of many readings lands close to the true value — it is fighting AC-type errors and noise that wobble around the truth. A sensor is precise when repeated readings cluster tightly together, even if that tight cluster sits on a fixed DC-type offset from the truth. A part can be precise but inaccurate (tightly grouped, consistently wrong — a calibration fix), or accurate but imprecise (correct on average, but noisy on any single reading — an averaging or filtering fix). That is exactly why the "Measurement quality" review row below asks about accuracy and repeatability separately: one number cannot tell you which failure mode, if either, is present.
Datasheet Area
Review Question
Evidence to Keep
Failure Pattern
Operating conditions
Which voltage, temperature, humidity, load, and package conditions are guaranteed?
Recommended limits, table conditions, package variant, and any footnote that narrows the claim.
Designing near damage limits or assuming a value holds outside the stated operating range.
Measurement quality
Is the reading accurate, repeatable, responsive, and stable enough for the decision?
Accuracy class, resolution, noise, response time, drift, calibration state, and validation method.
Confusing decimal places or repeatability with absolute accuracy.
Interface
Can the controller, wiring, bus, ADC, and firmware schedule satisfy the sensor requirements?
Pinout, pull-up or bias needs, address options, timing rules, startup sequence, and sample interval.
Passing one bench read while ignoring stale data, bus conflicts, load effects, or package-specific pinout changes.
Lifecycle
What changes after installation, aging, replacement, recalibration, or supplier revision?
Revision history, calibration plan, replacement rules, field checks, and the owner of retest evidence.
Freezing the first datasheet value forever even when parts, firmware, or conditions change.
Datasheet review record: - Sensor and exact part/package: - Measurement decision: - Required range and environment: - Supply and interface limits: - Accuracy/resolution/noise/response evidence: - Calibration and drift evidence: - Firmware timing and stale-data rule: - Wiring/package/pinout notes: - Validation test: - Retest trigger:
Two real accelerometer datasheets show what a filled-in review record actually looks like. The Kionix KXSC7-1050 is an analog, ±2 g tri-axis part; the Bosch BNO055 is a digital, multi-range IMU whose accelerometer sub-block is programmable to ±2/4/8/16 g. Reading their tables side by side turns "trace the value to its conditions" from an abstract instruction into a concrete comparison.
Parameter
Kionix KXSC7-1050 (analog, ±2 g)
Bosch BNO055 accelerometer (digital, ±2 g range)
Reading note
Sensitivity
560 mV/g typical (543–577 mV/g min–max)
1 LSB/mg typical, ±1% tolerance at 25°C
Same physical idea — output per g — but one slope is analog volts-per-g and the other is digital counts-per-mg. Convert both to the same units before comparing parts.
Zero-g offset
1.4 V typical (1.26–1.54 V min–max), referenced to the mid-supply point
+80 mg typical (−150 to +150 mg min–max)
Both parts report a typical value sitting inside a much wider guaranteed min/max band — the typical number is not what a random unit off the line will show.
Bandwidth (−3 dB)
50 Hz typical (40–60 Hz min–max), fixed by the analog low-pass filter
Selectable 8–1000 Hz via a programmable 2nd-order digital filter
The BNO055 lets firmware trade bandwidth for noise at runtime; the KXSC7's bandwidth is set once, in hardware, at manufacture.
Output noise density
125 µg/√Hz
150 typical, 190 max µg/√Hz
Multiply by √bandwidth to get RMS noise in g — a wider bandwidth setting always costs noise, on either part.
Cross-axis sensitivity
Not listed on this part's mechanical table
1% typical, 2% max
Cross-axis leakage is how much of an off-axis acceleration shows up on the wrong axis. Silence on one datasheet does not mean the effect is absent — assume it is present unless a table proves otherwise.
Non-linearity
0.1% typical, 0.2% max of full-scale
0.5% typical, 2% max of full-scale (best-fit straight line)
Both are quoted as a percent of full-scale, so the same percentage is a larger absolute error on the BNO055's wider ±16 g range than on the KXSC7's ±2 g range.
The BNO055's own datasheet is candid about this: it labels its non-linearity a "best fit straight line" figure and reports cross-axis sensitivity as a percentage of full-scale — both of which flatter the number compared with reporting absolute error at the reading actually in use. That is the lesson to generalize: a typical value, a best-fit-line spec, or a percent-of-full-scale spec is the datasheet reporting the part in its best light, not a worst-case guarantee for the exact operating point a design will use. Use the min/max columns, not the typical column, for anything safety- or calibration-critical.
6.4 Datasheet Claim Boundaries
Datasheets are written around controlled tests and specified operating ranges. IoT systems add enclosures, power modes, long cables, shared buses, radio bursts, sleep schedules, condensation, vibration, sunlight, dust, replacement parts, and firmware updates. Under the hood, the job is to preserve the datasheet claim or explicitly narrow the application decision.
The hidden risk is that one section can quietly depend on another section. A performance table may assume a specific supply, sampling mode, output load, temperature window, or calibration state. If the installation changes any of those assumptions, the number in the table may still be printed correctly while the field claim is no longer supported.
Electrical Boundary
Supply range, pin current, input voltage, output drive, pull-ups, impedance, grounding, and transient behavior decide whether the part is being operated safely.
Measurement Boundary
Sensor physics, noise, hysteresis, drift, cross-sensitivity, self-heating, placement, and calibration decide how much trust the reading deserves.
Timing Boundary
Startup delay, conversion time, response time, bus transaction timing, averaging, and sleep recovery decide whether data is fresh enough.
Revision Boundary
Datasheet revision, package option, firmware mode, supplier substitution, and board assembly can change the assumptions behind a previous decision.
Boundary Test
What to Vary
Pass Evidence
Retest Trigger
Power mode
Sleep, wake, conversion, radio activity, and low-battery behavior.
Readings remain fresh, valid, and flagged when the device changes power state.
New battery policy, firmware schedule, radio duty cycle, or sensor mode.
Interface loading
Bus length, pull-up value, address selection, ADC source impedance, and sample rate.
Communication is stable and the measured signal is not distorted by the interface.
New controller, cable, board revision, added bus device, or ADC configuration.
Environment
Temperature, humidity, mounting, airflow, vibration, light, dust, and enclosure effects.
Field checks show the sensor remains within the decision's error and response limits.
New enclosure, mounting position, climate, cleaning process, or deployment site.
Replacement
Datasheet revision, package variant, supplier lot, module carrier, and library defaults.
Pinout, electrical limits, calibration, timing, and firmware assumptions still match.
New part number, package, datasheet revision, firmware library, or sourcing route.
6.5 A Datasheet Decision for a Cold-Room Probe
A cold-room sensor bead hangs beside the evaporator in a food store, where wet air freezes on its cable and the controller samples during compressor starts. The product photograph shows the real clues first: the bead is small, but its lead length, coating, and seal also sit inside the measurement path. A sensor datasheet must therefore answer more than “does it sense temperature?” It must show whether this exact probe can survive the room and settle before the next control decision.
Read Figure from the overview toward the appendix. Under the selected sensor limits, the overview names the part and its intended use. The datasheet’s electrical pages set supply, current, and input limits for the cold-room probe. Sensor performance pages qualify range, accuracy, response, noise, and drift. Mechanical and environmental pages then constrain the sensor package, mounting, humidity, shock, and storage. The datasheet appendix closes the path with timing diagrams, reference circuits, and ordering codes. In this selection, a sensor value is usable only when its test condition and exact orderable part travel with it.
Suppose the selected cold-room sensor channel samples at 400 Hz. Its Nyquist limit is (400/2=200\ \text{Hz}), so a 350 Hz disturbance appears at |(350-400)| (=50\ \text{Hz}). The same 3.3 V, 12-bit sensor channel divides full scale into 4,096 levels, giving (3.3/4096=0.000806\ \text{V}), or 0.806 mV per code. Those calculations do not prove the sensor probe is accurate. They show why the datasheet’s sampling-rate row, reference-voltage row, resolution row, and accuracy table answer different questions.
6.5.1 Predict the Datasheet Rows That Decide the Purchase
Check whether every datasheet limit is typical or guaranteed.
Keep the sensor datasheet page number beside every copied limit.
Ordering code matters at the final step. One suffix may change cable length, accuracy grade, connector, or temperature range while leaving the family name unchanged. Record the full sensor code and datasheet revision beside the cold-room test. When the supplier substitutes a suffix, repeat the rows and conditions that the change can affect.
Maximum ratings are not operating targets. A probe that survives 5 V at an input may still specify valid measurements only from a 3.0–3.6 V supply. Design to the operating table and use the maximum table to avoid damage during faults.
- Predict: A timing table lists a 600 ms startup and a 250 ms conversion, while the controller needs a fresh value 500 ms after wake-up. Will this order work unchanged? Check: No. The earliest stated value arrives after 850 ms, so the sensor schedule misses the 500 ms decision.
- Predict: The accuracy headline says ±0.2 °C, but its footnote limits that value to 0–50 °C. Can it support a −18 °C freezer claim? Check: Not from that row. The cold-room decision needs the accuracy or calibration limit that covers −18 °C and the chosen probe code.
6.6 Summary
Reading a sensor datasheet means turning component claims into design evidence. Start with the measurement decision, then verify operating limits, measurement quality, timing, interface requirements, calibration needs, package details, and revision boundaries. Keep a review record that names the datasheet conditions and the field tests that prove the sensor still supports the IoT decision.
Key Takeaway
Do not treat a datasheet headline as a field guarantee. A useful datasheet review ties each value to conditions, integration assumptions, validation evidence, and a retest trigger.
6.7 See Also
Sensor Specifications
Review accuracy, resolution, precision, drift, response time, and evidence terms before reading detailed tables.
Sensor Selection Guide
Use datasheet evidence to compare candidate sensors against a real application decision.
Sensor Circuit Fundamentals
Connect datasheet limits to biasing, loading, ADC behavior, grounding, and circuit evidence.
Sensor Communication Protocols
Check bus timing, addressing, pull-ups, diagnostics, and stale-data behavior when integrating digital sensors.