26 Sensor Power: Accuracy and Field Hardening

26.5.1 Start With the Measurement Story

26.5.1.1 Make the Reading Survive the Site

Firmware is the software stored inside a device. Latency is the time between an event and the result that depends on it.

Picture a water-level sensor on a cold, wet pump site. It reads well on the bench. In the field, cable strain, weak battery power, moisture, and a slow network can turn one fault into a believable but wrong value.

Build a threat list before choosing protection. Include the coldest start, the lowest useful battery level, vibration, water entry, dirty connectors, blocked vents, and lost communication. For each threat, name the expected sign, the limit for safe use, and the fallback. Keep raw reading, time, unit, quality flag, and device identity together.

Then run the checks in combinations, not only one at a time. A cold battery during retries may fail where either test alone passes. This review does not prove all future weather or ageing. It defines the tested envelope. The deeper sections show how calibration, power design, filtering, enclosure choices, and maintenance evidence support that boundary.

A field sensor has to be accurate after vibration, moisture, temperature swings, and low battery states. The design starts by naming the threats and deciding which protection, calibration, and evidence checks keep the reading usable.

The mathematical gist. With fixed-resistor excitation, current follows battery voltage and self-heating follows its square: $\Delta T\propto V_{batt}^2$. Drooping from the chapter’s 3.6 V fresh rail to 3.0 V gives $(3.0/3.6)^2=0.694$, so a 0.10 °C fresh-cell rise becomes 0.0694 °C. But the excitation signal also falls to 83.3%, so the smaller thermal error can hide worsening resolution.

Math Bridge · guided foundationsWhy can a depleted battery hide self-heating?Let Phoebe connect rail voltage, excitation current, squared heating, and lost signal. Learn the maths Check your understanding: Use the questions below to check the key idea

26.5.2 Learning Objectives

After this page, you should be able to:

• Explain how self-heating and settling delay can make low-power readings inaccurate.
• Calculate when excitation current violates a temperature sensor’s self-heating error budget.
• Configure wake-source and adaptive-sampling patterns without hiding recovery costs.
• Build a field-hardening checklist for radio bursts, peripherals, wake latency, and battery behavior.

26.5.3 Why This Follows the Main Power Chapter

Low-Power Sensor Networks builds the normal wake-read-transmit-sleep cycle. This page tests the cycle against the failure modes that appear after deployment: the sensor warms itself, conversion timing changes the reading, firmware sleeps without a recovery path, or adaptive sampling saves energy while losing important events.

26.5.4 Saving Power Can Corrupt the Measurement

Low-power sensor nodes live by duty-cycling: sleep, wake, read, sleep again. But two power-related effects sit directly between "save energy" and "get a correct reading," and both are easy to miss because the data still looks plausible.

The first is self-heating: the very current you push through a resistive sensor to read it dissipates power and warms the element, biasing a temperature reading upward. The second is warm-up and settling: a sensor that was just powered on after sleep has not yet stabilised, so an eager reading taken too soon is wrong. Both are trade-offs of energy against accuracy.

A practical power plan therefore starts with a measurement-quality budget, not just a battery-life target. For a thermistor node, for example, the designer chooses the excitation current, the on-time, the settling delay, and the radio schedule together. Reducing current may improve battery life but lower ADC signal-to-noise ratio; increasing current may clean up the code but heat the sensing element; shortening the delay may save milliseconds but sample a filter that is still moving.

The field symptom is subtle: the node seems reliable because it wakes on schedule and uploads data, yet its readings shift with sample rate, enclosure airflow, or firmware changes. When changing a power setting changes the measured value, the measurement chain is part of the power design. Treat each wake cycle as a small experiment: energise the sensor, wait for the documented condition, convert, verify the result is within range, transmit only when needed, and then sleep. If the number changes after only the sleep interval changes, investigate timing before recalibrating the sensor.

Overview Knowledge Check

26.5.5 Self-Heating Math and Excitation Budget

The temperature error from self-heating is the dissipated power divided by the sensor's dissipation constant (a datasheet figure in milliwatts per degree):

Power dissipated:  P = I^2 × R
Self-heat error:   ΔT = P / δ
δ = dissipation constant (mW per °C), from the datasheet

Thermistor, dissipation constant δ = 2 mW/°C (still air).

Read with sense power P = 0.2 mW:
  ΔT = 0.2 / 2 = 0.10 °C error   (small, tolerable)

Push 2x the current for a bigger signal. Because
P = I^2 R, power rises 4x to 0.8 mW:
  ΔT = 0.8 / 2 = 0.40 °C error

Push 4x the current -> 16x power = 3.2 mW:
ΔT = 3.2 / 2 = 1.6 °C error

Use the equation as a gate before firmware is considered done. If the error budget allows only 0.25 °C of self-heating and the dissipation constant is 2 mW/°C, the excitation budget is 0.5 mW. A 10 kΩ thermistor at that limit can carry only about 0.22 mA, because I = sqrt(P/R) = sqrt(0.0005 W / 10000 Ω). A convenient 1 mA test current would dissipate 10 mW and create about 5 °C of self-heating in the same condition.

That arithmetic explains why production firmware often pulses a divider or sensor rail through a MOSFET, discards the first sample after wake, averages only inside a bounded measurement window, and stores the actual excitation time with the reading. The goal is not the lowest instantaneous current; it is a repeatable energy packet whose thermal error, ADC noise, and settling time are all known.

