lkml.org 
[lkml]   [2021]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH v3 3/9] power: supply: Support DT originated temperature-capacity tables
Date
Hi dee Ho again,

On 11/18/21 08:11, Matti Vaittinen wrote:
> Hi Linus,
>
> On 11/18/21 04:10, Linus Walleij wrote:
>> On Tue, Nov 16, 2021 at 1:26 PM Matti Vaittinen
>> <matti.vaittinen@fi.rohmeurope.com> wrote:
>>
>>> Support obtaining the "capacity degradation by temperature" - tables
>>> from device-tree to batinfo.
>>>
>>> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
>>
>> Same questions as on the binding patch.
>>
>> If we already support different degradation by temperature tables,
>> why do we need a second mechanism for the same thing?
>
> Thanks for bringing this up. As I said, I didn't notice that we could
> indeed use the CAP-OCV tables for different temperatures to bring in
> this information :) I see certain benefit from the possibility of not
> requiring to measure the OCV at different temperatures - but it may not
> be meaningful. As I replied to your patch 1/9 review - I need to (try
> to) do some more research...

I tried doing some pondering here today. Unfortunately, the Friday
afternoon is probably the worst time to try this - my brains cease
operating at the afternoon - and double so at the Friday. Friday
afternoons are good for babbling via email though ;)

I don't see providing OCV tables at different temperature gives the
degradation of battery capacity. Whoah. A big thought for Friday.

We get the OCV => SOC correspondance at different temperatures. 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.

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.

(Explanation done at Friday afternoon accuracy here).

>> 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() )

Yours
--Matti

--
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 ~~
\
 
 \ /
  Last update: 2021-11-26 13:03    [W:0.263 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site