Digital Gauge Firmware: From Raw Sensor Data to Displayed Value

Document Overview

TL;DR Every reading on an ETENWOLF digital pressure gauge passes through a 6-stage MCU pipeline — from raw ADC counts to a temperature-compensated, unit-converted value on the display — in under 50 milliseconds. That pipeline is why two gauges with identical sensors can show readings…

Document type

Test Report

Prepared by

Kevin Marshall

Published

June 4, 2026

Last reviewed

June 4, 2026

Topics

Digital Gauges

TL;DR

Every reading on an ETENWOLF digital pressure gauge passes through a 6-stage MCU pipeline — from raw ADC counts to a temperature-compensated, unit-converted value on the display — in under 50 milliseconds. That pipeline is why two gauges with identical sensors can show readings 0.5 PSI apart: firmware matters as much as hardware.

The MCU Processing Pipeline: Six Stages From Sensor to Screen

Understanding what happens between the moment you press the Schrader valve and the number appearing on the LCD demystifies why digital gauges behave differently from each other — and why ours behave consistently.

Stage 1 — Sensor Excitation and Raw Output

We use piezoresistive MEMS pressure sensors in our digital gauge line. When pressure is applied, the silicon diaphragm deflects, changing the resistance of four piezoresistors arranged in a Wheatstone bridge configuration. The bridge produces a differential voltage output — typically in the range of 0 to 80 mV at full scale for a 150 PSI sensor. That signal is small, noisy, and nonlinear. It is also temperature-dependent, which we address in Stage 4.

The sensor is excited with a stable 3.3V regulated supply. Voltage regulation here is not optional — a 1% fluctuation in excitation voltage produces a direct 1% error in the raw output. Our regulators are specified to ±0.5% across the 0°C to 50°C operating range.

Stage 2 — Analog-to-Digital Conversion

The differential millivolt signal from the bridge is amplified by a low-noise instrumentation amplifier before being fed into the MCU’s onboard ADC. We use a 16-bit ADC running at a 200 Hz sampling rate on our current gauge platform. At 16-bit resolution, that gives us 65,536 discrete counts across the full pressure span — roughly 0.002 PSI per count on a 0–150 PSI range. In practice, effective resolution after noise is closer to 14 bits, but that is still more than sufficient for ANSI B40.7 Grade 2A accuracy requirements of ±1% full scale.

The 200 Hz sampling rate is a deliberate choice. Faster sampling captures more noise. Slower sampling makes the display feel sluggish — particularly when checking sports ball pressure where the user expects an immediate reading. 200 Hz gives us 200 raw samples per second to work with, which feeds comfortably into the digital filtering stage.

Stage 3 — Digital Filtering and Noise Rejection

Raw ADC samples contain several noise sources: electromagnetic interference from the MCU clock, thermal noise in the amplifier, and mechanical vibration when the gauge is in use on a running inflator. None of these should appear on the display.

We implement a two-stage filter. The first stage is a hardware-level RC filter on the analog input with a 3 dB cutoff at 80 Hz, which eliminates high-frequency switching noise. The second stage is a firmware-level IIR (Infinite Impulse Response) low-pass filter applied in software. The filter coefficient is tuned to a time constant of approximately 40 ms, which means:

• Step-change response (e.g., connecting to a fully inflated tire): display settles to within ±0.1 PSI of final value in under 100 ms
• Noise rejection: RMS noise on the display is reduced to below ±0.05 PSI under static conditions

We also run a simple outlier rejection pass: any single sample that deviates from the running average by more than 2 PSI is discarded before entering the IIR filter. This prevents a spike from a valve connection bounce from corrupting the displayed value.

Stage 4 — Temperature Compensation

This is the stage most firmware engineers underinvest in, and it is the primary reason budget gauges drift in winter or in a hot car.

MEMS piezoresistive sensors have two temperature-dependent error sources: offset drift (the reading shifts even at zero pressure) and sensitivity drift (the span changes with temperature). Both are real and significant. A typical uncompensated MEMS sensor drifts approximately 0.15% full scale per °C on offset alone. Across a -10°C to 50°C operating range — 60°C span — that is up to 9% full scale error if unaddressed. On a 100 PSI reading, that is 9 PSI of error. Unacceptable.

