Re: [RFC PATCH v3 3/9] power: supply: Support DT originated temperature-capacity tables

[Vaittinen, Matti]

Morning Linus & All,

First of all - thanks. I've no words to say how much I do appreciate 
this discussion. (There was zero sarcasm - I don't get much of 
discussion on these topics elsewhere...)

On 11/27/21 02:54, Linus Walleij wrote:
> Hi Matti,
> 
> don't worry you are probably right. You are the domain expert working
> on stuff like this inside a company that actually makes charger ICs.
> I am just some guy on the street. So I certainly trust you on this.

Please don't XD

I am working in a company which does pretty much _all_ frigging 
components from simple resistors to some CPU cores. There are PMICs, 
chargers, touch screens, SERDES, audio ICs - pretty much every 
semiconductor IC one can think of.

What comes to me - I have _very_ limited knowledge on any of these. I 
just do the drivers for whatever component they need one for. And for 
that purpose I do some research and a lot of "guesswork" - almost as if 
I was just a random guy on the street ;) I do _rarely_ have any proper 
documentation about how things are supposed to work - and if I do, I 
know how things are supposed to work at hardware-level, not how software 
should be orchestrating things :/

This discussion with guys like you helps _a lot_ regarding all the 
guesswork :)

> 
> On Fri, Nov 26, 2021 at 12:56 PM Vaittinen, Matti
> <Matti.Vaittinen@xxxxxxxxxxxxxxxxx> wrote:
> 
>> I don't see providing OCV tables at different temperature gives the
>> degradation of battery capacity. Whoah. A big thought for Friday.
> 
> I think we are getting close to academic definitions of the problem,
> so we'd need input from people who actually work on charging and
> knows how this works? Or we need to read up on it :/

Studying is hard work. I am so glad I get to chat with someone who has 
obviously done some of it ;) And just to stress the point - that someone 
is You :]

>> We get the OCV => SOC correspondance at different temperatures.
> 
> I read
> OCV = Open Circuit Voltage (which we can't measure but must calculate)

Me too. Although we can measure this when designing the system in order 
to extract those OCV tables, right?

> and
> SOC = State of Charge (a percentage of the capacity)

Yes.

> And we agree what the bindings and code gives today is
> (temp, OCV) -> SoC (%)
> 
> And this assumption is:
> 
> A) wrong as in the earth is flat or it makes the same sens to
>     take a random number and use as capacity
> 
> B) wrong as in not good enough and a bit rough around the
>     edges and you have an idea how to improve it > I assume (B) and what we are seeing on the battery indicator on
> most of the worlds mobile phones etc is sometimes a bit so-so
> because they have only used the above. (I think some people can
> attest to experiencing this problem.) >
> And now we want something better, think medical equipment.

I'd vothe the (B) too.

In theory the OCV => SOC is correct. (Part of the) Problem is that we 
can't measure the OCV reliably/accurately when system is running 
(because there is load connected). Also, there is probably some change 
here caused by battery aging. So for proper state-of-charge information 
we can't rely the OCV only. (This is where the coulomb counter comes 
in). Furthermore, I would not say it is medical only. I think that even 
the consumer electronics can benefit (a lot) from any accuracy 
improvement we can provide. I guess the improved accuracy can prolong 
the battery life and help avoiding unnecessary charging.

>> I
>> however don't see how this gives the OCV => energy relation. As far as I
>> know both the OCV and the 'amount of uAhs battery is able to store' are
>> impacted by temperature change. This means, seeing the OCV => SOC at
>> different temperatures does not tell us what is the impact of
>> temperature to the OCV, and what is the impact to SOC.
> 
> It is definitely true that both the OCV and SOC changes according to
> temperature.
> 
> But it is also true that these tables for a certain temperature are written
> with an OCV measured at this temperature, so the OCV used in the
> table is already compensated for the temperature, right?

Yes. OCV is fitted but we typically don't have the accurate OCV at all 
times. This meand that we need to use the coulomb-counter value - which 
makes it mandatory for us to find out the absolute capacity at given 
temperature.

