I worked on a torque sensor a while back, the kind built around a strain gauge bonded to a metal shaft. Two units off the same line, same firmware image, same bill of materials, and they’d report noticeably different numbers under the identical load. Not a firmware bug. Not a bad batch. Just what happens when you bond a strain gauge to metal by hand, or even with a well-controlled process: the adhesive layer, the exact placement, the surface prep, all of it shifts slightly unit to unit, and that shift shows up directly in the sensor’s offset and gain.
That’s the part people don’t expect. The firmware is identical because the code is identical. But the code reads a voltage, and the relationship between that voltage and the actual physical torque is a property of the bonded assembly in front of it, not of the code. Every one of those sensors needed its own offset and gain numbers, measured against a known reference load and written into the unit at production, before the firmware’s math meant anything.
That’s the real problem with per-unit calibration: it isn’t a firmware feature, it’s a manufacturing step. The offset and gain aren’t constants you can hardcode once and ship. They’re per-serial-number data that has to be captured at a calibration station, tied to that specific unit, and applied at runtime. Skip that step and the firmware is doing precise arithmetic on an imprecise input, which just gives you a very confident wrong answer.
Here’s the part that surprises people even after they’ve accepted that calibration is necessary: you can’t fix everything on the production floor. A two-point offset-and-gain calibration at final test corrects a linear error, and that’s genuinely useful, but it assumes the sensor’s behavior is linear and stable across the range you care about. If the real behavior is nonlinear, or if it drifts with temperature in a way that varies unit to unit, a quick production-line calibration won’t catch it. That has to come from characterization work done in the lab beforehand: pull a sample of units across their real operating range and real temperature range, understand how much they actually vary, and use that to decide what your production calibration needs to measure and what tolerance is acceptable to ship. Skip that lab step and you’re guessing at what “good enough” means when you write the acceptance criteria for the calibration station, and you’ll find out you guessed wrong when a customer sees inconsistent readings in the field, past whatever narrow window you tested in.
That characterization work is also where the numbers most people never think about come in. Everyone’s heard of “3 sigma” and “6 sigma” as vague synonyms for “pretty good” and “really good,” but the actual gap between them is enormous. A process centered on a 3-sigma tolerance leaves about 0.27% of units outside spec, roughly 2,700 per million. Push that same process to 6 sigma and you’re down to about 3.4 defects per million, a thousand-fold improvement for what sounds like a small change in a spec sheet. Whether that gap matters to you depends entirely on what a defective unit costs: for a consumer gadget, 2,700 ppm might be a rounding error in your return rate; for something in a safety loop, it’s a different conversation. And the sigma math only holds if the underlying distribution actually behaves like the normal distribution it assumes. A lot of real sensor variation does look roughly normal, but failure counts, defect occurrences, and some noise sources behave more like a Poisson process, with fatter tails than a normal curve would predict. Assume normal when the real distribution has fatter tails and you’ll under-provision your calibration range and your acceptance limits, then get surprised by outliers your statistics said shouldn’t exist.
My honest opinion on the fix, and it’s not the textbook answer: I like moving to digital as early in the signal chain as possible, right at the sensor if I can, because every additional analog stage between the sensor and the ADC is one more source of unit-to-unit variation that calibration has to absorb. Fewer analog stages generally means a tighter, more predictable calibration problem. But I won’t pretend that’s free. Going digital early usually means more cost per channel, sometimes more board area, and it doesn’t eliminate the need for calibration, it just narrows what you’re calibrating for, because the sensing element itself, the strain gauge bond in this case, is still an analog physical thing with its own variability no ADC placement fixes. I’ve seen teams treat “digital early” as a silver bullet and skip the lab characterization anyway, and that’s the wrong lesson to take from it.
If you’re building something with per-unit variation baked into the sensing element, the practical path is: characterize a real sample in the lab before you lock the production process, decide what tolerance is actually acceptable for your application rather than defaulting to whatever sigma number sounds impressive, and design the calibration station and firmware storage for those specific coefficients before you’re staring at a line that can’t ship product because nobody planned where the calibration data lives.
What consistently surprises clients, and this is the thing I keep coming back to with every project like this, is how early the real decision gets made. It’s not the calibration station design, and it’s not the firmware’s compensation math. It’s the sensing architecture you commit to in the first few weeks: which sensing element, which analog front end, how much of the signal chain is analog before it hits a converter. That choice sets how much per-unit variation you’re going to be fighting for the life of the product, and it determines your calibration station cost, your test time per unit, and how much of your production line’s throughput gets eaten by this one step. Get it wrong early and no amount of clever firmware or a well-run calibration station fully buys you out of it later.