EMBEDDED SYSTEMS / FIELD NOTE
Designing the boundary between sensors and software
Units, timestamps, stale readings, and failure states: the small interface decisions that make connected devices easier to trust.
2 min read
A sensor reading looks simple when it appears as a number in a dashboard. Behind that number are assumptions about units, timing, calibration, and the connection between a physical device and its software.
A clear interface makes those assumptions inspectable. It also makes it easier to replace a sensor or change a dashboard without redesigning the entire system.
Give every value context
A useful measurement should identify what was measured, the unit, the device, and when the reading was taken. If a message contains only a value, the receiver must guess the rest.
Keep measurement time distinct from the time a server received the message. A device can reconnect and deliver older readings; arrival time alone does not tell the whole story. Document whether the device clock is synchronized and how uncertain timestamps are handled.
Separate zero from missing
A zero reading, a failed read, and an unavailable device are different states. Do not use the same numeric value for all three. Provide an explicit quality or status field, and let the display show when a value is unavailable.
Likewise, a dashboard should not show an old reading as if it were current. Choose a freshness window appropriate to the use case and show a stale state when it expires.
Decide what crosses the boundary
Before writing the communication code, agree on a short contract:
- What fields are required in every message?
- Which units and ranges does the receiver expect?
- How are device identity and message order represented?
- What should happen to malformed or duplicate messages?
- What information is needed to debug a failed measurement?
Validation belongs at the receiving boundary as well as on the device. A message arriving successfully does not guarantee that its contents make sense.
Test disconnection deliberately
Unplug a device during a controlled prototype test. Restart the receiver. Send a delayed message. These small exercises reveal whether the interface distinguishes “nothing changed” from “we no longer know.”
Good sensor software helps a person understand both the measurement and its limits. That clarity is often more valuable than adding another graph.