Battery Meter and Temp reading "Fix" (workaround) (6/22 Update)

[Unknownforce]

Originally Posted by obrienmd

Unknown - looks like it's working, can you update to latest zImage? Do you turn off debug, like the balsat.hopto.org zImages? These non-debug kernels improve speed for me.

I haven't changed anything in my builds other than what I specified already, so unless it's disabled by default, then no it's not off. I can look into turning it off, but right now, I don't have the time. I at least updated to the latest zImage for now.

[sovereignty03]

Originally Posted by Unknownforce

Just thought I'd share this here...

First and Foremost. This is NOT supported by the Devs... NOR am I a Dev... This is simply a modification of the code that generates the zImage file. (specifically the file htc_battery_smem.c)

Secondly... This has ONLY been tested on MY OWN Sprint Touch Pro 2... I cannot guarantee it will work on ANY other device including other sprint tp2's.. I just know that it works on MY device... so I figured I'd share it...

Thirdly... It's not dead accurate, it's using some of the calculations from the raphael's battery calculations... I have been told by one of the devs that the rhodium calculates battery life much differently, so I will say that this isn't supposed to be a REAL fix, just a temporary workaround.

OK, now that all that is out of the way... here's somewhat of a "fix" for the Battery meter for the SPRINT CDMA TP2 RHODIUM (At least that's all I've tested it on)

It's the same zImage as all the others with just a single modified source file compiled in. So all you have to do is copy it over the zImage file you currently have and run android like normal.

The zImage includes all zImage updates including the one from today ( 5/29/10 )

Here's the link:

http://www.mediafire.com/?sharekey=2...ecd7d091ba63d2

Where does one get the source htc_battery_smem.c for the calculations? Where is it located in the tree while in android? I was curious about the calculations to see where the accuracy problem is. Does it have to do with temperature compensation? That right there would probably be different than the Raphael... I am using the latest stuff from Reefermattness along with your workaround and it is working so far, just not accurate.

Using Tilt2...

EDIT: Just tried a find in Terminal Emulator and didn't get a result

[Unknownforce]

Originally Posted by bhuggins

Where does one get the source htc_battery_smem.c for the calculations? Where is it located in the tree while in android? I was curious about the calculations to see where the accuracy problem is. Does it have to do with temperature compensation? That right there would probably be different than the Raphael... I am using the latest stuff from Reefermattness along with your workaround and it is working so far, just not accurate.

Using Tilt2...

EDIT: Just tried a find in Terminal Emulator and didn't get a result

The source is here: http://gitorious.org/linux-on-qualco...battery_smem.c

What I changed is the static int function called htc_rhod_batt_corr here: http://pastie.org/989450

All I really did was use a little common sense, when the topaz fix was released, I looked at the code that was changed, and basically just did a little testing. I set it to think that it was a topaz, which made the battery report 100 all the time, Then I noticed that the mV readings were way off, so I just adjusted the numbers to get it to show that number to be a little closer to accurate, and in doing this, I discovered that the battery level would also show somewhat close to accurate because apparently the current code seems to directly relate the two (battery % and mV readings) As such, when you plug your phone in, the %age jumps WAY up because the mV readings increase dramatically. I've been thinking about writing some kind of stabilization code to lower the % reading based on status of charging and the increase in mV readings to help stabilize the %age number, but it's been so long since I've done any type of these kinds of Mathematics, I have to do much testing in order to get a proper table in which to write some formula to correctly stabilize it...

Something like if charging = 1 and mV = a certain range, than adjust the % reading to xyz.. But this would only be a "workaround" for another workaround. what we really need are the exact calculations from the battery driver itself. I'm slowly learning ARM ASM to accomplish this, but I've been working 2 jobs, so when I get in the "groove" so-to-speak, it gets interrupted and I have to re-start my train of thought from the beginning... it's very frustrating...

[sovereignty03]

Originally Posted by Unknownforce

The source is here: http://gitorious.org/linux-on-qualco...battery_smem.c

What I changed is the static int function called htc_rhod_batt_corr here: http://pastie.org/989450

All I really did was use a little common sense, when the topaz fix was released, I looked at the code that was changed, and basically just did a little testing. I set it to think that it was a topaz, which made the battery report 100 all the time, Then I noticed that the mV readings were way off, so I just adjusted the numbers to get it to show that number to be a little closer to accurate, and in doing this, I discovered that the battery level would also show somewhat close to accurate because apparently the current code seems to directly relate the two (battery % and mV readings) As such, when you plug your phone in, the %age jumps WAY up because the mV readings increase dramatically. I've been thinking about writing some kind of stabilization code to lower the % reading based on status of charging and the increase in mV readings to help stabilize the %age number, but it's been so long since I've done any type of these kinds of Mathematics, I have to do much testing in order to get a proper table in which to write some formula to correctly stabilize it...

Something like if charging = 1 and mV = a certain range, than adjust the % reading to xyz.. But this would only be a "workaround" for another workaround. what we really need are the exact calculations from the battery driver itself. I'm slowly learning ARM ASM to accomplish this, but I've been working 2 jobs, so when I get in the "groove" so-to-speak, it gets interrupted and I have to re-start my train of thought from the beginning... it's very frustrating...

Did you do any tweaking in the function "GetBatteryDischargeLevel"? It looks like this is where the accuracy might be corrected...still looking through the code, though

[Unknownforce]

I changed nothing else other than the function I mentioned.

[Unknownforce]

Updated today with a charging meter reading "fix." Same link, see first post for details and explanation.

[sovereignty03]

Originally Posted by Unknownforce

Updated today with a charging meter reading "fix." Same link, see first post for details and explanation.

Hey man, I've been looking into the source, but haven't had time to set my system up to compile and test on my phone. If you don't mind, please try this: Look in htc_battery_smem.c for the line that reads "If ( av_index > 1347 )". Try changing that to "If ( av_index > 1500 )". The next line needs to be changed from "av_index = 1347" to "av_index = 1500". Just see what it does. The Raphael has a 1340mAh battery and the Rhodium has a 1500mAh battery. This is only a start as I see there also needs to be some changes in the scaling. When I have a chance, I am going to try to figure out some of the mV values that need to be put into "GetBatteryDischargeLevel". Just for test on the Rhodium, those values can be changed, but it will break the Raphael side. If the values are found to be good, then there needs to be some other stuff done to add the extra batt_vendor...

I'm gonna try your new stuff ASAP...

EDIT: later realized this is not what av_index is for...

[sovereignty03]

Oh, and sorry about the name change. I was bhuggins. I didn't want that showing so I asked the admins to change it to what I usually use, which is sovereignty

[dunebuggydude11]

what is the "1.0" file for? it says it is a "0 File (.0)" is it supposed to be the modules.....file? thx

[samjer111]

Thanks man. Keep up the Great work.