Embedded systems · Implementation study
Sensor telemetry from firmware to dashboard
An acquisition pipeline for equipment readings that preserves timing, units, and data quality from the device to the operator.
What the demo shows
Temperature, vibration, pressure, graphs, and firmware events are sample values generated by the browser. They do not come from connected sensors or demonstrate predictive maintenance.
Proposed system flow
- 01Sensor driver
- 02Timestamped sample
- 03Local buffer
- 04Telemetry display
01
Acquire measurements deliberately
Start with the sensor datasheet: bus protocol, conversion time, supported sample rates, calibration, and physical units. A firmware acquisition task would read the device on a defined schedule and attach a timestamp and quality flag. With Zephyr's fetch-and-get API, acquisition blocks its calling thread, and concurrent access needs synchronization. Driver behavior determines whether polling, interrupts, or an asynchronous API is appropriate.
02
Separate collection from delivery
A bounded queue between acquisition and networking lets the device continue sampling during brief uplink delays. For this design, every record would carry a device identifier, sequence number, units, and schema version. Queue overflow and stale readings should be visible. An MQTT transport is one option; QoS 1 permits duplicate delivery, so the receiver would deduplicate records using stable identifiers.
03
Choose analysis to match the signal
A temperature trend and a vibration spectrum need different sampling and filtering choices. The slow example graph does not substantiate a machine fault diagnosis. A production monitoring view would distinguish missing data from zero, show last contact time, and explain alarm thresholds. Predictive maintenance would additionally require relevant failure data and evidence that its predictions remain useful in the intended installation.
Validation plan
- Compare readings with a reference instrument and document calibration error.
- Exercise sensor disconnects, queue exhaustion, reboot, and delayed delivery.
- Verify timestamps, unit conversions, and alarm behavior against recorded fixtures.
More in embedded systems
Have a similar problem to solve?
Discuss your project