On 12/2/21 03:57, Linus Walleij wrote: > On Tue, Nov 30, 2021 at 7:33 AM Vaittinen, Matti > <Matti.Vaittinen@xxxxxxxxxxxxxxxxx> wrote: > >> 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). Yes. > 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. Right. As far as I understand, at least part of the 'aging degradation' comes from the fact that battery materials are 'vaporizing' when battery is charged. And as far as I understand, the temperature in which charging occurs has a big impact on this. Eg, higher the temperature where you do charging, worse the degradation. Which means that the cycle count should actually be weighed by the charging temperature. But this kind of missed my point :) I was thinking of how to give the absolute (uAh) value of capacity drop caused by the temperature. My original RFC patch gave this as linear change of absolute uAh's at a temperature range. As you pointed, we should not include the linearity in the DT model. So the next step would be to just give measured value pairs (should be done by battery vendor or computed by some theoretical basis) of absolute uAh/temperature - and leave fitting of the data points to be done by SW. What I was now considering is that maybe the capacity drop (in uAhs) caused by the temperature change - is not the same for new and old battery. It sounds more logical to me that the capacity drop caused by the temperature is proportional to the maximum capacity battery is having at that point of it's life. Eg, if new battery can hold 80 units of energy, and drops 20 units of energy when temperature changes from T0 => T1 - an badly aged battery which now only can hold 40 units would lose only 10 units at that same temperature drop T0 => T1. I was wondering if such an assumption is closer to the truth than saying that bot of the batteries would lose same 20 units - meaning that the new battery would lose 25% of energy at temperature drop T0 => T1 but old one would lose 50% of the capacity. I somehow think both of the batteries, old and new, would lose same % of capacity at the temperature change. So, if this assumption is correct, then we should give the temperature impact as proportion of the full capacity taking the aging into account. So if we happen to know the aging impact to the capacity, then software should use aging compensation prior computing the temperature impact. If aging information or impact is not known, then designed capacity can be used as a fall-back, even though it means we will probably be somewhat off for old batteries. My problem here is that I just assume the impact of temperature is proportional to the full-capacity which takes the aging into account. Knowing how this really is would be cool so we could get the temperature impact modelled correctly in DT. >> 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 :( Right. By the way, I heard tha the TI has patent protecting some type of battery internal resistance usage here. OTOH, ROHM has patent over some of the VDROP value table stuff. Occasionally it feels like the ice is getting thinner at each step here. :/ Best Regards Matti Vaittinen -- The Linux Kernel guy at ROHM Semiconductors Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~ this year is the year of a signature writers block ~~
