Smart battery full_charge_capacity does NOT get updated without a reboot

Hi,

I had a question about the full charge capacity read by the pixhawk and relayed to Mavproxy/MP. I can see in AP_BattMonitor_SMBus.cpp that the full_charge_capacity register is only being read once and once it gets a non-zero value it does not read the register again until the vehicle is rebooted.

Is there a reasoning behind this? The full charge capacity of the battery degrades over time/use. Is there any downside to polling the full_charge_capacity register as often as the other registers are being polled?

Thank you.

    bool AP_BattMonitor_SMBus::read_full_charge_capacity(void)
    {
        uint16_t data;

        if (_full_charge_capacity != 0) {
            return true;
        } else if (read_word(BATTMONITOR_SMBUS_FULL_CHARGE_CAPACITY, data)) {
            _full_charge_capacity = data;
            return true;
        }
        return false;
    }

I want to remove the following check so that its being read periodically

if (_full_charge_capacity != 0) {
    return true;
}

Designed capacity is only set when the battery/BMS is manufactured.
Actual full capacity changes as battery re-calibrates it, only on full charge or close to it.
Remaining capacity decreases thru the flight, and is read out often. this is what you really need, … to know how many mAh is left , NOT to know the actual full capacity of the battery , even if it did change thru the flight.

In other words; there is absolutely no reason for such change.
you may learn a few things about how smart batteries work by reading the description of items displayed by this device: https://madhacker.org/3dr-solo-battery-charging-adapter-and-diagnostics-tool/

As @Andre-K indicated it’s not likely with any of the BMS’s I’ve seen that the full capacity value will be updated during a discharge cycle. Unless you are trying to hot swap batteries, or charging with the autopilot booted I can see why you need to reread this information? There are a couple of things like battery failsafes which will not behave well without rebooting the vehicle at the moment if this is your intended use case.

@Andre-K @WickedShell thank you for your responses. We keep our drones on for a day or two and it goes through several charge cycles and missions. The drone goes through a charge and discharge cycle and the full charge capacity changes. We have a status LED that indicates the charge level by reading the percentage remaining via dronekit API. And sometimes when it goes through one or two charge cycles the percentage remaining that’s shown is wrong because the full charge capacity has reduced a bit and arducopter does not know about the decrease in full charge capacity as it reads it only once. So in this scenario I thought it’d be better and more reliable for the full charge capacity to be read more often than just once.

It’s ok to have ground power or hotswap, could you just script in a preflight reboot (just a command to the flight controller) ?

  • it does not have to be right before flight, but somewhere in between flights should do.
    That would solve it just fine, and there are other advantages of doing a preflight reboot as well.

Also: a healthy battery won’t change its actual capacity that much fast, your energy calculation/flight time calculation or other safety alerts should be based on actual remaining capacity or SOC , not calculated by using “actual_capacity_when_full” - “spent_capacity”.

Possibly more important: A battery failsafe level can only be triggered once per boot (to avoid jitter when the battery is unloaded/loaded again). So if you are using battery failsafes it will never retrigger on you until you reboot.

Thank you @Andre-K and @WickedShell. Also, isn’t it beneficial to have both DESIGN_CAPACITY and FULL_CHARGE_CAPACITY read from the BMS? It’ll give an idea of how fast your battery is degrading and their state of health? Or there might be additional registers which indicate state of health.

Yes, on arm, those two could be nice, just for log’s sake.

Is it possible for DESIGN_CAPACITY change to be made in 3.6 stable release?

I’m not sure what the autopilot would do with DESIGN_CAPACITY. We care about full charge/remaining capacity for failsafe reasons, DESIGN_CAPACITY only show up as useful for long term battery analysis, which at the moment can easily be done as you know what a given battery had as design capacity.

State of health/alarms however should be honored, and it isn’t something we currently use at all.