Add INA226 battery meter support

[FlyingRC-Official]

Summary

Add INA226 support as both a battery voltage source and current meter source.

This uses the INA226 shunt-voltage and bus-voltage registers directly, so INAV keeps using its existing battery pipeline for filtering, power, mAh/mWh, alarms, OSD, telemetry, and stats. It does not depend on the INA226 calibration/current/power registers.

Details

• Add CURRENT_SENSOR_INA226 and VOLTAGE_SENSOR_INA226.
• Add INA226 to the CLI current_meter_type and vbat_meter_type settings.
• Add an INA226 I2C driver behind USE_INA226.
• Register INA226 through the bus-device system with:
  • INA226_I2C_BUS
  • optional INA226_I2C_ADDRESS
  • default address 0x40
• Detect INA226 using manufacturer ID and die ID registers.
• Read:
  • shunt voltage register 0x01
  • bus voltage register 0x02
• Convert INA226 bus voltage using 1.25 mV/bit.
• Convert shunt voltage to centiamps using ina_shunt_res_uohm.
• Add ina_shunt_res_uohm as a CLI setting for INA226 shunt resistor value in micro-ohms.
• Add shared USE_BATTERY_VOLTAGE_SENSOR gating so non-ADC voltage sources can use the normal battery voltage/profile/power-limit settings.
• Keep existing ADC defaults unchanged unless a target explicitly opts into INA226.

Target Opt-In

This PR does not change any official target default voltage/current source.

Targets that have an INA226 can opt in with something like:

#define USE_INA226
#define INA226_I2C_BUS BUS_I2C2
#define INA226_I2C_ADDRESS 0x40
#define INA226_SHUNT_RES_UOHM 300
#define CURRENT_METER_TYPE_DEFAULT CURRENT_SENSOR_INA226
#define VBAT_METER_TYPE_DEFAULT VOLTAGE_SENSOR_INA226

INA226_I2C_ADDRESS is optional and defaults to 0x40.

Notes

The setting is named ina_shunt_res_uohm instead of using ina226 in the CLI setting name. This avoids issues with the settings-name compressor on some F4 targets.

The first version supports one INA226 device per target. Address scanning and runtime address configuration can be added later if needed.

Hardware Test

Tested on:

• Target: MATEKH743
• INAV: 9.0.1-based branch
• INA226 connected on CL2/DA2, which maps to I2C2 PB10/PB11
• Shunt: 0.3 mOhm
• CLI setting:

set ina_shunt_res_uohm = 300
save

Result:

• Battery voltage reads correctly.
• Current reads correctly.
• INAV Configurator status page shows expected voltage/current values.
• Verified against an external electronic load / power meter.

Observed values:

Source	Voltage	Current	Power
INAV Configurator	12.11 V	2.14 A	25.91 W
External meter	12.097 V	2.000 A	24.197 W

The current difference is expected to depend on shunt tolerance, wiring, load stability, and filtering/calibration.

Test Photos

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[github-actions]

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

---

This is an automated suggestion to help route contributions to the appropriate branch.

[github-actions]

Test firmware build ready — commit 5d8d561

Download firmware for PR #11656

238 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[sensei-hacker]

My AI-based tool brought up a question that may be interesting (or not):

In power_limits.c, powerLimiterApply() was changed from:

int16_t current = getAmperageSample();
to:
int16_t current = getAmperage();

getAmperage() returns the cached value after the 1 Hz PT1 low-pass filter (AMPERAGE_LPF_FREQ in battery.c), while getAmperageSample() returns a fresh, unfiltered instantaneous reading. This line isn't gated behind USE_INA226, so
it changes the current-limiter's input for every existing target using USE_POWER_LIMITS with any current sensor (ADC, virtual, ESC telemetry) — not just new INA226 hardware.

Was this intentional? If the goal was just to make powerLimiterApply() compile without USE_ADC, would it work to instead generalize getAmperageSample() itself to dispatch by sensor type — mirroring the pattern already used in the
CURRENT_SENSOR_INA226 case you added in currentMeterUpdate(), which already does a fresh ina226ReadShuntCurrent() read before filtering:

int16_t getAmperageSample(void)
{
switch (batteryMetersConfig()->current.type) {
case CURRENT_SENSOR_ADC:
return /* existing ADC math, unchanged */;
#if defined(USE_INA226)
case CURRENT_SENSOR_INA226: {
int16_t ina226Current;
return (ina226Detected && ina226ReadShuntCurrent(&ina226Dev, ..., &ina226Current))
? ina226Current + batteryMetersConfig()->current.offset : 0;
}
#endif
default:
return 0;
}
}

That would let power_limits.c keep calling getAmperageSample() unchanged, preserving the existing (unfiltered) dynamic response for every current target, while giving INA226 the same semantics as ADC. Happy to be wrong if there's
a reason the filtered value is actually preferable here — just want to make sure the dynamic-response change for existing hardware is a deliberate choice rather than a side effect of the generalization.