DEV Community: Aliaksandr Liapin

The Zephyr fuel_gauge API Has No 'Battery Health' Property - So My Driver Adds One

Aliaksandr Liapin — Sat, 06 Jun 2026 03:15:34 +0000

There's a moment in every open-source project where you stop asking "is my thing good?" and start asking "is my thing the obvious choice?" The difference is usually interoperability: does it plug into what people already use, or does adopting it mean betting on your bespoke API?

My battery SDK (ibattery-sdk, Apache-2.0) had a bespoke API. It does some genuinely useful things on tiny MCUs — estimates State of Charge, and even learns a battery's State of Health (how worn out it is) on-device, in integer-only C. (That last part is its own story.) But to use any of it, you had to learn my headers.

So I taught it to speak the language Zephyr developers already use: the fuel_gauge driver API. This is the story of doing that — including the part where I discovered the standard is missing the one property I care about most, and the part where verifying against the actual source code stopped me from publishing something false.

What "speaking the standard" means

Zephyr has a fuel_gauge subsystem: a uniform driver interface with a fuel_gauge_get_prop() call and drivers for real gauge chips (max17048, sbs_gauge, …). If your code is written against it, you can swap the gauge underneath without touching your app:

const struct device *fg = DEVICE_DT_GET_ANY(aliaksandr_ibattery_fuel_gauge);
union fuel_gauge_prop_val v;

fuel_gauge_get_prop(fg, FUEL_GAUGE_VOLTAGE, &v);                    /* µV */
fuel_gauge_get_prop(fg, FUEL_GAUGE_RELATIVE_STATE_OF_CHARGE, &v);   /* %  */

The goal: make iBattery be one of those drivers, so adopting it isn't a bet — it's just "the implementation behind the API you already use." I scoped it deliberately as read-only (a software view over the SDK's existing outputs, no set_property), instantiated from a devicetree node like any real gauge, and opt-in (CONFIG_BATTERY_FUEL_GAUGE_API, off by default — zero impact if you don't want it).

Most of it mapped cleanly

The SDK already computes everything the common properties want; the work was mostly unit conversion, and the units are the fiddly part. From the header (verified, not remembered):

Zephyr property	Unit	iBattery source
`VOLTAGE`	µV	mV × 1000
`CURRENT` / `AVG_CURRENT`	µA, negative = discharging	mA × 1000, sign-flipped
`TEMPERATURE`	0.1 K	°C × 10 + 2731.5
`RELATIVE_STATE_OF_CHARGE`	% (0–100)	SoC, rounded
`REMAINING_CAPACITY`	µAh	coulomb counter
`FULL_CHARGE_CAPACITY`	µAh	learned (SoH-adjusted) capacity
`DESIGN_CAPACITY`	mAh	rated capacity
`CYCLE_COUNT`	1/100ths	cycle count

Two things worth calling out. First, the current sign convention is flipped from mine (Zephyr says discharge is negative; I report it positive) — exactly the kind of detail that's invisible until it's wrong on real hardware. Second, a happy accident: the spec literally says FULL_CHARGE_CAPACITY "might change … to determine wear" — so when I map it to the SoH-learned capacity, a standard SBS-style consumer sees the battery's aging for free, through a standard property.

The property the standard forgot

Here's the twist. I went to map my headline feature — State of Health — to its standard property… and there isn't one. I grepped the actual fuel_gauge.h in two Zephyr versions:

$ grep -i health include/zephyr/drivers/fuel_gauge.h
$        # (nothing)

The standard fuel-gauge API has RELATIVE_STATE_OF_CHARGE, ABSOLUTE_STATE_OF_CHARGE, capacities, cycle count… but no State-of-Health property at all.

