DEV Community: Aliaksandr Liapin

Why I Shipped Coulomb Counting Before the Hardware Worked

Aliaksandr Liapin — Mon, 11 May 2026 14:54:05 +0000

An embedded battery SDK story about ambitious algorithms, stubborn breadboards, and the discipline of shipping anyway.

I spent a weekend implementing coulomb counting for my open-source battery monitoring SDK. The code is in production. The hardware doesn't actually work yet.

That sentence used to make me anxious. Now I think it might be one of the most useful things I've learned about embedded engineering.

The voltage-lookup-table problem

My SDK has been shipping state-of-charge estimation for months. The approach is simple: read the battery voltage, look it up in a curve like this:

4200 mV → 100%
3800 mV → ~50%
3000 mV → 0%   (LiPo cutoff)

This works fine for a CR2032 coin cell that discharges in a smooth, predictable curve. For LiPo it's a disaster.

Three reasons:

1. The plateau region. Between 3.7V and 3.8V, a LiPo can have anywhere from 30% to 70% charge. The voltage barely moves. A 10mV measurement error becomes a 10% SoC error. You can't accurate-curve your way out of physics.

2. Load-induced sag. Every time the device transmits over Bluetooth, the battery voltage drops 200-500 mV for a few milliseconds. The voltage-LUT sees this as "battery suddenly at 60%!" Then the transmit ends, voltage recovers, and the SoC jumps back to 80%. Users see a percentage that flickers like a stock ticker.

3. Cell aging is invisible. A 500-cycle-old battery reads the same voltage at the same SoC as a fresh one — but it actually holds 80% of the original capacity. Voltage-LUT can't see this.

The fix everyone agrees on: coulomb counting. Measure current going in and out, integrate over time, you know exactly how much charge has moved. It's how your phone, your laptop, your EV all really do it.

Designing the architecture

I want this SDK to be a real product, not a hack. So before writing any code, I sat down to think about layering.

What I landed on:

INA219 chip (current sensor)
    │
    ▼ I²C
┌─────────────────────────────────────┐
│  Current HAL (battery_hal_current)  │  ← swap backends (INA219, fuel gauge, shunt+ADC)
└─────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────┐
│  Coulomb counter                    │  ← trapezoidal integration, NVS persistence
│  (integer-only, int64 accumulator)  │
└─────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────┐
│  SoC estimator v2                   │  ← coulomb primary, voltage anchor at endpoints
└─────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────┐
│  Telemetry v3 (32 bytes)            │  ← BLE notifications to gateway
│  + current_ma + coulomb_mah         │
└─────────────────────────────────────┘

Key constraints I imposed on myself:

Integer-only math. I'm targeting nRF52840 (Cortex-M4 with FPU), STM32L4 (with FPU), and ESP32-C3 (no FPU). All math must work without floats so the same code paths run on every platform.
Zero heap allocation. Embedded SDKs that malloc are embedded SDKs that mysteriously crash at 3 AM in a field deployment.
Backward compatible. Existing users with voltage-only setups must continue to work with zero changes. Coulomb counting is opt-in via Kconfig.

The coulomb counter

Here's the heart of it. Trapezoidal integration with an int64 accumulator in 0.001 mAh units (sub-mAh precision):

int battery_coulomb_update(int32_t current_ma_x100, uint32_t dt_ms)
{
    if (!g_initialized) return BATTERY_STATUS_NOT_INITIALIZED;
    if (g_first_sample) {
        g_prev_current = current_ma_x100;
        g_first_sample = false;
        return BATTERY_STATUS_OK;
    }

    /* Trapezoidal: average of previous and current sample */
    int64_t avg = ((int64_t)g_prev_current + current_ma_x100) / 2;

    /* Convert to x1000 mAh units:
     *   delta = (avg_ma_x100 * dt_ms) / 360000
     * Keep remainder to avoid truncation drift over multi-day runs. */
    int64_t numerator = avg * (int64_t)dt_ms + g_remainder;
    int64_t delta_x1000 = numerator / 360000;
    g_remainder = numerator - delta_x1000 * 360000;

    g_accumulated_mah_x1000 += delta_x1000;
    g_prev_current = current_ma_x100;
    return BATTERY_STATUS_OK;
}

