Insights / IoT & Hardware
From sensor samples to trustworthy product events
A sensor reading needs timing, calibration, quality signals, and context before it becomes a product event. Treat the entire signal path as part of the interface.
Kiran Bandarupalli · 2 Oct 2026 · 2 min read
A device can transmit numbers perfectly and still produce a misleading product. Sampling rate, analog noise, calibration, clock drift, and sensor placement all affect what a downstream application can conclude. The software contract should carry those limitations forward.
Write down the measurement
Record the unit, range, expected sampling interval, calibration method, and conditions under which the reading is meaningful. If a reading can be clipped, saturated, or disconnected, represent that state explicitly. A value of zero should not ambiguously mean both “measured zero” and “sensor unavailable.”
Keep timing and quality with the value
Use a monotonic clock for intervals on the device and include a sequence number or timestamp when events may be buffered. Keep track of clock synchronization separately; a device's wall clock may be wrong after a battery change. Attach a quality indicator so the application can avoid presenting questionable samples as precise facts.
Shape data to the link
Radio bandwidth and energy are limited. Choose whether the product needs raw samples, derived features, or both. Aggregation reduces payload but makes some later analysis impossible, so make that trade-off with the product and privacy requirements in view. Version packet formats and define how older firmware is handled by the service.
Design for missing data
Connections drop. Buffering needs a maximum size and an expiry policy; otherwise a long outage can create a burst that overloads the service on reconnect. Make duplicate uploads safe, expose a gap in the timeline, and distinguish delayed data from current state.
- Test with noisy, missing, clipped, and out-of-range inputs.
- Measure current draw under the intended sampling and transmit schedule.
- Keep calibration and firmware versions with the session metadata.
- Avoid retaining more raw personal data than the feature needs.
Good telemetry does not hide uncertainty. It tells the user and the system what was measured, how reliable it is, and when it is not safe to make a decision from it.