A connected sensor:
from power to trustworthy data

One monitor, three places where meaning can be lost.

A storage-room temperature node measures once per second, gives a local high-temperature warning, and sends a summary every minute to a nearby Bluetooth Low Energy (BLE) gateway. The gateway forwards records to a dashboard. The node keeps recording when the gateway disappears.

The physical design determines whether the sensor measures the room or heat from its own board. Firmware determines whether a reading is new, valid and timely. The gateway determines whether an old record appears to the user as a current measurement. Each discipline therefore contributes to the trustworthiness of the displayed temperature.

The assumed node contains a battery and regulated supply, voltage supervision, a digital temperature sensor, an MCU with BLE, serial non-volatile memory and a status LED. The sensor is mounted to respond to room air, away from the regulator and radio heat sources. A service connection supports controlled configuration and updates.

Make the initial requirements testable

These are a selected system baseline, not a complete product specification. Their identities let the design discussion and verification matrix refer to the same claims. Additional environmental, radio, usability and market requirements would follow from the actual product context.

An energy budget is also a behaviour model.

Use battery-input current so converter losses are already included in the assumed figures. The active currents below are incremental above the 12 µA baseline. Summing them is valid for this illustrative accounting model; real measurements must avoid counting the same load twice. These duty times describe normal use, not worst-case execution bounds.

For a nominal 2,000 mAh battery with 60% assumed usable capacity, the simple estimate is 1,200 mAh ÷ 0.077 mA ≈ 15,584 h ≈ 649 days. This is a feasibility estimate, not a demonstrated service interval. Establish temperature derating, self-discharge, ageing, reconnect activity, alarm duty and the actual battery pulse capability.

If every radio transaction takes three attempts, its contribution rises from 40 to 120 µA. Total current becomes 157 µA and the same estimate falls to about 318 days. An unbounded retry loop can therefore invalidate CS-008 even while every feature appears to work. Set a per-minute radio budget and defer further retries, preserving acquisition and local warning operation.

Peak current and thermal error need separate evidence

During a transmit burst, probe the regulated rail and reset signal at the node. A weak battery can have enough average capacity yet cause a brownout under peak load. At the selected sensor supply, require supervisor thresholds and tolerances that hold the MCU in reset before operation becomes unreliable; numerical thresholds require an actual component selection.

The enclosure also couples radio and regulator heating to the sensor. A provisional steady-state error allocation of 0.20 °C sensor error + 0.05 °C conversion / calibration residual + 0.15 °C installation and self-heating leaves 0.10 °C against the ±0.5 °C limit. Each contribution needs evidence over the stated conditions. Digital resolution alone cannot establish this budget.

TI’s TMP117 data sheet provides a concrete example of conversion-mode, self-heating and layout considerations. It is a reference for the reasoning, not the selected sensor or the source of this case’s assumed 20 ms conversion limit.

“Connected by I²C” is only the beginning.

Select the actual sensor and MCU from a reviewed electrical and timing contract. For this example, the sensor interface is a short, on-board 100 kbit/s I²C bus. Confirm pull-up sizing, line capacitance, logic levels and unpowered behaviour. A transaction acknowledgement shows a transfer response; it does not prove a new, physically correct temperature.

NXP’s I²C specification, section 3.1.16, distinguishes stuck-SCL and stuck-SDA recovery. Firmware cannot release a physical short by repeatedly retrying a read. If sensor power cycling is part of recovery, hardware must provide it without back-powering through the bus pins.

Keep live data separate from historical delivery

The gateway calculates a conservative live age from the node’s reported age at transmission, elapsed time since reception, a bounded transport allowance and clock uncertainty. The assumed maximum connected-link transit is 500 ms; reject or classify as historical any live message whose timing bound cannot be established. Use monotonic clocks for durations and retain uncertainty in any mapping to UTC.

After a six-hour outage, replayed history must never refresh the live display. Deduplicate durable records using device ID, a non-reused boot ID and record sequence. A new boot ID is allocated through a power-loss-safe mechanism before producing records; otherwise recording remains unavailable. Reset changes session identity, and an old configuration command cannot silently regain authority.

See TEA-104 — Communications Interfaces and Protocols and TEA-204 — Application and Connectivity Engineers for the interface and reconciliation principles.

The electronic deadline starts after a physical assumption.

A slow enclosure cannot be repaired by a faster interrupt. CS-003 deliberately separates the electronic warning rule from the specified ambient-temperature step. For that step only, allocate up to 12 s for thermal transfer until the sensing element reaches the qualifying condition. Confirm the enclosure, placement and airflow; this is not a universal bound for every possible temperature change.

The jitter allowance assumes releases tied to an absolute monotonic schedule, not a fresh one-second delay after every task completes. Conversion waiting is non-blocking; flash erases and radio reconnection cannot occupy the acquisition path. If their real interference exceeds 20 ms, the allocation is invalid and the architecture must change.