The remainder accumulator was a debugging gift. My first version had a 1% drift over 1800 samples — each step lost a fractional unit to integer truncation, and that loss compounded. The fix: carry the leftover into the next iteration. Now drift is mathematically zero.

It survives reboot via NVS (non-volatile storage), saving every 60 seconds or whenever charge changes by more than 1 mAh.

Voltage anchoring

Coulomb counting drifts. Voltage-LUT is accurate at the endpoints (full charge, cutoff) but lies in the middle.

So I use voltage as a periodic calibration anchor:

/* Anchor at full charge (LiPo): voltage near max AND current is tiny
 * (CV phase complete) */
if (voltage_mv >= 4180 && abs_current_ma < 50) {
    battery_coulomb_reset(capacity_mah);  /* declare 100% */
}

/* Anchor at cutoff: voltage below safe threshold */
if (voltage_mv <= 3000) {
    battery_coulomb_reset(0);  /* declare 0% */
}

The "low current at full voltage" check is the trick. During charging, a LiPo sits at 4.2V for hours while current tapers. The cell isn't actually full until current drops to a trickle (the "CV phase" of CC/CV charging). If you anchor purely on voltage, you'll claim 100% an hour too early.

The voltage smoothing layer

While I had the project open, I added two more accuracy improvements that don't need hardware:

Median filter (replaces moving average)

The existing moving-average filter dilutes BLE transmit sags but doesn't reject them. A 500 mV dip across 8 samples still pulls the average down 62 mV — enough to swing SoC by 10% on the LiPo plateau.

Median filter throws outliers out completely:

uint16_t median_of(const battery_voltage_filter_t *filter)
{
    uint16_t sorted[BATTERY_VOLTAGE_FILTER_MAX_WINDOW_SIZE];
    size_t n = filter->count;

    /* Insertion sort a copy — n ≤ 16, fast for tiny arrays */
    memcpy(sorted, filter->buffer, n * sizeof(uint16_t));
    for (size_t i = 1; i < n; i++) {
        uint16_t key = sorted[i];
        size_t j = i;
        while (j > 0 && sorted[j-1] > key) {
            sorted[j] = sorted[j-1];
            j--;
        }
        sorted[j] = key;
    }

    return (n % 2 == 1) ? sorted[n/2]
                        : (sorted[n/2-1] + sorted[n/2]) / 2;
}

The cost: O(n²) sort, but n is bounded at 16 — worst case 256 comparisons, executed at 0.5 Hz. The MCU spends more cycles blinking the status LED.

SoC slew limiter

Even with a perfect voltage filter, the LUT has steep regions where a 20 mV change maps to a 5% SoC jump. Reality doesn't work that way: an IoT load can't physically discharge a battery 5% in 2 seconds.

So I cap the rate of change:

static uint16_t apply_slew_limit(uint16_t new_soc)
{
    if (!g_first_call) {
        uint32_t dt_ms = current_uptime - g_prev_uptime;
        int32_t max_delta = (5 * 100 * dt_ms) / 60000;  /* 5%/min */
        int32_t delta = (int32_t)new_soc - (int32_t)g_prev_soc;
        if (delta > max_delta) new_soc = g_prev_soc + max_delta;
        if (delta < -max_delta) new_soc = g_prev_soc - max_delta;
    }
    g_prev_soc = new_soc;
    g_prev_uptime = current_uptime;
    g_first_call = false;
    return new_soc;
}

Defense in depth: the median filter catches voltage outliers, the slew limiter catches SoC outliers if anything slips through.

And then the hardware didn't work

I wired the INA219 to an ESP32-C3 DevKitM. Default I2C pins, default address (0x40). Powered on. Watched the serial log:

[INA219] not found at 0x40 (rc=-14) — check wiring

OK, classic. Probably a loose breadboard contact. I swapped wires, pressed harder, tried both INA219 boards (I bought a 2-pack). Same result.

I added an I²C scanner. The chip responded to the simple probe — its address showed up. But every register write got NACK'd. Reads through the proper i2c_write_read API also failed. Only the bare scan worked.

Switched platforms to nRF52840-DK. Same INA219 board. Same wiring topology, just different pins. Different I²C controller from Nordic instead of Espressif. Zero devices found on the bus. The chip was completely invisible.