Our compensation approach uses a two-point characterization method. During factory calibration, each sensor module is measured at two temperatures — 0°C and 40°C — at three pressure points (0 PSI, 75 PSI, 150 PSI). The resulting six data points define a bilinear compensation surface. Coefficients are calculated per unit and stored in non-volatile flash memory on the MCU. At runtime, the MCU reads the on-die temperature sensor at each measurement cycle and applies the stored coefficients before outputting a compensated pressure value.

In our thermal cycling tests — running units through 100 cycles between -10°C and 50°C — compensated units maintained accuracy within ±0.8% full scale across the entire range. Uncompensated units of the same sensor type drifted to ±4.2% by the end of the same test. See NIST traceability guidelines for why calibration reference chain matters here: our factory reference gauges are calibrated against NIST-traceable deadweight testers annually.

Stage 5 — Unit Conversion and Scaling

After temperature compensation, the MCU holds a value in raw engineering units — typically kPa, since the sensor calibration is done in SI units. The firmware then converts to the user-selected display unit: PSI, Bar, kPa, or kg/cm². These are simple linear multiplications stored as fixed-point constants to avoid floating-point overhead on a low-power MCU.

The conversion constants we use:

• 1 kPa = 0.14504 PSI
• 1 kPa = 0.01000 Bar
• 1 kPa = 0.01020 kg/cm²

Rounding rules matter here. We round to the nearest 0.1 PSI at display resolution. Truncation — rounding down always — creates a systematic low-reading bias of up to 0.05 PSI. We see this in some competitor units. Our firmware rounds to nearest, which eliminates systematic bias and keeps mean error near zero across a population of readings.

Stage 6 — Display Refresh and Hold Logic

The processed value is written to the LCD controller at a 5 Hz refresh rate for the live reading. A slower refresh reduces flicker and makes the display easier to read while inflating. When the user activates Peak Hold mode, the firmware latches the maximum observed value in a dedicated register and freezes the display update loop for that value — the live measurement continues in the background at full 200 Hz sampling, so the peak capture is not degraded by the slow display refresh.

The LCD itself is driven at a voltage adjusted by the MCU based on temperature: below -5°C, LCD contrast degrades noticeably on standard displays. Our firmware adjusts the LCD bias voltage by approximately 15% in cold-weather mode (triggered below 0°C on the temperature sensor) to maintain readable contrast down to -10°C operational minimum.

Sampling Rate, Averaging, and Why Both Numbers Matter

A question we get from technical buyers: “What is your sampling rate and what is your averaging window?” These are two different things and they interact.

The interaction between sampling rate and averaging window determines two things: response speed and noise floor. A 200 Hz sampler with a 40 ms time constant is effectively averaging about 8 samples per displayed value. That is enough to suppress high-frequency noise while remaining fast enough to track a pressure rise during inflation.

We chose 200 Hz specifically because it allows the auto-stop pressure control logic in our inflator integration (when the gauge module is embedded in an inflator rather than used as a standalone unit) to respond to pressure overshoot within 5 ms — fast enough to prevent more than 0.3 PSI of overshoot at typical inflation rates. At 10 Hz sampling, that same overshoot would be 6–8 PSI, which is why low-sampling-rate implementations need much larger software deadbands.

The SAE International standard SAE J2095 covers performance requirements for tire pressure monitoring systems more broadly, but the sampling and response principles translate directly to gauge firmware design. For reference on pressure measurement standards applicable to workshop and portable tools, ANSI Standards ANSI B40.7 remains the primary U.S. benchmark for gauge accuracy grading.

Firmware Calibration: Factory Process and Field Stability

Calibration is not a one-time event applied to a batch — it is applied to every individual unit. Batch calibration assumes that all sensors within a production lot are identical. They are not. Sensor-to-sensor offset variation within a single production reel can span ±2% full scale before compensation. That is why per-unit calibration is the only path to consistent Grade 2A accuracy.

Our calibration station applies known pressures from a NIST-traceable deadweight tester at three points per unit. The MCU captures ADC counts at each point, computes the gain and offset coefficients, and writes them to flash. Total calibration time per unit: approximately 45 seconds at the station. The cost in production time is real, but it is the reason our gauges read consistently rather than “usually close.”

Field stability is a separate concern. Flash memory retains calibration data without power for 100,000+ write/erase cycles and 20+ years data retention — calibration does not drift due to memory wear. What can change over time is the sensor’s mechanical zero point, typically due to repeated pressure cycling fatigue in the diaphragm. In our accelerated life testing — 50,000 pressure cycles from 0 to 100 PSI at 1 Hz — we observed less than 0.3% full scale zero drift. For a gauge used 10 times per day, that represents roughly 14 years of use before zero drift becomes measurable.

