Working on the battery issue... I think - New battery code based on BEHOLD II

angelluis73

Newbie

Cookies: 1
Posts: 12

Re: Working on the battery issue... I think

« Reply #15 on: December 30, 2009, 02:36:57 PM »

Numus, you get a cookie for that... Shocked


	Logged

numus

Pro Member

Cookies: 3
Posts: 279

Re: Working on the battery issue... I think

« Reply #16 on: December 30, 2009, 02:43:54 PM »

Quote from: angelluis73 on December 30, 2009, 02:36:57 PM

Numus, you get a cookie for that... Shocked

To simplify it..
If i am actually read this code correct (who knows.. i might be reading somethign that doesn't even have anything to do with it, but i am pretty sure this is why) The person who coded the battery portion of the moment decided that at 50% charge (what they deemed at batt_medium) that is at 3.74V should be reported as 15%.. meaning when our phones say 15%, they really mean 50%...

Now here is the kicker:
http://www.mpoweruk.com/performance.htm
You can see at the beginning there is a big decrease in voltage.. this is because a battery at full capacity has a voltage above nominal (nominal for lithium ion is 3.7).. then you will see this very long almost flat part.. that ist he nominal voltage (notice it is around 3.7).. The is how a battery discharges the majority of its energy.. Voltage doesn't change that much.. Then notice at the end a very steep dropoff..
Basically if you draw a line in th emiddle of that long flat part.. that is 50% usable capacity left.. Because of the way our battery meter was programmed.. that line would represent the 15% our phone displays..


« Last Edit: December 30, 2009, 02:49:29 PM by numus »	Logged

TBone

Jr. Member

Cookies: 2
Posts: 74

Re: Working on the battery issue... I think

« Reply #17 on: December 30, 2009, 03:07:17 PM »

Essentially yes, anything between 3.74V and 3.68V is deemed 15% according to the code. Anything between 3.68V and 3.63V gets 5%, and anything between 3.63V and 3.49V gets 3% while anything below 3.49V and dead (3.40V) gets 1%. According to the code, you drop from 30% directly down to 15%, and once you're at or below 15% they don't bother with the increments of 10 anymore.

BTW, Numus the following code:

Code:

if (!s3c_bat_info.bat_info.batt_is_full)
bat_level = 90;

actually says if the battery is not full. The exclamation point indicates not so essentially if s3c_bat_info.bat_info.batt_is_full = false, that's why they're setting the level to 90 in that scenario.

It's been a while since I had Physics or Chem, so thanks on the brushup of electricity! While it would be easy to change the code to reflect that MEDIUM (3.74V) is actually 50%. I've attached the file. According to numus, the values are:

Max to Full is 100-90%
Full to Almost full 90-80
Almost to High 80-70
High to medium 60-50
Med to low 50-15
(note there are no steps between medium and low.. like there are between max and medium (full, almost full, high p--probably need to add additional header items for 50/40, 40/30, 30/20)
Low to critical 15-5
critical to minimum 5-0

I commented out the original code and added the addiitonal code. I haven't compiled this, although I'm assuming it will compile. I don't have Linux or a C compiler. Obviously we can't test this either, so who knows what effect this will have on your phone. Use at your own risk if someone can compile it into the kernel.

s3c6410_battery.c (60.14 KB - downloaded 9 times.)
	Logged

zefie

Pro Member

Cookies: 29
Posts: 458

Re: Working on the battery issue... I think

« Reply #18 on: December 30, 2009, 03:10:38 PM »

header file

Will await modifications to both in a zip before testing on ZE05

s3c6410_battery.h (3.62 KB - downloaded 12 times.)
	Logged

zefie

Pro Member

Cookies: 29
Posts: 458

Re: Working on the battery issue... I think

« Reply #19 on: December 30, 2009, 03:19:46 PM »

heh, looks like we already have spica code Shocked

Code:

#if defined(CONFIG_MACH_SPICA)
bat_vol = (((adc - 2170) * 10 / 7)/100)*100 + 3200;


	Logged

numus

Pro Member

Cookies: 3
Posts: 279

Re: Working on the battery issue... I think

« Reply #20 on: December 30, 2009, 03:21:03 PM »

Quote from: zefie on December 30, 2009, 03:10:38 PM

header file

Will await modifications to both in a zip before testing on ZE05

The header wont need modifications UNTIL we can determine numbers for between 50% and say 20%.. IDK when i will get a chance to even look for data to reflect this (unless someone else has a calibrated decay curve that their phone produced that would make this very easy)..
Pending there were no changes to the 5-0% this probably has no chance of screwing up your phone (i havent seen anything that really uses these numbers to reference anything important) but it is an AT YOUR OWN RISK...
Zefie if you are feeling brave i would compile both of those and try it out.. the only thing that changed was the reporting numbers


	Logged

zefie

Pro Member

Cookies: 29
Posts: 458

Re: Working on the battery issue... I think

« Reply #21 on: December 30, 2009, 03:28:17 PM »

Quote from: numus on December 30, 2009, 03:21:03 PM

Quote from: zefie on December 30, 2009, 03:10:38 PM

header file

Will await modifications to both in a zip before testing on ZE05

50% to 15% darn they really didnt have any granularity huh.


	Logged

numus

Pro Member

Cookies: 3
Posts: 279

Re: Working on the battery issue... I think

« Reply #22 on: December 30, 2009, 04:11:58 PM »

Zefie that would be the quick dirty patch that would be easy to implement..
TBONE i got another project if you are interested..
I just ploted points based upon the headerfile to create a darn near linear expression.. so it would be possible to report values as actual numbers instead of intergers of 10..
Based upon the header data i used
Batt_Almost_full as 90
BATT_High as 70
Batt_med as 50
Batt_Low as 30
Batt_Critical as 10
plotted and then adding the trendline i get y = 298.99x-1070.6 with an r^2 value of 0.9717 (R^2 = 1 means the line perfectly fits the points)... The best part is this line almost goes through point 50 at 3.74 meaning it atleast has a pretty good accuracy at halfway.. So basically at >Batt_Almost_Full = 100 then between Batt_Almost_full and Batt_Critical we could use a linear decay express to get the battery percentage.. then at >Batt_Critical we use what is already there.... I don't think 15% will be a problem since i believe the screen dimming and everything else is independent of this batt_lev

What do you think?


« Last Edit: December 30, 2009, 04:35:22 PM by numus »	Logged

zefie

Pro Member

Cookies: 29
Posts: 458

Re: Working on the battery issue... I think

« Reply #23 on: December 30, 2009, 04:21:22 PM »

Quote from: numus on December 30, 2009, 04:11:58 PM

Zefie that would be the quick dirty patch that would be easy to implement..
TBONE i got another project if you are interested..
I just ploted points based upon the headerfile to create a darn near linear expression.. so it would be possible to report values as actual numbers instead of intergers of 10..
Based upon the header data i used
Batt_Almost_full as 90
BATT_High as 70
Batt_med as 50
Batt_Low as 30
Batt_Critical as 10
plotted and then adding the trendline i get y = .0032x+3.5855 with an r^2 value of 0.9717 (R^2 = 1 means the line perfectly fits the points)... The best part is this line almost goes through point 50 at 3.74 meaning it atleast has a pretty good accuracy at halfway.. So basically at >Batt_Almost_Full = 100 then between Batt_Almost_full and Batt_Critical we could use a linear decay express to get the battery percentage.. then at >Batt_Critical we use what is already there.... I don't think 15% will be a problem since i believe the screen dimming and everything else is independent of this batt_lev

What do you think?

full spectrum of numbers with accuracy would rule xDD


	Logged

numus

Pro Member

Cookies: 3
Posts: 279

Re: Working on the battery issue... I think

« Reply #24 on: December 30, 2009, 04:24:05 PM »

Quote from: zefie on December 30, 2009, 04:21:22 PM

Quote from: numus on December 30, 2009, 04:11:58 PM

Zefie that would be the quick dirty patch that would be easy to implement..
TBONE i got another project if you are interested..
I just ploted points based upon the headerfile to create a darn near linear expression.. so it would be possible to report values as actual numbers instead of intergers of 10..
Based upon the header data i used
Batt_Almost_full as 90
BATT_High as 70
Batt_med as 50
Batt_Low as 30
Batt_Critical as 10
plotted and then adding the trendline i get y = 298.99-1070.6 with an r^2 value of 0.9717 (R^2 = 1 means the line perfectly fits the points)... The best part is this line almost goes through point 50 at 3.74 meaning it atleast has a pretty good accuracy at halfway.. So basically at >Batt_Almost_Full = 100 then between Batt_Almost_full and Batt_Critical we could use a linear decay express to get the battery percentage.. then at >Batt_Critical we use what is already there.... I don't think 15% will be a problem since i believe the screen dimming and everything else is independent of this batt_lev

What do you think?

full spectrum of numbers with accuracy would rule xDD

Full spectrum from 90-10.. possibility
Accuracy... Ehh.. depends on how close you want it..
Zef did you try the battery patch tbone did to see if it works?

Upon thinking.. i think it would be possible to do the >90 accuracy part.. but think leaving the <10 alone as-is since that is where things get iffy
For >90 we can do
>=Batt_Full 100 no matter what.. the means between BATT_MAXIMUM and BATT_FULL it will read 100..
Then y=71.429x-188.57 where x = voltage and y = percent avalible

CORRECTION TO THE FIRST EQUATION
y=298.99x-1070.6 The first time i plotted it i put voltage as Y and percentage as X on accident.. fixed it so voltage is X and percentage is Y

BTW this could break the crap out of the battery meter.. havent even begun to look to see if it references bat_lev that is outputted by the original script or if it does it on its own.. I am guess this would show 2 digital percentages in openhome and all other battery monitors/meters tho


« Last Edit: December 30, 2009, 04:40:54 PM by numus »	Logged

TBone

Jr. Member

Cookies: 2
Posts: 74

Re: Working on the battery issue... I think

« Reply #25 on: December 30, 2009, 04:56:34 PM »

According to your latest equation, here are the values I got which seem off according to the initial header data.

Percent	Voltage	Header Voltage
100	3.915181	4.04
90	3.881735	4.00 - 4.04
80	3.848289	3.90 - 4.00
70	3.814843	3.79 - 3.90
60	3.781397	3.74 - 3.79
50	3,646851	3.68 - 3.74
40	3.714506	N/A
30	3.68106	N/A
20	3.647614	N/A

is that what you want?

Zefie, don't add the code yet, I just noticed there are a couple more instances of code we need to modify. There are a few methods that set the battery level.


	Logged

numus

Pro Member

Cookies: 3
Posts: 279

Re: Working on the battery issue... I think

« Reply #26 on: December 30, 2009, 05:09:55 PM »

Quote from: TBone on December 30, 2009, 04:56:34 PM

According to your latest equation, here are the values I got which seem off according to the initial header data.

Percent	Voltage	Header Voltage
100	3.915181	4.04
90	3.881735	4.00 - 4.04
80	3.848289	3.90 - 4.00
70	3.814843	3.79 - 3.90
60	3.781397	3.74 - 3.79
50	3,646851	3.68 - 3.74
40	3.714506	N/A
30	3.68106	N/A
20	3.647614	N/A

is that what you want?

Zefie, don't add the code yet, I just noticed there are a couple more instances of code we need to modify. There are a few methods that set the battery level.

The equation isn't an exact linear expression.. Hense an r^2 value less then 1.. basically i derived an equation based on a curve... I was attempting to find a way to express the values as integers of 1 instead of integers of 10..
Like i said previously.. they are going to be off but it is still better then what we currently have.. the problem is
#define BATT_MAXIMUM      59   /* 4.19V */
#define BATT_FULL      46   /* 4.04V */
#define BATT_SAFE_RECHARGE   43   /* 4.00V */
#define BATT_ALMOST_FULL   34   /* 3.90V */
#define BATT_HIGH      24   /* 3.79V */
#define BATT_MED      20   /* 3.74V */
#define BATT_LOW      15   /* 3.68V */
#define BATT_CRITICAL      10   /* 3.63V */
#define BATT_MINIMUM      (-2)   /* 3.49V */
#define BATT_OFF      (-8)   /* 3.40V */
I have no idea what they used to determine those numbers that represent the voltages (59,46,43,34,24,20,15,10) in order to create new states between 50-15 so we didnt have such a sudden drop off

the 60-40 range should be the closest to the accurate values since i took the derivative close to the center (figured it was the most accurate way)... Was just trying to figure out a way to get a more "Accurate" percentage..

TBONE: Make sure you dont mess with the parts in the ADC Charging portion.. Those are important as they are i believe

Quote from: zefie on December 30, 2009, 03:19:46 PM

heh, looks like we already have spica code Shocked

Code:

#if defined(CONFIG_MACH_SPICA)
bat_vol = (((adc - 2170) * 10 / 7)/100)*100 + 3200;

WTF IS THAT?!?
I can't even begin to attempt to figure out what they are trying to calculate.. consider they have ((())/100)*100 which is redundant cause they cancel each other out


« Last Edit: December 30, 2009, 05:28:21 PM by numus »	Logged

zefie

Pro Member

Cookies: 29
Posts: 458

Re: Working on the battery issue... I think

« Reply #27 on: December 30, 2009, 05:38:09 PM »

tbone's patch works great.


	Logged

numus

Pro Member

Cookies: 3
Posts: 279

Re: Working on the battery issue... I think

« Reply #28 on: December 30, 2009, 05:39:52 PM »

Quote from: zefie on December 30, 2009, 05:38:09 PM

tbone's patch works great.

Good.. push out the release so i can get it

Don't feel like installing ubuntu on my server right now


	Logged

TBone

Jr. Member

Cookies: 2
Posts: 74

Re: Working on the battery issue... I think

« Reply #29 on: December 30, 2009, 05:42:19 PM »

So, here's what I'm going to do as long as I get the master of electricity (numus) to tell me it looks ok. These values should spit out an exponential curve and give us more accuracy toward the bottom of the spectrum.

   100% = 4.04V
   90% = 3.97V - 4.04V
   80% = 3.90V - 3.97V
   70% = 3.85V - 3.90V
   60% = 3.79V - 3.85V
   50% = 3.74V - 3.79V
   40% = 3.70V - 3.74V
   30% = 3.66V - 3.70V
   20% = 3.63V - 3.66V
   10% = 3.58V - 3.63V
   5% = 3.49V - 3.58V
   1% = 3.40V - 3.49V

Numus, I noticed additional s3c_get_bat_level methods below the one I changed. Lines 572 - 679 have another method. Is that one not to muck with? I would believe this needs it as well?


	Logged

Pages: 1 [2] 3 4 ... 7

« previous next »

News: Do you like Samsung Moment?
Scratch-Proof your Samsung Moment Best Price on Sprint Phones Screen Protection	Latest Ringtone for your mobile