After two hours of debugging — checking pull-up solder bridges on the DK, swapping wires, power-cycling, trying both INA219 boards — I had to admit: I don't know what's wrong. It could be:

Cold solder joints on the INA219 header pins
Breadboard contacts at end-of-life
A clock-stretching quirk in the Espressif I²C driver
Static damage to one of the chips
Something I haven't thought of

I needed a logic analyzer. Without one, I'm guessing in the dark. Ordered a $10 HiLetgo USB 24MHz 8-channel analyzer — arrives Monday.

The shipping discipline

Here's where I had a choice. The lazy option: don't release until hardware works. The disciplined option: release the software and document the gap.

I chose to ship.

Reasons:

The software is complete and verified. 14 host-based unit tests, all passing. 65 gateway tests, all passing. The math, the integration, the wire format, the gateway decoder — all proven. A logic analyzer is going to find a wiring problem, not a code problem.
It composes with the existing voltage-LUT path. Users without an INA219 see no behavior change. The HAL has a stub backend that returns "unsupported" — the SoC estimator detects this and falls back to voltage-only. Zero regression.
The Known Issues section is honest. The release notes document the exact failure mode. A potential adopter knows what they're getting.
Holding releases hostage to one flaky breadboard is bad strategy. I have working voltage smoothing (v0.9.0) that helps every single user immediately. Bundling it with stalled hardware validation would mean shipping nothing.

I tagged v0.8.0 for coulomb counting (software complete, hardware pending) and v0.9.0 for voltage smoothing (fully production-ready). Both are live on GitHub.

CI as accountability

Before stopping for the day, I added a GitHub Actions workflow that builds the firmware for ESP32-C3 in three configurations — default, median filter, current sensing — on every commit. It also runs the host tests on Ubuntu and macOS, and the Python gateway tests.

Now anyone landing a pull request gets concrete proof the code builds and the tests pass. The badge on the README isn't decoration; it's a contract.

What's next

Monday: logic analyzer arrives. I'll capture the I²C bus during boot, see exactly which byte gets NACK'd, fix the underlying issue. Ship v0.8.1 as a hardware-validation patch.

Then Phase 8c: Kalman filter fusion. Combine voltage and current optimally, weighted by their relative confidence (voltage is noisy under load, coulomb counting drifts over weeks). Same public API as today; just a smarter estimator inside.

This is the path real BMS firmware takes — phones, EVs, medical devices. The fact that an open-source SDK targeting CR2032s and breadboards can run the same algorithm is, honestly, the point. Battery intelligence shouldn't be a moat.

Takeaways

If you're building embedded products and you're not sure when to ship:

Ship the software, document the hardware gap. Honesty is more credible than perfection.
Design for graceful degradation. If the new sensor isn't there, fall back to the old path. No regression.
Get a logic analyzer. Ten dollars buys you the difference between guessing and knowing.
Test what you can on the host. I have ~80 unit tests that run on Linux, macOS, and Windows. They caught the integer truncation drift bug long before any breadboard was involved.
Layer your design so you can replace any part. My HAL means swapping INA219 for a fuel-gauge IC later is a 100-line change, not a rewrite.

The SDK is open-source and Apache 2.0. If you're working on a battery-powered IoT product and want to skip rewriting voltage curves and coulomb integrators from scratch:

Repo: https://github.com/aliaksandr-liapin/ibattery-sdk

If you've solved the I²C-on-breadboard-on-Espressif puzzle before, I'd love to hear from you. The logic analyzer arrives Monday but human wisdom is faster.

Next post will cover the Kalman filter fusion (Phase 8c), once Phase 8a is hardware-validated. Subscribe if you like battery math and honest engineering write-ups.

Designing a HAL Abstraction That Actually Ports — Lessons from 3 MCU Families

Aliaksandr Liapin — Tue, 14 Apr 2026 03:57:40 +0000

"Just add a HAL layer" is the most common advice in embedded development. It's also the most under-explained. After porting a battery monitoring SDK across nRF52840, STM32L476, and ESP32-C3, here's what I learned about HAL design that actually works in practice.

The Problem

I needed to read battery voltage on three MCU families. Sounds simple — until you realize each one does it completely differently:

