voltage_min_design

[dave-at-axon]

I found something strange today with my Android build.

In sys/class/power_supply/battery/voltage_min_design the value is 3400 which would be in mV

In sys/class/power_supply/battery/voltage_max_design the value is 4200000 and is in uV

In the code the 2 are subtracted from each other to get the range. I suspect this is the reason I am getting the wrong percentage calculated when on battery.

I can't seem to find where this file is written to.

Anyone else seen this?

[jess]

My guess is that 4V2 is the max voltage ever applied to LiPo and measured immediately after it stopped charging and corresponds to so called 100%.  The second one 3V4 is when the battery is fully depleted (i.e. zero percent) and we should start charging it to avoid voltage drop below the critical for LiPo voltage of 3V2. So the 100 percent span is 4.2 - 3.4 = 0.8

Again, it's only my guess. 

[JohnS]

Are they fake files that are populated by the kernel when opened and read?

John

[dave-at-axon]

Hi Jess, I understand what they are for but they are not in the same number format. One is in mV and the other is in uV.

I did find the point in the kernel where the value is retrieved and I have since updated this to *1000 and now the value in the voltage_min_design is 3400000 and in uV.

It still gives me strange readings. The battery voltage I can read with a meter and it is not the same as the kernel is storing.

@John. They are real values. If I cat voltage_now I get the voltage value of the battery in uV. It seems that something is amiss where it calculates the percentage and I am trying to find out where this is occurring. It does not correspond with the voltage reading. It's in the kernel as I found the Android code and it simply reads the sys/class/power_supply values.

[JohnS]

I was wondering where it got those from...

My suspicion is that the "files" are not ordinary files but are simulated files, akin to device files in /dev or the many files in /proc etc, so finding what goes on to make the files was what I meant.

I hoped the values would be accurate, however created!!

Are they not just read from the AXP209?  Maybe even a bug in its driver?

John