This matters to me personally, because minutes earlier I had written — in a positioning doc — that "the Zephyr fuel_gauge API even has a State-of-Health property that maps onto our feature." That was wrong. I'd written it from memory. Reading the header before building is the only reason it didn't ship. (Lesson, stated plainly: don't trust your memory of an API surface — open the file.)

But a missing standard property isn't a dead end — the API has an escape hatch (FUEL_GAUGE_CUSTOM_BEGIN) for exactly this. So iBattery extends the standard with a documented custom property:

/* State of Health: value in val.flags as centi-percent (7310 == 73.10 %) */
#define BATTERY_FUEL_GAUGE_PROP_SOH (FUEL_GAUGE_CUSTOM_BEGIN + 0)

So the positioning flipped from a (false) "we match the standard" to a (true and better) "we conform to the standard for the common properties, and add the battery-health metric the standard is missing."

How I kept it honest: separate the math from the glue

A Zephyr driver is hard to unit-test (it needs the device model + devicetree). So I split it:

Pure conversion helpers — plain C, no Zephyr includes (mV→µV, the current sign-flip, °C→0.1 K, the SoH-scaled capacity, …). These are host-unit-tested with the same fixed-point edge cases the rest of the SDK uses.
A thin driver that just calls those helpers and packs the result into the union. It's verified by a build-smoke test in CI: a tiny consumer that DEVICE_DT_GETs the node and calls fuel_gauge_get_prop, built on ESP32-C3 through the real subsystem.

All the risky arithmetic is covered by fast host tests; the platform glue is proven to link.

The payoff: read it back on real hardware

Build-passing isn't the same as correct. So I added an opt-in self-check that, each cycle, reads every property back through fuel_gauge_get_prop() and prints it next to the SDK's native telemetry — then ran it on a NUCLEO-L476RG with a real current sensor and a programmable supply standing in for the cell:

native:  V=3133mV  I=32.60mA  SOC=1.28%  Q=219.85mAh  SOH=100.00%
[FG]:    V=3137000uV  I=-32600uA  SOC=1%  REM=219850uAh  FULL=220000uAh
         DESIGN=220mAh  SOH(flags)=10000  set_rc=-88

Every line checks out:

V in µV = mV × 1000 ✓
I = -32600 µA — scaled and sign-flipped (discharge negative) ✓
REM = 219850 µAh = 219.85 mAh — tracks the coulomb counter exactly ✓
SOH(flags) = 10000 = 100.00 % ✓
set_rc = -88 (-ENOSYS) — the read-only contract, confirmed ✓

A battery learning it's worn out, surfaced through the standard interface, validated by reading it straight back. That's the whole loop.

Why this matters

Conforming to a standard interface is unglamorous and high-leverage. It means a Zephyr developer can reach for iBattery the same way they reach for any fuel-gauge driver — and get something the dedicated gauge chips often don't bother with on cheap hardware: an on-device battery-health number, in a couple hundred bytes of integer code.

It's free and open, runs on nRF52840 / STM32L4 / ESP32-C3, and it's read-only today (reading is the 90% case; writing can come later):

👉 github.com/aliaksandr-liapin/ibattery-sdk

If you're building battery-powered hardware on Zephyr, enable CONFIG_BATTERY_FUEL_GAUGE_API, drop in the devicetree node, and read your battery — including how aged it is — through the standard API. Issues and PRs welcome.

Read-only driver, validated by reading every property back on a NUCLEO-L476RG + INA219 + PPK2 rig. The voltage is bench-emulated; the conversions, the SoH, and the read-back are real.

I Made a Battery Admit It Was Only 73% Healthy — On-Device, End to End

Aliaksandr Liapin — Thu, 04 Jun 2026 18:45:02 +0000

Voltage lies.

Put a battery under load and its terminal voltage sags. Let it rest and the voltage springs back. A naive fuel gauge watching only voltage will happily tell you a worn-out cell is "fine" right up until it falls off a cliff. The number you actually care about — is this battery still good, or is it time to replace it? — isn't in the instantaneous voltage at all. It's in the capacity: how much charge the cell can still deliver between full and empty.

That quantity fades as a cell ages. Tracking it is called State of Health (SoH), and it's the difference between "the device says 80%" and "the device has 80% of the runtime it had when it was new."

I wanted my open-source battery SDK (ibattery-sdk, Apache-2.0) to learn SoH on the device itself — no cloud model, no floating-point, on MCUs with kilobytes of RAM. This post is the story of getting that working end to end: from a coulomb integral in firmware to a faded value showing up live on a Grafana dashboard.

The idea: learn capacity from one full→empty trip

You don't need a PhD-grade model to estimate usable capacity. You need two anchors and an ammeter.

Full anchor — when the cell is at its full-voltage plateau, declare "this is full" and set the coulomb counter to the rated capacity.
Discharge — integrate current over time (coulomb counting). Every milliamp-hour that leaves the cell ticks the counter down.
Empty anchor — when the cell hits its empty-voltage threshold, look at how much charge actually flowed. A healthy cell delivers close to its rated capacity before going empty. An aged cell hits empty early — it simply has less to give.

From the charge measured between those two anchors, you get the cell's real usable capacity, and SoH = measured / rated. The SDK runs it through an integer EMA (so one noisy excursion doesn't whip the estimate around) and a plausibility guard (reject anything outside 30–120% of rated — that's almost certainly a glitch, not a real measurement).

The whole thing is integer-only, ~200 bytes of flash, and zero new static RAM. It's opt-in behind a Kconfig flag and rides on the coulomb counter that was already there.

That's the theory. The fun part is proving it on hardware.

You can't wait six months for a coin cell to age

Here's the catch with validating a capacity-fade feature: capacity fade takes months. I was not going to babysit a coin cell through a hundred discharge cycles to get a number on a chart.

So I cheated — honestly. I used a Nordic PPK2 (Power Profiler Kit II) as a programmable cell emulator. In Source Meter mode it's a voltage source you can sweep from ~0.8 V to 5 V while it measures current. That means I can drive the sensed battery voltage anywhere I want, independently of the MCU's own supply, and walk it through a full→empty excursion in minutes instead of months.

The rig (all on a breadboard):

PPK2 sources the emulated cell voltage.
A resistor divider taps that voltage down onto an ADC pin (the firmware has an external-ADC voltage-sense mode for exactly this).
An INA219 current sensor in the load path measures the real current flowing through a load resistor — that's what feeds coulomb counting.
Everything shares a common ground (the ADC measures relative to it — skip this and you get garbage).

One nice detail: the divider tap sits before the INA219 shunt, so the ~microamps the divider draws never pollute the current reading.

The bring-up gotchas (because there are always gotchas)

The divider reads low. My 10 kΩ/10 kΩ divider plus ADC gain came in about 9% under the true voltage. That doesn't matter for SoH — SoH is charge-based, not voltage-based — but it does matter for the anchors, which are voltage thresholds. To make the firmware read ≥ 2950 mV (the full-anchor threshold), I had to set the PPK2 to ~3300 mV. Measure, don't assume.

Make the excursion fast. At the default rated capacity, draining at ~33 mA would take hours. I rebuilt with a small rated-capacity override so a full excursion finishes in a few minutes — same physics, faster clock.

Cross-check your instruments. The PPK2's own ammeter read 31.9 mA while the INA219 reported 31.7 mA — agreement under 1%. When two independent measurements agree, you trust the chain.

Watching it happen

With the full anchor armed (SOH = 100%), I let it discharge, then swept the PPK2 down toward empty. The serial stream tells the whole story:

V=2890 mV  I=22.4 mA  Q=5.39 mAh  SOH=100.00%
V=2623 mV             Q=5.38 mAh  SOH=100.00%
V=2351 mV             Q=5.37 mAh  SOH=100.00%
V=2079 mV  PWR=4      Q=0.01 mAh  SOH=73.10%   ← empty anchor fires
>>> SOH CHANGED 100.00% -> 73.10% <<<

There it is. The moment the reading crossed into the empty region, the empty anchor fired, the coulomb counter snapped to zero (nothing left), and the SDK locked in a learned State of Health of 73.10% — a plausible, faded value, computed entirely on a Cortex-M4 with integer math.

From firmware to a live dashboard

A number in a serial log is satisfying. A number on a dashboard is convincing.

The SoH value rides out over BLE in the telemetry packet (a dedicated wire-format field), into a Python gateway, into InfluxDB, and onto a Grafana panel. I confirmed it landed in the database directly:

_field: soh_pct   _measurement: battery_telemetry   _value: 73.1

And on the dashboard, the State of Health gauge dropped from 100% to 73.1%, with the trend graph capturing the exact step down. (Screenshot above.) That's the whole pipeline — firmware → BLE → gateway → time-series DB → dashboard — carrying a value the device figured out about itself.

The part that makes it real: it survives a reboot

A learned value you lose on power-cycle is a parlor trick. So the SDK persists the learned capacity to flash (Zephyr NVS), behind a guard that rejects the stored value if the configured rated capacity has changed.

I reset the board and watched the first telemetry line after boot:

Battery SDK initialized OK
[v4 t=32]  V=1872 mV  SOH=73.10%   ← restored from flash, not 100%

It came up reading 73.10%, straight from flash — not re-initialized to 100%. Learn it once, keep it forever (or until the next excursion refines it).

Why this matters

Knowing which devices in a deployment are genuinely wearing out — versus just momentarily sagging under load — is the foundation for sensible battery-replacement decisions. Doing that estimation on-device, in a couple hundred bytes of integer code, means it works on the cheapest sensor node without a cloud round-trip.

It's all open source and runs today on nRF52840, STM32L4, and ESP32-C3 (Zephyr RTOS):

👉 github.com/aliaksandr-liapin/ibattery-sdk

If you're building battery-powered hardware and want a fuel gauge that tells you the truth about aging — not just the moment-to-moment voltage — take it for a spin. Issues and PRs welcome.

Built and validated with a NUCLEO-L476RG, an X-NUCLEO BLE shield, an INA219, and a PPK2 standing in for a cell. The voltage readings are emulated; the coulomb counting, the SoH math, the persistence, and the dashboard are all real.

When Soldering Doesn't Fix It: Swap the MCU

Aliaksandr Liapin — Fri, 29 May 2026 19:35:51 +0000

A hardware-debugging technique that uses your portable firmware codebase as the diagnostic tool. Plus the deeper bug it exposed once I got past the hardware wall.

I spent a week chasing an I2C bus that refused to ACK. By the end of it, I had soldered the breakout, replaced every jumper, swapped chips, and verified every pin assignment three times. The firmware still reported 0 devices found on every scan.

What finally cracked it wasn't another tweak in the same setup. It was moving the peripheral to a different MCU — and discovering that the same chip, with the same wires, came up 6/6 immediately on a NUCLEO.

Here's the technique, and the bonus firmware bug it exposed once I got past the hardware wall.

The symptom

iBattery SDK, Phase 8a: an Adafruit INA219 current sensor wired to a nRF52840-DK over I2C, addressed at 0x40. From the firmware shell:

uart:~$ i2c scan i2c@40003000
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
40:  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0 devices found on i2c@40003000

Six scans in a row, all empty. A logic analyzer earlier in the project had captured the chip ACKing on the wire occasionally — so the chip was alive — but the firmware never saw it.

What I had already ruled out

By the time soldering came into the picture, I'd already burned through the usual suspect list:

Power: Adafruit "on" LED solid green → VCC + GND wires good
Pin assignment: triple-verified P0.26 = SDA, P0.27 = SCL, VDD on the power header
Wires: replaced both data jumpers with fresh, different-colored wires
Chip: swapped to a second known-good INA219, same result at every address (0x40, 0x41, 0x44, 0x45 — all --)
Firmware: unchanged from a prior release that had captured clean ACKs on a logic analyzer

I soldered the male header pins onto the INA219 PCB to eliminate the press-fit class of failure entirely. Re-scan: still 0/6.

At that point I'd run out of in-place things to try.

The pivot: swap the MCU

The SDK was already portable — nRF52840-DK, NUCLEO-L476RG, and ESP32-C3 all built from the same source tree, with per-board overlays and configs. I'd never thought of that portability as a debugging tool before, but here we were: same firmware logic, same INA219 driver, same wire-level protocol — just running on different silicon.

So I added a minimal STM32 build config:

// app/boards/nucleo_l476rg.overlay (excerpt)
&i2c1 {
    ina219: ina219@40 {
        compatible = "ti,ina219";
        reg = <0x40>;
        status = "disabled";
        shunt-milliohm = <100>;
        // ...
    };
};

# app/boards/nucleo_l476rg_i2cscan.conf
CONFIG_I2C=y
CONFIG_SHELL=y
CONFIG_I2C_SHELL=y
CONFIG_BATTERY_CURRENT_SENSE=y
CONFIG_BATTERY_SOC_COULOMB=y
CONFIG_BATTERY_CAPACITY_MAH=220

Built and flashed:

west build -b nucleo_l476rg app -d /tmp/build-stm32-scan --pristine -- \
    -DEXTRA_CONF_FILE=boards/nucleo_l476rg_i2cscan.conf
west flash -d /tmp/build-stm32-scan --runner openocd

Moved the exact same wires from the nRF DK to the NUCLEO's Arduino I2C pins (PB8/PB9 = D15/D14). Reset, scanned:

uart:~$ i2c scan i2c@40005400
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
40:  40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
1 devices found on i2c@40005400

Six out of six scans ACKed 0x40. Telemetry started flowing:

[v3 t=92117] V=3323 mV T=23.56 C SOC=100.00% PWR=1 CYC=0 flags=0x00000000
I=0.20 mA Q=220.00 mAh

Note flags=0x00000000 — no CURRENT_ERR. On the nRF DK this had been stuck at 0x00000020 for two weeks.

The conclusion this isolation enabled

I now had two chips, multiple fresh wires, and the firmware all working correctly on STM32. That ruled out the chip, the wires, and the firmware in one experiment. The only remaining variable was the specific nRF52840-DK unit.

The defect was local to that DK's P0.26 / P0.27 GPIOs — most likely damaged from repeated plug-cycle wear over many sessions. Not a chip issue, not a wiring issue, not a firmware issue. A per-unit hardware defect on a specific MCU board.

I never would have isolated this cleanly without changing the MCU. Every other test I ran kept the broken hardware in the loop.

What "swap the MCU" requires

Two preconditions, and the technique is cheap. Without them, it's not available:

Portable firmware with a HAL clean enough that you can rebuild for a different MCU without rewriting drivers. In my case the SDK already supported three platforms — same code, different overlay.
A second known-good MCU with the right peripheral on physically accessible pins. The STM32 NUCLEO's Arduino-compatible I2C1 (PB8/PB9) was already silkscreened.

If you only have one platform target or your driver code is wired to one chip's idioms, this technique isn't available to you — and that itself is an argument for keeping your HAL portable.

The bonus payload: a bug the swap exposed

This is the part that surprised me. Once the chip was responding cleanly on STM32, I let it run for five minutes under a small load (~1 kΩ resistor across Vin+/Vin-, ~2.80 mA draw).

   t (ms)   V (mV)   T (C)      SOC     flags    I (mA)    Q (mAh)
 5506348     3322   23.56  100.00%  00000000      2.80     220.00
 5536382     3322   23.89  100.00%  00000000      2.80     220.00

I is correctly reading 2.80 mA. But Q (the coulomb accumulator, nominal full = 220 mAh) is pinned at 220.00. Over five minutes, delta = 0.0000 mAh. SoC stuck at 100%.

Discharge at 2.80 mA for 300 seconds should accumulate 0.233 mAh of charge consumed — easily resolvable with the 0.01 mAh display precision. Something was actively resetting Q.

I had two suspects, and both turned out to be real bugs:

Bug B — the full anchor was firing every sample

The SoC estimator periodically calibrates the coulomb counter at known voltage anchors (full at the top of the curve, empty at the bottom). For CR2032, the macro that gates the "this is full" condition on current draw is 0:

// src/intelligence/battery_soc_estimator.c
#define SOC_ANCHOR_FULL_I_X100  0    // primary cell, no current check

// ...
if (voltage_mv >= SOC_ANCHOR_FULL_MV &&
    (SOC_ANCHOR_FULL_I_X100 == 0 ||
     abs_current < SOC_ANCHOR_FULL_I_X100)) {
    // reset coulomb counter to full capacity
    battery_coulomb_reset(full_mah_x100);
}

For CR2032, SOC_ANCHOR_FULL_I_X100 == 0 short-circuits the || to true, collapsing the entire gate to just V >= 2950 mV. A fresh CR2032 sits well above 2.95 V under any realistic load and never exits that condition during normal use — so the anchor fires on every sample, wiping the integration delta each time.

I fixed this by making the anchor a one-shot edge-detected event:

static bool g_full_anchor_active;
static bool g_empty_anchor_active;

if (in_full_region) {
    if (!g_full_anchor_active) {
        battery_coulomb_reset(full_mah_x100);
        g_full_anchor_active = true;
    }
    g_empty_anchor_active = false;
} else {
    g_full_anchor_active = false;  // re-arm
    g_empty_anchor_active = false;
}

The anchor calibrates once when entering the region, then lets the integrator do its job until voltage leaves the region.

Bug A — the integrator and the estimator disagreed on Q's meaning

This one is sneakier. Look at the integrator:

// src/intelligence/battery_coulomb.c (before)
g_accumulated_mah_x1000 += delta_mah_x1000;

Positive current (INA219's discharge convention) → positive delta → Q increases. So Q is "cumulative throughput."

Now look at the SoC estimator:

// On full anchor:
battery_coulomb_reset(full_mah_x100);  // Q := capacity

// On read:
soc = mah_x100 * 10000 / capacity_x100;  // soc = Q / capacity

The estimator sets Q to capacity at full, reads it back, and computes SoC as Q / capacity. That's "Q-as-remaining-capacity" semantics — the opposite of what the integrator implements.

Even with Bug B fixed in isolation, the integrator would have grown Q above capacity during discharge, the SoC math would have clamped at 100%, and the system would have looked superficially fine while silently misreporting forever.

The fix is one character:

// src/intelligence/battery_coulomb.c (after)
g_accumulated_mah_x1000 -= delta_mah_x1000;  // Q-as-remaining

…plus updates to the unit tests that were enshrining the old semantics, and a new TDD regression test that drives the estimator across 100 samples at the full anchor and asserts Q strictly decreases.

The proof on hardware

Same rig, same load, same five-minute capture, two firmware versions:

v0.8.3 (broken):   Q = 220.00 mAh stuck         SoC = 100.00% stuck
v0.8.4 (fixed):    Q = 219.98 → 219.75 mAh      SoC = 99.99% → 99.88%
                   Δ = -0.23 mAh in 300 s @ 2.80 mA load
                   theoretical:  -0.233 mAh

Δ matches theory to two decimal places. The anchor calibration is even visible in the first sample — Q starts at 219.98 (not 220.00), confirming the anchor fired once at boot and the integrator immediately began tracking the load.

What I'd file under "lessons"

1. Your portable firmware codebase is a diagnostic tool. If you've spent any effort keeping a clean HAL, you've already bought yourself the swap-the-MCU technique. Use it.

2. "Analyzer sees X, firmware reads Y" usually means signal integrity, not a software bug. I spent too long suspecting the firmware before the analyzer captures redirected me to the wire.

3. "Symptom A consistent with no bug" can hide compounding bugs. The SoC clamping at 100% looked like correct anchor behavior. It was also masking a sign-flipped integrator. Bugs that hide each other are disproportionately expensive — fix one, the other surfaces immediately.

4. Per-unit GPIO damage is real. A DK plugged and unplugged dozens of times can have specific pins go bad in ways that aren't obvious without a clean comparison. The board still boots, runs other peripherals, and the GPIO reads 3.3 V at idle — only the edge-sensitivity of I2C exposes the fault.

5. TDD regression tests for hardware bugs feel slow until they save you twice. The new test_cr2032_full_anchor_fires_once_not_every_sample test took 20 minutes to write. It documented exactly the bug, failed deterministically before the fix, passed after, and will catch any future regression from someone "simplifying" the anchor logic.

Wrap-up

Repo: aliaksandr-liapin/ibattery-sdk

Releases that came out of this debugging arc:

v0.8.3 — swap to STM32, validated end-to-end
v0.8.4 — the two coulomb bugs fixed
v0.8.5 — gateway + Grafana panels surface the working signal

Captures preserved in the repo at docs/captures/ for anyone who wants the raw evidence. The diagnostic methodology is written up in docs/HARDWARE_TROUBLESHOOTING.md.

If you've got a hardware bug that won't budge and your codebase is portable, try the swap. Worst case you've confirmed your firmware works on another platform.

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.

DEV Community: Aliaksandr Liapin

The Zephyr fuel_gauge API Has No 'Battery Health' Property - So My Driver Adds One

What "speaking the standard" means

Most of it mapped cleanly

The property the standard forgot

How I kept it honest: separate the math from the glue

The payoff: read it back on real hardware

Why this matters

I Made a Battery Admit It Was Only 73% Healthy — On-Device, End to End

The idea: learn capacity from one full→empty trip

You can't wait six months for a coin cell to age

The bring-up gotchas (because there are always gotchas)

Watching it happen

From firmware to a live dashboard

The part that makes it real: it survives a reboot

Why this matters

When Soldering Doesn't Fix It: Swap the MCU

The symptom

What I had already ruled out

The pivot: swap the MCU

The conclusion this isolation enabled

What "swap the MCU" requires

The bonus payload: a bug the swap exposed

Bug B — the full anchor was firing every sample

Bug A — the integrator and the estimator disagreed on Q's meaning

The proof on hardware

What I'd file under "lessons"

Wrap-up

Why I Shipped Coulomb Counting Before the Hardware Worked

The voltage-lookup-table problem

Designing the architecture

The coulomb counter

Voltage anchoring

The voltage smoothing layer

Median filter (replaces moving average)

SoC slew limiter

And then the hardware didn't work

The shipping discipline

CI as accountability

What's next

Takeaways

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

The Problem

Attempt 1: The Giant #ifdef

What Actually Works: Separate the What from the How

Layer 1: Platform Constants (one header)

Layer 2: Strategy Selection (one C file)

Layer 3: Everything Above (zero platform awareness)

The Temperature Sensor Problem

What I Got Wrong (and Fixed)

Mistake 1: Hardcoded ADC parameters

Mistake 2: Assuming VDD is readable

Mistake 3: NVS flash page size

The Porting Checklist

Results

Key Takeaways

Links

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

Watch the 4-minute demo

What is iBattery SDK?

The Portability Challenge

The HAL Abstraction

Three Different VDD Strategies

Platform Config in One Header

The Full Pipeline

Build Matrix

Getting Started

What I Learned

Links