Platform	VDD Strategy	How it works
nRF52840	Direct SAADC	Internal mux connects VDD to the ADC. Read it like any channel.
STM32L476	VREFINT sensor	ADC measures a ~1.21V internal bandgap reference. Back-calculate VDD using factory calibration data stored in ROM.
ESP32-C3	Voltage divider	Can't read VDD at all. Route battery through external resistors to a GPIO pin.

Three fundamentally different approaches. Same end result: battery voltage in millivolts.

Attempt 1: The Giant #ifdef

The obvious first approach:

int read_battery_mv(void) {
#if defined(CONFIG_SOC_SERIES_NRF52X)
    // 30 lines of nRF SAADC code
#elif defined(CONFIG_SOC_SERIES_STM32L4X)
    // 40 lines of VREFINT sensor code
#elif defined(CONFIG_SOC_SERIES_ESP32C3)
    // 25 lines of voltage divider code
#endif
}

This works for two platforms. By three, it's unreadable. By four, it's unmaintainable. Every new feature means touching every #ifdef block.

What Actually Works: Separate the What from the How

The key insight: split platform constants from platform logic.

Layer 1: Platform Constants (one header)

A single header file defines what each platform needs — no logic, just values:

// battery_adc_platform.h

#if defined(CONFIG_SOC_SERIES_NRF52X)
    #define BATTERY_ADC_DT_NODE    DT_NODELABEL(adc)
    #define BATTERY_ADC_VDD_INPUT  NRF_SAADC_VDD
    #define BATTERY_ADC_VDD_GAIN   ADC_GAIN_1_6
    #define BATTERY_ADC_VDD_REF_MV 600

#elif defined(CONFIG_SOC_SERIES_STM32L4X)
    #define BATTERY_ADC_VDD_USE_VREFINT 1
    // No ADC config needed — uses Zephyr sensor driver

#elif defined(CONFIG_SOC_SERIES_ESP32C3)
    #define BATTERY_ADC_VDD_USE_DIVIDER    1
    #define BATTERY_ADC_VDD_DIVIDER_RATIO  2
    #define BATTERY_ADC_DT_NODE    DT_NODELABEL(adc0)
    #define BATTERY_ADC_VDD_INPUT  2  // GPIO2
    #define BATTERY_ADC_VDD_GAIN   ADC_GAIN_1_4
    #define BATTERY_ADC_VDD_REF_MV 2500
#endif

Adding a fourth platform means adding 5-10 lines to this one file.

Layer 2: Strategy Selection (one C file)

The ADC driver selects its strategy based on the flags from Layer 1:

// battery_hal_adc_zephyr.c

#if defined(BATTERY_ADC_VDD_USE_VREFINT)
    // STM32: use Zephyr vref sensor driver
    // sensor_sample_fetch() → sensor_channel_get(VOLTAGE) → mV

#elif defined(BATTERY_ADC_VDD_USE_DIVIDER)
    // ESP32: raw ADC read → adc_raw_to_millivolts() → multiply by ratio

#else
    // nRF52: raw ADC read → adc_raw_to_millivolts() → done
#endif

Each block is self-contained. They don't interact. You can read one without understanding the others.

Layer 3: Everything Above (zero platform awareness)

The voltage module, SoC estimator, telemetry collector, and BLE transport don't include any platform headers. They call:

int battery_hal_adc_read_raw(int16_t *raw_out);
int battery_hal_adc_raw_to_pin_mv(int16_t raw, int32_t *mv_out);

That's it. They don't know if the voltage came from SAADC, VREFINT, or a resistor divider. They don't care.

The Temperature Sensor Problem

Temperature was trickier. Each platform names its die temp sensor differently in the devicetree:

Platform	Node label
nRF52840	`temp`
STM32L476	`die_temp`
ESP32-C3	`coretemp`

The solution: a devicetree-driven fallback chain with zero CONFIG_SOC_SERIES_* checks:

#if DT_NODE_EXISTS(DT_NODELABEL(temp))
#define BATTERY_TEMP_NODE DT_NODELABEL(temp)
#elif DT_NODE_EXISTS(DT_NODELABEL(die_temp))
#define BATTERY_TEMP_NODE DT_NODELABEL(die_temp)
#elif DT_NODE_EXISTS(DT_NODELABEL(coretemp))
#define BATTERY_TEMP_NODE DT_NODELABEL(coretemp)
#endif

