Embedded firmware
Sensor Firmware & Signal Conditioning
Kyros Engineering develops sensor firmware and the signal-conditioning chain it depends on — analog front end, ADC selection, filtering, calibration and drift compensation — and delivers the measurement with its error budget written down. Most sensor problems that reach us are not firmware bugs: they are a number that was never traceable from the physical quantity to the reported value, so nobody can say which stage is lying.
Scope this with usA sensor reading is a chain: the transducer, the front end, the converter, the filter, the calibration, and the code that scales it. A defect anywhere in that chain arrives at the application as a plausible-looking number, which is exactly what makes it expensive. Teams end up tuning firmware to compensate for an analog problem, or replacing a sensor that was never at fault.
We work the chain end to end and make the error budget explicit, so the reported value has a defensible relationship to the thing being measured.
Where sensor chains go wrong
A short list of causes accounts for most of it, and they are checkable in order.
- Units and scaling that were never documented, so a factor of two hides in a conversion nobody re-derived
- ADC resolution quoted from the datasheet rather than the effective number of bits at the actual sample rate and source impedance
- Aliasing — a digital filter placed where an analog anti-alias filter was required
- Calibration performed at one temperature and one point, then trusted across the whole operating range
- Ground and reference noise coupling into the front end from a switching supply on the same board
- Raw readings never range-checked, so a failed sensor reports a number instead of a fault
How we build the chain
Front end and firmware are designed together, because the split between what the analog does and what the code does is an engineering decision with a cost on both sides.
- Front-end design — instrumentation amplifiers, gain staging, reference selection, guarding and shielding
- Converter selection against the real requirement: successive-approximation or delta-sigma, resolution, sample rate, latency
- Anti-alias filtering in analog, decimation and digital filtering in firmware, each doing the part it is good at
- Fixed-point signal processing unless floating-point hardware is confirmed present
- Calibration and compensation — multi-point, temperature-aware, with coefficients stored and versioned on the device
- Fault detection: range, rate-of-change and plausibility checks, so a bad sensor announces itself
The measurement is documented, not implied
Every signal we deliver carries its units, its scaling, its expected range and its error contributors in writing. In regulated work that documentation is evidence and has to exist anyway. In unregulated work it is what lets the next engineer — including yours, two years from now — trust the number without re-deriving the whole chain. Firmware is done when the device measures correctly on real hardware across the operating range, not when the code compiles and the value looks reasonable at room temperature.
When to call
You probably want this if…
Frequently asked
Do you do the analog hardware as well as the firmware?
Yes, and for sensor work that is usually the only way to get a defensible answer. Where the analog and the firmware are owned by different vendors, the boundary between them is exactly where unexplained error accumulates and where neither party can be held to a number.
Can you tell us whether a problem is the sensor, the board, or the code?
That is a common first engagement. We instrument the chain stage by stage on your hardware and show you where the error enters, with captures. It usually takes days rather than weeks, and it stops teams replacing a sensor that was reporting correctly.
What about calibration in production?
We design the calibration procedure alongside the firmware — what gets measured, at how many points, at what temperatures, how long it takes per unit, and how the coefficients are written and verified. A calibration scheme that is correct but takes four minutes a unit is a manufacturing problem, so cycle time is a design input rather than an afterthought.
Do you work with sensors in regulated devices?
Regularly. In an IEC 62304 or IEC 60601 context the measurement chain needs a traceable requirement, a verification method and evidence for each, and we build that alongside the engineering rather than reconstructing it before a submission.
Not sure whether it's the sensor or the code?
Send us the hardware and what you're seeing. We'll instrument the chain and tell you where the error enters.