Dew Point / RH / Temperature Sensor AFE Design
← Back to: Industrial Sensing & Process Control
Core idea: Dew point is the actionable condensation risk metric—compute it from RH and temperature only after proper linearization, calibration, and time-aware filtering, then compare it against surface temperature to get a reliable dew margin. A robust design treats coefficient lifecycle (NVM integrity), duty-cycling, and placement/error budget as first-class engineering constraints so field readings stay trustworthy.
Definition Block: What This Page Answers
Relative humidity (RH) describes how close air is to saturation at a given temperature, while dew point (Td) is the temperature where that air would become saturated and start condensing. In practical designs, dew point is the actionable metric because condensation risk depends on whether a surface temperature (Ts) falls below Td, not on RH alone. This page focuses on sensor AFEs, linearization & calibration stored in NVM, low-power MCU workflows, and industrial-bus reporting with diagnostics.
What will be built here
- How RH and temperature sensors are read by an AFE, corrected, and used to compute dew point and dew margin.
- How linearization and calibration coefficients are created, stored safely in NVM, and verified over the product lifecycle.
- How a low-power MCU publishes stable measurements and health diagnostics over industrial buses with provenance signals.
Jump links (anchors exist now; deeper sections can be added later)
Measurement Basics: RH vs Absolute Humidity vs Dew Point
RH is temperature-dependent. RH reports the fraction of saturation at the current air temperature, so the same RH value can imply very different moisture content and condensation behavior at different temperatures. Absolute humidity (water vapor amount per air mass or volume) is more stable for process comparison, but it still does not directly answer “will water condense on this surface?”
Dew point (Td) converts RH and air temperature into a condensation-relevant temperature. Condensation becomes likely when a local surface temperature (Ts) drops below Td. For engineering decisions and alarms, the most useful scalar is: dew margin = Ts − Td. A negative margin indicates that the surface is colder than the air’s dew point and is inside the condensation zone.
Minimum viable telemetry (for reliable decisions)
- RH(%) — measured at the sensor location
- T(°C) — air temperature at the sensor
- Td(°C) — computed dew point
- Ts(°C) — surface temperature (recommended whenever condensation matters)
- dew margin (°C) — Ts − Td, the decision scalar for thresholds, logging, and trends
Sensor Front-End Taxonomy: What Is Being Interfaced
Humidity and temperature “sensors” are not one interface type. The front-end design depends on whether the sensing element behaves like a capacitance, a resistance, or a digitized temperature source. This section maps each element class to what the AFE must provide (excitation, readout domain, reference strategy) and to the dominant failure modes that cause field drift.
Humidity elements (high-level)
- Capacitive polymer RH: dominant in modern designs; pF–nF-level capacitance change with very high input impedance needs.
- Resistive RH: less common; wide resistance range, stronger sensitivity to bias/self-heating and input bias currents.
Temperature elements (high-level)
- Bandgap IC temperature: integrated digital or analog temperature output; simplified analog front-end needs.
- NTC/PTC: external thermistor; non-linear resistance requiring controlled excitation and ratiometric ADC practices.
- RTD: industrial-grade resistance temperature detector; lead resistance and wiring method dominate accuracy.
What the AFE must provide (by element)
- Capacitive RH: gated excitation + capacitance-to-time/frequency/code conversion; strict control of leakage and parasitics.
- Resistive RH: biasing (constant current or voltage) + resistance measurement; manage self-heating and bias-current errors.
- NTC/RTD: stable excitation, ratiometric measurement, and (for RTD) lead resistance mitigation through wiring method awareness.
Selection matrix (interface demand, not application)
- Input nature: capacitance vs resistance vs digitized temperature
- Best readout domain: time / frequency / ratio / ADC counts
- Critical AFE traits: input leakage, reference stability, excitation gating, dynamic range
- Typical pitfalls: PCB contamination, self-heating, lead resistance, thermal gradients
- Evidence fields: raw counts, reference counts, VDD, status flags, sample age
AFE Architectures: Implementable Signal Chains
A practical RH/T front end is defined by two choices: how the element is excited and which domain is measured (time, frequency, ratio, or ADC code). Reliable designs also standardize a small set of evidence fields so field anomalies can be localized to input leakage, reference drift, ADC behavior, or excitation timing—without relying on application-specific assumptions.
Excitation strategies
- Capacitive RH: charge/discharge timing; oscillator-based C→f conversion; sigma-delta / switched-cap conversion for noise robustness.
- Resistive elements: constant current (simple R=V/I mapping) or constant voltage (simple biasing); both require self-heating awareness.
- Gating: short, controlled excitation windows reduce average power and limit self-heating while preserving repeatability.
ADC strategy
- Ratiometric measurement: ratio to a known reference path cancels reference drift and supply variation.
- Oversampling vs duty-cycling: oversampling reduces noise but increases power; duty-cycling saves power but requires warm-up control and stable timing.
Dominant front-end error sources
- Input node: leakage from PCB contamination and humidity films; parasitic capacitance; input bias currents.
- Reference & excitation: Vref drift, excitation amplitude drift, timing jitter, supply coupling.
- Conversion: ADC quantization and sampling artifacts; counter resolution limits in timing-based methods.
Evidence fields (minimum debug log)
- raw counts: C_raw / R_raw / T_raw
- reference counts: ref path counts (ratio baseline)
- VDD: supply voltage at measurement time
- AFE flags: warm-up, saturation, open/short, NVM invalid
- sample age: time since last valid update
Linearization & Compensation: Turning Raw Into Accurate RH/T
Linearization and compensation convert raw front-end measurements into stable, comparable RH and temperature values. The design goal is not only numerical accuracy but also maintainability: calibration models must be explainable, versioned, and diagnosable in the field. This section frames nonlinearity as observable error shapes and then maps those shapes to practical model choices that fit low-power MCU constraints.
Common nonlinearity types (as observable error shapes)
- RH sensitivity curve: slope varies across RH range; residual error forms a systematic curve rather than random noise.
- Hysteresis: rising vs falling humidity produces different outputs under similar conditions; history affects the reading.
- Temperature coupling: the RH element shifts with temperature; compensation must use temperature as a first-class input.
Compensation strategy (implementation order)
- Normalize raw: prefer ratio/ratiometric forms so reference and supply drift is reduced early.
- Temperature-correct RH: apply temperature compensation before nonlinearity correction when the element is strongly temperature-coupled.
- Model the curve: use multi-point calibration via piecewise-linear or polynomial only within a defined valid range.
- Respect dynamics: hysteresis and response time require filtering and reporting policy to prevent “jumping” outputs.
Real-world detail: hysteresis + response time
- Filtering is needed because dew-point decisions amplify noise near thresholds; unstable RH creates unstable Td and false alarms.
- Reporting policy should expose provenance: warm-up state, saturation clamping, and coefficient validity (CRC / version).
| Model | NVM footprint | Compute cost | Robustness | Best fit (engineering) | Failure symptom |
|---|---|---|---|---|---|
| 2-point slope + offset |
lowest 2–3 coeff |
lowest | good for mid-range weak at extremes |
threshold/control use where tight absolute accuracy is not required | systematic end-range bias; poor extrapolation outside calibration points |
| 3–5 point piecewise linear |
moderate N segments |
low–moderate | high predictable |
most production systems: explainable, diagnosable, easy to version and roll back | localized segment bias when a point is wrong; easy to detect via residual patterns |
| Polynomial bounded range |
low–moderate few coeff |
moderate | variable numeric risk |
only when input range is constrained and numeric stability is controlled (format, scaling, saturation) | edge instability; coefficient drift causes large errors; dangerous outside intended range |
Dew Point Computation: Robust Firmware Design
Dew point computation must be designed as a firmware pipeline, not as a standalone formula. Reliable implementations manage input validity, numeric safety, and stability near thresholds. The output must carry provenance so field systems can distinguish valid measurements from clamped, frozen, or fault states.
Inputs and computation options
- Inputs: RH and air temperature are primary; pressure may improve absolute accuracy but should remain optional.
- Approximate Td: suitable for control thresholds where dew margin bands dominate decisions.
- Higher-accuracy Td: used when tight dew margins are required; must be bounded and numerically guarded.
Firmware engineering details
- Fixed-point vs float: choose based on MCU resources; both require explicit scaling, bounding, and saturation rules.
- Saturation handling: RH spikes above 100% must be clamped with a visible flag; sensor faults must not be silently masked.
- Filtering order: filtering RH/T before Td typically improves stability because dew-point mapping is nonlinear near thresholds.
Do not do this (common pitfalls)
- Computing Td from unfiltered RH and triggering alarms on instantaneous dew margin crossings.
- Ignoring warm-up stabilization time and treating early samples as fully valid.
- Clamping RH without setting flags (silent correction) and losing fault provenance.
- Using Td alone without dew margin (Ts − Td) and alarm hysteresis/debounce near the boundary.
Calibration Strategy: Factory + Field and Coefficient Lifecycle
Long-term accuracy is maintained by treating calibration as a lifecycle: factory characterization produces coefficients with traceable metadata, field operation monitors drift and condensation exposure, and only bounded adjustments are allowed without controlled references. The objective is to avoid silent “re-fitting to the wrong reality” while keeping dew-point alarms stable across aging and contamination.
Factory calibration (production-friendly)
- Multi-point RH: cover low/mid/high RH so end-range nonlinearity is captured.
- Temperature points: at least a small set of temperature corners to model temperature coupling.
- Stabilization: only accept readings after the system reaches steady-state (rate-of-change based), not after a fixed delay.
- Coefficient package: store coefficients together with metadata (timestamp, lot, UID, format version).
Field calibration / reconditioning (bounded by policy)
- Drift causes: contamination films, long-term aging, and condensation exposure that distorts recovery behavior.
- Allowable adjustment: limited offset correction when drift is moderate and plausibility checks pass; avoid changing curve shape without controlled references.
- Full recalibration: only under controlled references (chamber or traceable standards); otherwise it risks locking in a wrong curve.
Drift monitoring (plausibility rules + event counters)
- Rate limits: RH/T jump-rate bounds detect bad samples, condensation transients, or sensor instability.
- Td sanity bounds: flag numerically impossible or physically inconsistent dew-point outputs.
- Condensation exposure: count dew-margin-negative events and correlate with step changes in drift score.
- Optional self-test: conceptual heater-based checks can confirm recovery behavior and contamination risk (when supported).
Calibration NVM Design: Integrity, Wear, and Rollback Safety
Calibration storage must remain reliable under power-loss, brownouts, and partial writes. The design should guarantee a “last known good” coefficient set, reject corrupted or mismatched formats, and provide predictable recovery behavior. A/B slotting with an atomic commit pattern is the most production-friendly approach: write a new slot, verify it, then switch active state only after integrity checks pass.
What to store (split payload vs header)
- Payload: coefficients, model_type, temperature compensation parameters, and bounded valid ranges.
- Header: format_version, calibration_version, sensor UID, last_cal_timestamp, and coeff_crc.
- Rule: firmware must validate the header before trusting any payload bytes.
Integrity & robustness (atomic update)
- CRC + versioning: detect corruption and incompatible formats after firmware updates.
- A/B slots: keep one last-known-good slot available for rollback at all times.
- Atomic pattern: write → verify → set commit → switch active; never switch active on an unverified slot.
Wear management (write rules)
- Do not write every boot: only write on real calibration events, approved field offsets, or controlled maintenance actions.
- Event-driven updates: consolidate counters and avoid frequent page erase cycles; batch updates when possible.
Validation checklist (expected behavior)
- Power-loss during write: active slot remains unchanged; new slot is ignored until verified and committed.
- Brownout during switch: boot-time logic must choose a committed+CRC-valid slot; never point active to a half-written bank.
- Corrupted bank: CRC fail triggers automatic fallback to the other slot; both bad triggers safe mode (invalid output + flags).
- Format mismatch: reject payload if format_version is incompatible; prefer last known good or safe mode.
Low-Power MCU Orchestration: Duty-Cycling Without Breaking Accuracy
Multi-year battery life is achieved by optimizing the full duty-cycle workflow—not by sleeping longer at any cost. The critical constraint is measurement validity after wake-up: humidity sensors often need settling, and dew-point decisions amplify noise near thresholds. A robust design therefore uses a small state machine with explicit validity gates, plus filtering that respects the actual time between samples.
Duty-cycle states (a production-friendly loop)
- Sleep: keep RTC/timers and minimal provenance; avoid writing NVM.
- Warm-up: power sensor + AFE, wait for stabilization using a rate-of-change gate (not only fixed delay).
- Sample burst: capture a short cluster of samples; reject early transients and outliers.
- Compute: linearize → time-aware filter → compute Td → dew margin → flags.
- Transmit: report-on-change and state-change triggers; include sample age and flags.
Sensor stabilization nuance (why warm-up cannot be “one number”)
- RH settling: humidity elements may recover slowly after power-up, especially after condensation exposure.
- Steady-state gate: treat warm-up as “signal stable enough” (bounded change-rate) rather than a constant timeout.
- Burst handling: discard early samples and prefer median/trimmed statistics before applying long-term smoothing.
Filtering under low duty-cycle (time-constant awareness)
- Time-aware EMA/IIR: filter strength should adapt to the real sample_interval so the effective time constant stays consistent.
- Order matters: filtering RH/T before Td typically reduces false condensation alarms caused by nonlinear mapping.
- Threshold reporting: combine numeric change thresholds with alarm-state transitions to reduce needless transmissions.
Report-on-change rules (battery + robustness)
- Report only on meaningful deltas: RH, Td, or dew margin crosses a configured band, not every small fluctuation.
- Always report state changes: td_valid, saturation, sensor_fault, nvm_invalid, or alarm_state transitions.
- Stale-data behavior: if a reading is not refreshed, publish stale flags and sample age rather than repeating old numbers.
Industrial Bus Options: Data Modeling and Diagnostics Payload
Field buses differ in framing and transport, but robust deployments converge on the same data model: deliver measurements (RH/T/Td/dew margin), publish health flags that prevent misuse, and include provenance so controllers can detect stale or invalid data. The most valuable part is not the register numbers but the object boundaries and the rules that make diagnostics reliable over years.
Layers you may meet (kept high-level)
- Local: I²C/SPI from sensor/AFE to MCU (focus: read integrity and clear fault signaling).
- Field: RS-485/Modbus via transceiver, CAN object mapping, IO-Link object mapping (focus: consistent objects + provenance).
What to expose (object groups)
- Measurements: RH, T, Td, dew margin (and optional surface temperature if available elsewhere).
- Health flags: sensor_fault, saturation, nvm_invalid, heater_active.
- Counters: condensation_event_counter, crc_error_counter (monotonic behavior preferred).
Robustness rules (prevent control misuse)
- Timestamping / sample age: include sample_age so PLC/SCADA can reject stale values.
- Stale-data flags: publish explicit stale when warm-up is incomplete, sensor not updated, or NVM invalid.
- Monotonic counters: counters must be monotonic within uptime; resets must be detectable via uptime or reboot flags.
Layout, Placement, and Real-World Error Budget
Many RH/T builds fail after integration because the dominant error is mechanical, thermal, or contamination-related—rather than sensor silicon. A practical design treats placement, airflow, condensation exposure, and PCB leakage as first-class error sources, then proves the dominant contributor with targeted validation tests (humidity step, thermal ramp, and condensation challenge).
Placement traps (the usual root causes)
- Heat sources bias temperature: proximity to LEDs, power stages, inductors, or rectifiers creates local hot spots that distort Td and dew margin.
- Airflow vs enclosure lag: sealed housings and dead zones introduce diffusion/venting time constants; readings become “historical” during fast ambient changes.
- Condensation on the sensor: surface water films push RH toward saturation and create long recovery tails; dew-risk logic must treat this as an event state, not noise.
PCB-level concerns (high-impedance + leakage)
- Guarding for high-impedance nodes: capacitive RH front-ends can be dominated by board leakage and parasitics; guard rings and controlled creepage help redirect leakage paths.
- Contamination / flux residues: hygroscopic films create humidity-dependent leakage and drift that is repeatable in high RH—even if the lab bench looks stable.
- Protection without distortion: ESD/TVS must not add excessive leakage or capacitance on sensitive nodes; placement and leakage class matter.
Error budgeting (stack the contributors, then identify the dominant one)
- Sensor intrinsic: accuracy, hysteresis, response time, and long-term drift.
- AFE + reference: offset, noise, reference drift, input bias/leakage, and parasitics.
- Thermal gradients: local temperature bias due to heat paths and airflow differences.
- Sampling strategy: warm-up gates, duty-cycle cadence, filtering time-constant mismatch, and threshold chatter.
Validation tactics (prove what dominates)
- Humidity step response: identify enclosure/airflow time constant vs sensor/AFE behavior; capture rise/fall asymmetry and lag.
- Thermal ramp: sweep ambient temperature and load power; quantify temperature bias vs heat source distance and mounting.
- Condensation challenge: intentionally cross Ts < Td to trigger condensation; measure recovery tail and correlation with condensation_event_counter.
MPN examples (reference parts for typical implementations)
Parts below are examples commonly used in RH/T + dew-point nodes. Selection depends on accuracy, power, bus, and environmental constraints.
| Function block | Example MPNs | Why it matters in H2-11 (layout/error-budget angle) |
|---|---|---|
| Digital RH/T sensor | Sensirion SHT41, SHT45, SHT31; TI HDC2080 | Placement and airflow dominate time response; condensation recovery tails must be characterized per mounting. |
| RTD/NTC ADC front-end | TI ADS122C04, ADS124S08; ADI AD7124-8 | High-impedance and reference behavior impacts drift; routing/leakage and thermal gradients can dominate system accuracy. |
| Precision reference | ADI ADR4525; TI REF5025, REF5050 | Reference drift and thermal coupling become visible during thermal ramp tests; keep away from heat islands. |
| Low-power MCU | ST STM32L052; TI MSP430FR2355; Microchip SAMD21 | Sampling strategy (warm-up gates, cadence) directly affects error budget; evidence fields and event counters rely on MCU integrity. |
| RS-485 transceiver | TI SN65HVD75; Analog Devices/Maxim MAX3485E | Field wiring and transients can cause stale/invalid data; robust diagnostics payload prevents “good numbers, wrong truth”. |
| CAN transceiver | TI TCAN1051; Microchip MCP2562FD | Noise and grounding issues often look like sensor errors; include sample_age + counters to separate comm faults from physics. |
| IO-Link device/PHY | TI TIOL111-5; Analog Devices/Maxim MAX14827 | Object modeling matters more than register addresses; include provenance so PLC logic can reject stale readings. |
| ESD/TVS (I/O protection) | Littelfuse SMF05C; Nexperia PESD5V0 series (example) | Leakage/capacitance of protection can corrupt high-impedance measurements; placement and leakage class impact humidity-dependent drift. |
Request a Quote
FAQs (Troubleshooting Index)
Each FAQ below maps back to the measurement evidence fields and a specific section that explains the fix. The goal is consistent diagnosis: first confirm the dominant contributor (algorithm, calibration/NVM, placement/layout, or data model), then apply the corresponding design rule.
MPN quick refs (examples)
These are common reference parts used in RH/T nodes and diagnostics paths; select based on accuracy, power budget, bus, and environmental constraints.
| Block | Example MPNs | Typical use in this page |
|---|---|---|
| RH/T sensor | Sensirion SHT41, SHT45, SHT31; TI HDC2080 | RH/T acquisition with condensation recovery characterization (H2-11) and Td stability (H2-6/H2-9). |
| RTD/NTC ADC | TI ADS122C04, ADS124S08; ADI AD7124-8 | Ratiometric temperature measurement; thermal gradient diagnosis near heat sources (H2-11). |
| Reference | ADI ADR4525; TI REF5025, REF5050 | Reference stability during thermal ramps; avoid heat islands (H2-11). |
| Low-power MCU | ST STM32L052; TI MSP430FR2355; Microchip SAMD21 | Duty-cycle orchestration, evidence logging, and safe coefficient handling (H2-8/H2-9). |
| RS-485 | TI SN65HVD75; ADI/Maxim MAX3485E | Field bus transport; alarms must include stale/sample_age and flags (H2-10). |
| CAN | TI TCAN1051; Microchip MCP2562FD | Object mapping with provenance and monotonic counters (H2-10). |
| IO-Link | TI TIOL111-5; ADI/Maxim MAX14827 | Protocol-agnostic data model: measurements + health + provenance (H2-10). |
| ESD/TVS | Littelfuse SMF05C; Nexperia PESD5V0 series (examples) | Protection with leakage-aware placement for high-impedance nodes (H2-11). |
1 RH looks stable but dew point jumps — is the filtering order wrong?
Short answer
Dew point “jumping” with stable RH is usually a processing artifact: inconsistent filtering (or time-constant mismatch) makes the nonlinear Td mapping amplify noise near thresholds.
What to check
- Compare RH_raw vs RH_filt, T_raw vs T_filt, and Td computed from each; log sample_interval.
- Verify whether filtering is time-aware under duty-cycling and whether Td is computed from filtered inputs.
Go deeper
2 After a condensation event, RH reads too high for hours — contamination or sensor saturation?
Short answer
Hours-long “high RH” after condensation is typically physical recovery (water film/adsorption) or contamination-driven leakage, not a simple calibration offset.
What to check
- Track condensation_event_counter, recovery time, and flags like saturation/sensor_fault across repeats.
- Correlate RH error with high-humidity exposure; rising drift_score suggests contamination/leakage effects.
Go deeper
3 Two units in the same room differ by ~6%RH — calibration model or placement gradient?
Short answer
Large unit-to-unit differences in the same room are often dominated by placement: local temperature bias, airflow dead zones, or enclosure lag can look like “bad calibration.”
What to check
- Compare T_local (near the sensor) versus a reference point; examine dew_margin and sample_age.
- Check calibration_version and coefficient metadata to rule out mismatched models.
Go deeper
4 Factory calibration drifts after a month — NVM corruption or sensor aging?
Short answer
Distinguish “coefficients changed/lost” from “sensor drifted”: NVM integrity failures cause abrupt model/version anomalies, while aging shows gradual, environment-correlated deviation.
What to check
- Read coeff_crc, calibration_version, and last_cal_timestamp; watch for sudden jumps after power events.
- Trend drift_score over time; stable CRC with rising drift suggests sensor/environment effects.
Go deeper
5 Capacitive RH readings are noisy — parasitics/leakage or ADC/reference issues?
Short answer
Capacitive RH noise often comes from leakage/parasitics that vary with humidity or contamination, and it can be amplified by reference/supply variation in the AFE chain.
What to check
- Log C_raw variance (or timing counts), supply_v, and reference-related counts; check humidity-correlation of noise.
- Inspect for contamination and verify guarding/creepage around high-impedance nodes.
Go deeper
6 Deep sleep saves power but accuracy got worse — warm-up and duty-cycle timing?
Short answer
Accuracy degradation after aggressive sleep usually indicates insufficient stabilization or a filter that ignores changing sample intervals; the fix is a quality-gated state machine.
What to check
- Review warmup_ms, sleep_ratio, sample_interval, and whether stale/td_valid behaves correctly.
- Compare burst statistics vs single-shot sampling to quantify transient bias.
Go deeper
- Follow H2-9 (warm-up gates + time-aware filtering).
7 Td indicates risk but no condensation occurs — is surface temperature missing?
Short answer
Dew point indicates the air’s saturation threshold, but condensation risk is determined by the surface temperature; without Ts, alarms can be “correct Td, wrong risk.”
What to check
- Compute and log dew_margin = Ts − Td; include Td, Ts (if available), and alarm_state.
- Validate with a controlled test where Ts is deliberately driven above/below Td.
Go deeper
- Revisit H2-2 (dew margin and risk logic).
8 Modbus shows values but alarms are inconsistent — stale-data flags or register model?
Short answer
Inconsistent alarms with “good numbers” usually indicate missing provenance: controllers act on outdated samples or ignore health flags because the data model does not make validity explicit.
What to check
- Confirm sample_age, stale flag, and alarm_state are exported and interpreted consistently.
- Trend crc_error_counter or transport error counters to separate comm issues from sensing physics.
Go deeper
- Use H2-10 (measurements + health + provenance object model).
9 Calibration update bricked devices sometimes — A/B commit sequence?
Short answer
Intermittent bricking during calibration updates is almost always an atomicity problem: power-loss during write/verify/commit leaves no valid bank or an ambiguous active pointer.
What to check
- Log active_bank, commit_flag, and coeff_crc before/after update; capture reset cause (brownout).
- Run power-cut tests specifically during the commit window and confirm rollback behavior.
Go deeper
- Follow H2-8 (A/B slot + commit state machine).
10 RH exceeds 100% sometimes — how to clamp and log without hiding faults?
Short answer
Clamp RH only for downstream stability (Td and alarms), but preserve the raw condition with explicit flags so diagnostics still reveal saturation, condensation, or sensor faults.
What to check
- Keep RH_raw and export saturation flag/sensor_fault; record sample_age and event counters.
- Verify Td is computed from a “safe RH” value while logs retain the original out-of-range reading.
Go deeper
11 NTC vs IC temperature sensor — why does dew point get biased near heat sources?
Short answer
Near heat sources, the dominant issue is not sensor type but measurement location: local hot spots bias T, which shifts Td and dew margin even when RH is correct.
What to check
- Compare T_local vs a reference point under different load powers; track Td and dew_margin drift with power state.
- Check airflow and thermal path: the “temperature-of-interest” must match the physics of condensation risk.
Go deeper
12 How to prove system accuracy in production quickly?
Short answer
Fast production proof relies on a short, repeatable test that checks both coefficient integrity and dynamic response, rather than attempting full environmental characterization on every unit.
What to check
- Verify coeff_crc, calibration_version, and last_cal_timestamp; reject units with NVM invalid flags.
- Run a compact step/ramp screening and record response time plus a drift_score baseline.
Go deeper