The rest of the file — sensor_sample_fetch(), sensor_channel_get(SENSOR_CHAN_DIE_TEMP) — is identical across all platforms. Zephyr's sensor API handles the underlying driver differences.

This pattern is more resilient than #ifdef chains. If a future platform uses temp (same as nRF), it works automatically with zero changes.

What I Got Wrong (and Fixed)

Mistake 1: Hardcoded ADC parameters

My first NTC thermistor driver had this:

#define NTC_ADC_ACQ_TIME  ADC_ACQ_TIME(ADC_ACQ_TIME_MICROSECONDS, 40)

Worked on nRF52840 and STM32. Crashed on ESP32-C3 — the driver only accepts ADC_ACQ_TIME_DEFAULT. Same for .calibrate = true and .oversampling = 4 in the ADC sequence struct.

Fix: platform-conditional defaults in the NTC driver. Lesson: even "standard" Zephyr APIs have platform-specific capabilities.

Mistake 2: Assuming VDD is readable

I designed the API around battery_hal_adc_read_raw() + battery_hal_adc_raw_to_pin_mv() — a raw ADC read followed by a conversion. This maps cleanly to nRF52 and ESP32.

But STM32's VREFINT path doesn't use the ADC driver at all — it uses the Zephyr sensor API (sensor_sample_fetch). The "raw" value is meaningless; the real millivolts come from the sensor channel.

I solved this by storing the computed millivolts in a global during read_raw() and returning them from raw_to_pin_mv(), ignoring the raw parameter. It's a pragmatic hack that keeps the interface stable.

A cleaner design would have been a single battery_hal_adc_read_mv(int32_t *mv_out) function. But by the time I hit this problem, the two-function API was used everywhere. The adapter pattern was the right tradeoff.

Mistake 3: NVS flash page size

I hardcoded the NVS sector size to 4096 bytes (nRF52840 flash page size). STM32L476 has 2048-byte pages. The fix: query it at runtime:

struct flash_pages_info page_info;
flash_get_page_info_by_offs(flash_dev, offset, &page_info);
nvs.sector_size = page_info.size;

Lesson: even infrastructure like flash storage has platform-specific geometry.

The Porting Checklist

After three ports, here's my checklist for adding a new platform:

Add platform section to battery_adc_platform.h (~10 lines)
- ADC node label, VDD input channel, gain, reference, strategy flag
- NTC channel, gain, reference
Create board overlay (app/boards/<board>.overlay)
- Enable ADC, temperature sensor, GPIO aliases
Create board config (app/boards/<board>.conf)
- Kconfig: temp source, BLE, charger pins
Check devicetree node labels
- Die temp sensor name? Add to the fallback chain if new.
- ADC node name? Add to NTC driver if different.
Test ADC sequence compatibility
- Does the platform support oversampling? Calibrate flag? Custom acquisition time?
Build and verify — no core module changes should be needed.

If step 6 requires core changes, the HAL interface is incomplete. Go back and fix the abstraction.

Results

Platform	Flash	RAM	Core code changes
nRF52840-DK	152 KB	30 KB	(original)
NUCLEO-L476RG	38 KB	10 KB	0
ESP32-C3 DevKitM	356 KB	138 KB	0

Zero core module, intelligence, telemetry, or transport changes across all three ports. Only HAL files and board configs.

Key Takeaways

