[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