Practitioner Knowledge Check

26.5.6 Warm-Up, Airflow, Accuracy

Duty-cycling introduces its own errors on top of self-heating, and they interact in ways that shape the whole power budget.

Warm-up is both an energy event and a measurement-validity interval. The average-current ledger in Figure 26.1 includes warm-up, radio use, and exception reserves that a sleep-current headline omits.

Shows: Figure 26.1: Power budget ledger separating sleep baseline, sensor warm-up, radio transaction, exception states, and reserve margin.

+

Show text version

Read Figure 26.1 against its Budget ceiling 38 µA: the Sleep baseline consumes 10 µA and the Sensor warm-up contributes another 4.4 µA even though the sensor draws 8 mA for only two seconds each hour. The Radio transaction adds 8.3 µA for transmit, receive, acknowledgement, and retry risk, bringing the Normal measured total to about 23 µA. Exception states—cold start, weak signal, update, and diagnostics—then occupy the remaining field margin rather than disappearing from the calculation. The ledger explains the section’s operating rule: power the sensing element long enough to settle in its real airflow and temperature environment, accept readings only after that interval, and preserve reserve for the conditions most likely to extend it.

The ledger view also changes how failures are budgeted. A node that normally sleeps for 99% of the hour may still need a reserve for cold starts, low-battery retries, cloud outages, or a stuck sensor that forces extra reads. If the normal cycle already consumes the whole budget, exception paths drain the battery first and accuracy degrades next as firmware starts cutting settle time to recover.

The design that wins treats accuracy and energy as one coupled problem: pulse the excitation to limit self-heating, allow just enough settling time for the required accuracy, measure the radio burst separately from the sensor warm-up, and pick a sensor whose thermal and electrical time constants fit the duty cycle. Optimising energy while ignoring settling gives a node that lasts for years and reports numbers that were never quite right.

Under-the-Hood Knowledge Check

26.5.7 ESP32 Deep-Sleep Wake Sources

The ESP32 offers multiple wake sources for deep sleep mode (see also Common Power Pitfalls for what happens when you forget to configure one):

• Timer wake — esp_sleep_enable_timer_wakeup(microseconds) — Most common for periodic sensing.
• GPIO wake (EXT0) — Wake on single RTC GPIO pin state change (e.g., button press, PIR sensor).
• GPIO wake (EXT1) — Wake when multiple RTC GPIOs match condition (AND/OR logic).
• Touchpad wake — Wake on capacitive touch sensor activity (ESP32 has 10 touch-capable pins).
• ULP coprocessor — Ultra-low-power coprocessor can monitor sensors and wake main CPU only when thresholds are exceeded.

ESP32 power mode comparison:

26.5.8 Concept Check: Deep Sleep Wake Sources

26.5.9 Basic Deep Sleep

Goal: Make ESP32 read a sensor, send data, then sleep for 10 minutes.

Code structure:

#include <esp_sleep.h>

void setup() {
    // Read sensor
    float temp = readTemperature();

    // Send data (Wi-Fi or LoRa)
    sendDataToCloud(temp);

    // Configure wake timer
    esp_sleep_enable_timer_wakeup(10 * 60 * 1000000ULL); // 10 minutes in µs

    // Enter deep sleep
    esp_deep_sleep_start();
}
void loop() { /* Never runs */ }

Expected result: Current drops from 80mA active to 10µA sleep

26.5.10 Power-Aware Sensor Fusion

Goal: Combine GPS + accelerometer + barometer, but only wake GPS when movement detected.

Strategy:

• Accelerometer runs continuously (low power)
• GPS off unless accelerometer detects motion
• Barometer updates every minute
• Transmit fused data every 5 minutes

Power savings: GPS uses 40-60mA. In this movement-gated GPS design, assume motion is rare enough that running GPS only when moving saves over 80% of its active energy.

26.5.11 Variance-Based Adaptive Sampling

Goal: Sample faster when sensor values change rapidly, slower when stable.

Algorithm:

Start by calculate rolling standard deviation of last 10 readings. Then if stddev > threshold: sample every 10s. Next if stddev < threshold: sample every 60s. Finally transmit only when value changes by >5%.

Challenge: Implement this for temperature sensor with automatic adaptation

26.5.12 Try It: Adaptive Sampling Power SavingsTry: Adaptive Sampling Power Savings

26.5.13 Concept Relationships

26.5.14 Release Checklist

Before accepting a low-power sensing design, capture this evidence:

Start by measured sleep, sensor-warm-up, conversion, and radio currents as separate ledger entries. Then a self-heating estimate for the highest excitation current used in firmware. Next a settling-time check showing when the first valid post-wake reading is allowed. After that a configured wake source plus a development fail-safe wake path. Continue by adaptive-sampling thresholds with proof that rapid events are not skipped. Finally cold-temperature, low-battery, retry, and network-outage behavior.

26.5.15 See Also

Start by Low-Power Sensor Networks - main power-management workflow. Then Sensor Data Processing - filtering and event detection before transmission. Finally Sensor Calibration Techniques - accuracy evidence over time.

26.5.16 What’s Next

Return to Low-Power Sensor Networks for the module path, or continue to Common Sensor Mistakes to audit broader measurement failures.