For distributors and OEM partners integrating our gauge modules into third-party products, the calibration coefficients are locked in firmware and cannot be overwritten through the standard user interface. Recalibration requires factory-level hardware access. This is intentional — it prevents field tampering that would degrade accuracy and create warranty liability. See our detailed product guide for the Etenwolf T600 Digital Tire Pressure Gauge for how these firmware principles translate to user-facing behavior on that specific platform.

The IEC Standards IEC 61298 series covers general performance evaluation methods for process measurement equipment, including offset and span stability tests that informed our long-term drift test protocol.

Maintenance & Best Practices

The firmware in your ETENWOLF digital gauge requires no maintenance — there are no user-accessible calibration adjustments to drift or reset. What you do control is the hardware condition that firmware operates on top of.

Keep the Schrader valve chuck clean. Debris on the chuck seal causes pressure leakage during measurement, which the firmware correctly reads as a lower-than-actual pressure. It is not a firmware error; it is a seal problem. Wipe the chuck with a dry cloth before use.

Battery voltage affects ADC reference accuracy. Our gauges include a low-battery warning at 20% remaining capacity. Do not ignore it — at very low battery states (below 2.8V for a CR2032-based unit), the regulated 3.3V supply for sensor excitation can sag, introducing up to 1% reading error. Replace batteries promptly when the indicator appears.

Store the gauge between -20°C and 60°C. Extended storage below -20°C can stress the MEMS diaphragm and alter the mechanical zero point permanently. This is outside the compensation range and would require factory recalibration.

For professional shops using gauges daily, we recommend a quarterly check against a known reference — a freshly calibrated master gauge or shop reference — and logging the result. If zero-pressure offset exceeds ±0.5 PSI, return the unit for recalibration rather than continuing to use it on critical applications like TPMS threshold verification.

Avoid dropping the gauge onto hard surfaces. The sensor diaphragm can sustain mechanical shock damage that changes its zero-point output. Our drop-test protocol is 1 meter onto concrete — units that pass remain within spec. Multiple drops accumulate risk.

Frequently Asked Questions

Q1: What sampling rate does the MCU use to read the pressure sensor?

A: Our current platform samples the ADC at 200 Hz, giving 200 raw pressure readings per second before filtering. The display updates at 5 Hz — the difference is all consumed by the digital filter and averaging stages.

Q2: Why does my gauge read slightly differently from my car’s built-in TPMS?

A: TPMS sensors embedded in wheels measure static pressure at ambient temperature and transmit to the car’s ECU — they are not calibrated to the same Grade 2A standard as a hand gauge. Additionally, TPMS typically reads within ±1.5–2.0 PSI of actual, while our gauges target ±1.0% full scale. A 1–2 PSI difference between a hand gauge and TPMS display is normal and does not indicate a fault in either device. Always trust a properly calibrated hand gauge for inflation decisions.

Q3: Can firmware updates change the accuracy of the gauge?

A: Accuracy is determined by the combination of sensor hardware, the factory-programmed per-unit calibration coefficients, and the firmware compensation algorithm. A firmware update that changes the compensation algorithm could theoretically alter effective accuracy, which is why we lock calibration data separately from the main firmware. Our production units do not expose a field firmware update interface — this protects calibration integrity over the product’s service life.

Q4: Does the gauge meet any recognized accuracy standard?

A: Yes. Our digital gauges are designed to meet ANSI Standards ANSI B40.7 Grade 2A, which specifies ±1% of full scale accuracy. Every unit is verified against a NIST-traceable reference before shipping.

Q5: Does temperature affect gauge accuracy even with compensation?

A: Compensation reduces temperature error dramatically — from a potential ±4–9% uncompensated to under ±0.8% full scale across -10°C to 50°C in our tested units — but it does not eliminate it entirely. The residual error comes from second-order nonlinearities in the sensor that our two-point compensation model does not fully capture. For most tire pressure applications, the residual error is well within acceptable bounds. If you are using the gauge in extreme conditions, allow 60 seconds after exposure to temperature extremes before taking a measurement, so the sensor and MCU can reach thermal equilibrium.

---

Published by ETENWOLF Technical Team | Request a quote