>> For cases like the ROHM Chargers, we are interested on how much has the
>> 'ability to store uAhs' changed due to the temperature. When we know the
>> amount of uAhs we can store, we can use the coulomb counter value to
>> estimate what we still have left in the battery.
>>
>> In addition to this we do use the OCV information for the "nearly
>> depleted battery" - to improve the estimation by zero-correction
>> algorithm. I must admit Friday afternoon is not the time I can quite
>> recap this part. I think it was something like:
>>
>> 1. Measure VBat with system load (VBAT)
>> 2. Find OCV corresponding the current SOC estimate (SOC based on coulomb
>> counter value) - OCV_NOW
>> 3. Compute VDROP caused by the load (OCV_NOW - VBAT)
>> 4. Assume VDROP stays constant (or use ROHM VDR parameters if provided)
>> 5. Using VDROP compute the OCV_MIN which matches the minimum battery
>> voltage where system is still operational
>> 6. Use the OCV_MIN and "OCV at SOC0 from calibration data" difference to
>> adjust the battery capacity.
> 
> That's a neat trick!
> If you look at drivers/power/supply/ab8500_fg.c function
> ab8500_fg_load_comp_volt_to_capacity() you find how
> someone else chose to do this with a bit of averaging etc.

Thanks for the pointer. I haven't read that yet but I will do. Although, 
I'll probably postpone that reading to the next week.

> 
>>>> I'd just calculate a few tables per temperature and be done with
>>>> it.
>>>>
>>>> At least documentation needs to be updated to reflect that the two
>>>> methods
>>>> are exclusive and you can only use one of them.
>>
>> I don't see these exclusive (at Friday afternoon at least). I think they
>> can complement each-others. The temp_degradation table gives us the
>> temperature impact on <energy storing ability>, eg, how much the battery
>> capacity has changed from designed one due to the temperature.
>>
>> OCV-SOC tables at various temperatures tell us how OCV looks like when
>> we have X% of battery left at different temperatures. Estimation of how
>> much the X% is in absolute uAhs can be done by taking into account the
>> designed_cap, aging degradation and the temperature degradation (and the
>> position of moon, amount of muons created by cosmic rays hitting
>> athmosphere at knee energy region and so on...)
>>
>> Or am I just getting something terribly wrong (again)? :)
>> (I still for example like internal functions named as __foo() )
> 
> OK so yeah I think you are at something here. Which is generic.
> 
> The battery indicator in my Tesla in Swedish winter times looks
> like this:

Oh, you're driving Tesla. I've wondered how do they work at winter time? 
At the Oulu Finland we can also have quite freezing cold winters so I 
wouldn't dare to buy Tesla (even if they weren't quite that expensive). 
I must admit that I do like the acceleration though. Well, on that front 
my old motorbike must suffice and for me my car is purely for 
transportation and not for run :/

> 
> +-------------------+---+
> |       25%         | * |
> +-------------------+---+
> 
> So the star * indicates some extra capacity that is taken away
> because of the low temperature.
> 
> This must be because the system is aware about the impact on
> the battery available uAh of the temperature. As you use the
> battery it will get warmer and the capacity will increase and the
> little star goes away.

Getting back to the topic - I think this is a good example. Coulomb 
counter can tell us the amoount of uAh we have drawn from the battery 
(with the drawback of for example the ADC offset causing drifting).

The temperature-degradation tables (and some figures explaining the 
impact of aging) can tell us how much absolute capacity we have lost 
(the star thingee) - some of which can be recovered when battery is 
warming - and finally we do get the SOC in %.

> Current random mobile phones are not this great and do not
> estimate the capacity fall because of the temperature, just shows
> a percentage of the full capacity at the temperature right now
> whatever that capacity may be, so it is a relative scale and we
> can never show anything as nice as what the Tesla does with
> this.

Yes. What I was after here is using the temperature-corrected capacity 
as a base of computing the relative SOC. I don't think we should tell 
user the battery is only half-full when it actually can't hold more 
charge in cold weather (due to reduced capacity) - because this 
instructs people to start charging.

OTOH, I do _really_ like your Tesla example of telling the user that 
even though your battery is as full as it can, it does not mean it lasts 
the same <XX> hours it usually does when you are indoors. I am pretty 
sure the current power-supply framework allows us to expose the current 
full_cap to userlans - so building your Tesla example with the star 
should be doable - if the drivers can somehow get the information about 
the absolute capacity drop.


> Then the question is: is the method used by Rohm universal and
> well-known and something many chargers will do exactly this
> way, so it should be in the core, or is it a particularity that should
> be in your driver?

I am not sure this is the correct question. I'd rephrase it to: Would it 
be beneficial for drivers to come if the core did support this 
functionality - or is the feature unnecessary, or are there better 
alternatives. If core does not provide the support - then it is a high 
mountain for one to climb if he wants to use such improvement.

I think that the agreement we can do is that the OCV+temperature => SOC 
tables do not provide quite same information as the suggested 
temperature => capacity-drop tables would. Whether there are better 
alternatives - or if this is generally useful remains to be discussed - 
and this is something where I _do_ appreciate your (and everyone else's) 
input!

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 ~~