Building a connected sensor product: PCB, firmware, and telemetry

The scenario

Imagine a small connected device that records environmental readings and sends them to a product dashboard. The first milestone would be a working prototype with a traceable relationship between the board revision, firmware build, and measurements. A cloud dashboard alone would not establish whether the underlying sensor data can be trusted.

Define the hardware and software boundary together

The design would start with the measurement range, power source, enclosure constraints, and expected connectivity. A short interface document would identify sensor buses, reset behaviour, debugging access, and how the application detects an unavailable peripheral. These decisions would influence both the schematic and the firmware structure.

KiCad would hold the schematic and PCB layout. The prototype review would check electrical rules, footprints, connector orientation, and access to test points before fabrication. Manufacturing outputs would be tied to a specific design revision, including the bill of materials and assembly information.

Bring up one subsystem at a time

The first board would be powered with suitable current limiting and a staged bring-up checklist. Supply rails, reset, the debug connection, and each peripheral would be checked separately. An incorrect sensor value should be distinguishable from a communication timeout or a missing calibration step.

Zephyr could provide the firmware foundation, with board-specific configuration kept separate from the measurement logic. Each diagnostic record would include the hardware and firmware revisions. A development image would expose useful diagnostics while a release image would have a deliberate logging and access policy.

Make telemetry interpretable after it leaves the device

An MQTT message would carry a device reference, schema version, sequence number, reading, unit, and timing information. If the device clock is not synchronized, the ingestion service would preserve that limitation rather than treating every timestamp as authoritative. The backend would handle repeated messages without adding duplicate measurements.

A bounded local queue would cover temporary disconnection. The product would define what to retain or discard when storage fills, and report gaps explicitly. Device credentials would be scoped to the intended topics so that one device cannot publish as another.

What to validate

• The build record identifies the exact PCB and firmware revisions.
• Disconnected or faulty sensors do not produce normal-looking measurements.
• Repeated MQTT delivery does not duplicate stored readings.
• Queue exhaustion and reconnect behaviour are observable.

The tradeoff

A prototype proves selected assumptions, not manufacturing readiness. Component variation, enclosure effects, power consumption, radio performance, and production testing would need their own validation before a larger build.