On Tue, Nov 30, 2021 at 7:33 AM Vaittinen, Matti
[off-list ref] wrote:

Hmm. Fair enough. Maybe instead of providing 'temperature range where
degradation is constant' we should simply support providing the
data-points. Eg, an array of known
temperature-[degradation/change]-from-[designed/full]-capacity pairs and
leave selecting the best fitting model to the software. Linear
interpolation is simple, and may suffice for cases where we have enough
of data-points - but you are correct that there probably are better
alternatives. Nice thing is software is that it can be changed over time
- so even implementing it with linear approach means opening a room for
further improvements ;)

Yeah someone will implement spline interpolation in the kernel one
day I bet...

Well, I don't know how constant such degradation is over time. I just
guess it is not constant but might be proportional to age-compensated
capacity rather than the designed capacity. It'd be nice to use correct
approximation of reality in device-tree...

IIUC the degradation of a battery is related to number of full charge cycles,
i.e. the times that the battery has been emptied and recharged fully.
This is of course never happening in practice, so e.g. two recharge cycles
from 50% to 100% is one full charge cycle. So you integrate this
over time (needs to be saved in a file system or flash if the battery does
not say it itself).

This measures how much the lithium ions have moved around in the
electrolyte and thus how much chemical interaction the battery has
seen.

Then the relationship between complete charge cycles and capacity
degradation is certainly also going to be something nonlinear so it
needs manufacturer data for the battery.

By the way, I was reading the ab8500 fuel-gauge driver as you suggested.
So, if I am correct, you used the battery internal resistance + current
to compute the voltage-drop caused by battery internal resistance. This
for sure improves the accuracy when we assume VBAT can be used as OCV.

Yes this is how it is done. With a few measurements averaged to
iron out the noise.

Epilogue:
In general, I see bunch of power-supply drivers scheduling work for
running some battery-measurements. Some do this periodically (I think
the ab8500 did this although I lost the track when I tried to see in
which case the periodic work was not scheduled - and maybe for
fuel-gauging) or after an IRQ is triggered (for example to see if change
indication should be sent).

Yes there is some tight community of electronic engineers who read the
right articles and design these things. We don't know them :(

I think we could simplify a few drivers if the core provided some helper
thread (like the simple-gauge) which could be woken by drivers (to do
fuel-gauge operations, or to just conditionally send the change
notification).

I think so too, I don't think they are very rocket science once the
right abstractions fall out.

Yours,
Linus Walleij