The local high warning asserts on three consecutive valid values ≥8.0 °C and clears on three consecutive valid values ≤7.5 °C. Invalid samples break both consecutive-value counts; they cannot clear an existing warning. Measurement health, temperature warning and link status are separate state variables so a lost gateway does not masquerade as a normal temperature.

Test the physical step using an independent reference near the sensor location, and test electronic timing with a controlled sensor-interface stimulus. Both are necessary: the latter isolates firmware timing but cannot demonstrate enclosure response. Continue with TEA-105 — Real-time Behaviour.

A believable failure response preserves uncertainty.

A hardware watchdog is useful only if its servicing demonstrates required progress. The supervisor checks that acquisition attempts, deadline checks and validity publication advance; a diagnosed sensor failure need not cause endless resets. An interrupt that blindly feeds the watchdog can hide a blocked main task.

The LED uses distinguishable Initialising, Healthy, High Warning and Sensor Fault patterns. Fault indication has display priority; retain the temperature-warning status separately in records. A single LED is a limited local interface, so any application requiring assured human response needs a separate usability and risk argument.

With 64-byte committed minute records, 24 h requires 1,440 × 64 = 92,160 bytes. A 128 KiB history allocation has room for 2,048 records, about 34 h before implementation overhead. In an illustrative 256 KiB memory, reserve another 64 KiB for configuration / metadata and 64 KiB for spare / recovery use. Verify the usable ring capacity after sector layout and metadata, not just the nominal chip capacity.

Use pre-erased slots, bounded writes, an integrity check and a durable commit convention appropriate to the selected memory. A CRC detects certain corruption; it does not make writing atomic. Losing power may discard the current uncommitted minute, so mark the interruption rather than promising zero data loss. Assess erase endurance and metadata wear.

Bring up the boundary in observable steps.

Retain the exact board, sensor configuration, firmware, bootloader, calibration, gateway and fixture versions. Keep debug-firmware findings separate from release evidence: breakpoints, logging and a powered debug probe can change timing, sleep and supply behaviour. See TEA-108 — Hardware–Software Integration.

The dashboard is current. The measurement is not.

The table below is a fictional trace deliberately constructed to expose a defect. It is not an observation from tested hardware. An acquisition task becomes trapped in a bus driver after a radio-induced supply disturbance, while the communications task continues transmitting.

Your task

1. Identify the violated requirements and the responsibility on each side of the hardware / firmware boundary.
2. Explain why packet arrival and a running watchdog do not establish measurement health.
3. Propose an electrical fix, a firmware fix and a gateway fix, each with a targeted verification observation.
4. Decide whether the evidence is sufficient to identify the electrical root cause.

Continue across the boundary at The Firmware Academy.

This case establishes system responsibilities and acceptance evidence. The following Firmware Academy lessons explain how to implement the corresponding firmware mechanisms. The temperature-controller project is a related example with an actuator; its numerical requirements and fault policy are different from this sensor monitor.

Browse the Firmware Academy home page for the full learning library.

Release a known system, with known limits.

A credible release record identifies the board and enclosure, sensor / memory variants, firmware and bootloader, configuration / calibration, gateway compatibility and tested artefacts. It links requirements to evidence and records anomaly disposition, remaining diagnostic limitations and the conditions supporting the battery and thermal claims.

Keep signing keys, device identity and service credentials as separate authorities. Protect configuration changes because they can alter the meaning of reported data. NIST’s Platform Firmware Resiliency Guidelines offer a useful protect, detect and recover perspective for the update design; applicability and implementation still depend on the actual platform.

The next engineering step for this fictional product would be to select components and test the highest-risk assumptions: enclosure thermal response, battery-load behaviour and bounded acquisition during storage / radio activity. A firmware demo alone cannot settle any of those system claims.

References and related learning

• NXP UM10204 — I²C-bus specification and user manualElectrical / protocol behaviour and bus-clear distinctions. Consult the selected component data sheets as well.
• TI TMP117 data sheetAn example of sensor conversion, power, self-heating and thermal-layout considerations; not the component selection for this case.
• NIST SP 800-193 — Platform Firmware Resiliency GuidelinesProtection, detection and recovery concepts for firmware.
• TEA-103 — Sensors, Actuators and Signal AcquisitionMeasurement quality and physical response.
• TEA-106 — Fault Handling and Safe StatesDetection, containment and recovery.
• TEA-111 — Reliability and Lifecycle ManagementMission profiles, field evidence and controlled change.

The components work. Challenge the interfaces.

Put this case study into practice with TEA-402 — Interface and Integration Exercise. Investigate a torn transmission, a lost acknowledgement, stale readings and unexpected restarts. Define the missing requirements, recovery behaviour and integration tests.

Then compare your answer with TEA-403 — Worked Solution, including an example message contract, a recovery state diagram and twelve tests with expected results.