Separate constants from logic. A platform header with just #defines is easy to extend. Logic with #ifdefs is not.
Use devicetree fallback chains instead of CONFIG_SOC_SERIES_* checks where possible. They're more resilient to new platforms.
Design for the weird platform. If you design your HAL around the easiest platform (nRF52's direct VDD read), the others won't fit. Design for the most constrained one and the simple cases fall out naturally.
Test on host, validate on hardware. 69 tests run in under 2 seconds without any embedded toolchain. Hardware validation is the final step, not the first.
The HAL boundary is where you'll find bugs. Most issues during porting were at the HAL edge — ADC parameters that don't transfer, node labels that differ, flash page sizes that vary. The core logic never broke.

How I Built a Portable Battery SDK That Runs on 3 MCU Platforms

Aliaksandr Liapin — Fri, 10 Apr 2026 06:03:39 +0000

Every battery-powered IoT project ends up reimplementing the same things: ADC voltage reading, SoC estimation, power state management, temperature monitoring. After doing this for the third time, I built a reusable SDK that handles all of it.

Watch the 4-minute demo

What is iBattery SDK?

It's an open-source C library (Apache 2.0) that provides a standardized battery intelligence layer for embedded devices running Zephyr RTOS. You init it with one call, and it gives you:

Voltage measurement with moving average filtering
State-of-Charge estimation via lookup table interpolation (CR2032 + LiPo)
Temperature monitoring (on-chip die sensor or external NTC thermistor)
Power state machine (ACTIVE → IDLE → SLEEP → CRITICAL, with charger integration)
BLE telemetry streaming to a Python gateway → InfluxDB → Grafana dashboard

The entire core uses ~48 bytes of static RAM, integer-only math, and zero heap allocation.

The Portability Challenge

The interesting part was making it run on 3 very different MCUs without changing any core code.

The HAL Abstraction

All platform-specific code lives behind a Hardware Abstraction Layer. The core modules only call HAL functions — they never include vendor headers. Porting to a new platform means implementing 5-6 HAL functions and adding board config files.

Three Different VDD Strategies

Each MCU reads battery voltage differently:

nRF52840 — reads VDD directly via the SAADC internal input. Simplest approach: configure gain and reference voltage, read the ADC.

STM32L476 — can't read VDD directly. Uses VREFINT: an internal ~1.21V bandgap reference. The ADC measures VREFINT against VDDA, and factory calibration data in ROM lets you back-calculate VDD.

ESP32-C3 — also can't read VDD. Uses an external voltage divider: two 100K resistors split the battery voltage in half, and the ADC reads the midpoint. Firmware multiplies by 2.

All three strategies are hidden behind the same battery_hal_adc_read_raw() / battery_hal_adc_raw_to_pin_mv() interface. The temperature module, SoC estimator, and telemetry layer don't know or care which MCU they're running on.

Platform Config in One Header

The battery_adc_platform.h header is the master switch:

#if defined(CONFIG_SOC_SERIES_NRF52X)
    // Direct SAADC, 1/6 gain, 0.6V reference
#elif defined(CONFIG_SOC_SERIES_STM32L4X)
    // VREFINT sensor, factory calibration
#elif defined(CONFIG_SOC_SERIES_ESP32C3)
    // Voltage divider, 12dB attenuation
#endif

Adding a fourth platform is ~50 lines of config in this header plus a board overlay and Kconfig file. No C code changes needed.

The Full Pipeline

The SDK doesn't stop at the firmware. There's a complete telemetry pipeline:

MCU (BLE GATT notifications, 24-byte packets every 2s)
  → Python gateway (bleak library, auto-reconnect)
    → InfluxDB 2.x (time-series storage)
      → Grafana (11-panel dashboard)

The gateway includes real-time anomaly detection, battery health scoring, remaining useful life estimation, and charge cycle analysis — all accessible via CLI.

Build Matrix

Platform	Flash	RAM	BLE
nRF52840-DK	152 KB	30 KB	Native
NUCLEO-L476RG	38 KB	10 KB	Shield
ESP32-C3 DevKitM	356 KB	138 KB	Native

Getting Started

# Clone
git clone https://github.com/aliaksandr-liapin/ibattery-sdk.git

# Run tests (no hardware needed)
cd ibattery-sdk
cmake -B build_tests tests && cmake --build build_tests
ctest --test-dir build_tests --output-on-failure
# 11 C test suites pass

# Build for nRF52840
west build -b nrf52840dk/nrf52840 app

# Start the cloud stack
cd cloud && docker compose up -d
cd gateway && pip install -e .
ibattery-gateway run
# Open http://localhost:3000 for Grafana dashboard

What I Learned

HAL design matters more than you think. Getting the abstraction boundary right on the first platform (nRF52840) made the STM32 and ESP32 ports almost trivial.
Integer-only math is worth the constraint. No FPU dependency means the code runs identically on Cortex-M4F, Cortex-M4, and RISC-V without any float promotion surprises.
Zephyr's devicetree is painful but powerful. Once you understand overlays and Kconfig, adding a new board is mostly config — not code.
Test on host, validate on hardware. 69 tests run in under 1 second on macOS without any embedded toolchain. Hardware validation is the final step, not the first.