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

[NeoMatrixJR]

unknownforce, are you going to get these changes into the xdanadroid dev tree so we can see this on the regular builds?

[Unknownforce]

Originally Posted by NeoMatrixJR

unknownforce, are you going to get these changes into the xdanadroid dev tree so we can see this on the regular builds?

I can offer it to them, but it's up to them if they want to include it or not... I can't commit the changes myself as I'm not a dev. And as I said before one of the Dev's that I spoke with when I first started looking at this said that using the Raph's Battery calculations was not correct... So I'm not sure that they would commit the changes.

[ylopez2007]

I copy the zImage over the zImage file that I currently have but there was no change. It keeps indicating that the battery is at 5% even though it says 60% in Windows Mobile.

[sovereignty03]

Originally Posted by ylopez2007

I copy the zImage over the zImage file that I currently have but there was no change. It keeps indicating that the battery is at 5% even though it says 60% in Windows Mobile.

You have to copy the module file also....

And either rename your old module file to not have "module" prefix or just delete it

[surge]

Unknownforce,

Have you looked at Post #37 by sovereignty03?

He lists something to try which looks like it may give more accurate readings since the calculations you are using appear to be from a phone with lower capacity.

[Unknownforce]

Originally Posted by surge

Unknownforce,

Have you looked at Post #37 by sovereignty03?

He lists something to try which looks like it may give more accurate readings since the calculations you are using appear to be from a phone with lower capacity.

av_index is used for identifying the proper temperature being pulled from the temperature array listed in htc_battery_smem.h, There are 1347 entries in that array. This is why it says if the av_index is higher than this, than it would cause the battery to freeze because it's trying to pull a value beyond the size of the array.

It has no correlation to the battery capacity.

Trust me if it were that easy, the Devs would have already had it working long ago.

The calculations I am using are very close, but they are just not as accurate as they should be. And there ARE no calculations that keep the battery level STABLE under different discharge/load levels at the current time. In just what little I have gathered from my limited disassembly of the battery.dll, it looks like there are 2 different ways it calculates the battery based on whether or not it's discharging or charging, (which is kind of what I have done in the 6/4 update) and then inside that there's multiple battery percentages it stores... One is a "stabilized" reading, another is a "immediate" reading, and another I believe is used in the stabilizing process, most likely a "previous" percentage used to "average" the battery level... So probably the only thing left to do on this is to just stabilize the load to percentage ratio and give it a condition to NEVER go up in percentage if it's NOT charging. But the current code doesn't seem to take load into consideration very well.

[drewcam888]

Should I be deleting the old module.gz from my phone? Or do I just copy the attached modules file?

[demonlordoftheround]

Wirelessly posted (Mozilla/5.0 (Linux; U; Android 2.1; en-gb; HTC Legend Build/ERD79) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17)

Originally Posted by drewcam888

Should I be deleting the old module.gz from my phone? Or do I just copy the attached modules file?

I put my old zimage and modules files into the my documents folder for saafe keeping in case I wanted to to go back. But this battery fix works pretty good.

[sovereignty03]

Originally Posted by Unknownforce

av_index is used for identifying the proper temperature being pulled from the temperature array listed in htc_battery_smem.h, There are 1347 entries in that array. This is why it says if the av_index is higher than this, than it would cause the battery to freeze because it's trying to pull a value beyond the size of the array.

It has no correlation to the battery capacity.

Trust me if it were that easy, the Devs would have already had it working long ago.

The calculations I am using are very close, but they are just not as accurate as they should be. And there ARE no calculations that keep the battery level STABLE under different discharge/load levels at the current time. In just what little I have gathered from my limited disassembly of the battery.dll, it looks like there are 2 different ways it calculates the battery based on whether or not it's discharging or charging, (which is kind of what I have done in the 6/4 update) and then inside that there's multiple battery percentages it stores... One is a "stabilized" reading, another is a "immediate" reading, and another I believe is used in the stabilizing process, most likely a "previous" percentage used to "average" the battery level... So probably the only thing left to do on this is to just stabilize the load to percentage ratio and give it a condition to NEVER go up in percentage if it's NOT charging. But the current code doesn't seem to take load into consideration very well.

Sorry...never updated my post. I realized what av_index is after looking into the code some more. You know, you are trying to do something about the increase while charging, but most devices I have used just display some type of animation while charging and then display the percentage again when it is unplugged.

About keeping stable under varying loads, There is a solution that uses the output impedance of the battery. I am in the (slow) process of compiling the data to plot a curve for the output resistance as a factor of battery temperature. If one knows this curve it is painless to calculate the correct percentage of charge. I'll share it with you when I get it done. I haven't had much time to dedicate to it yet...

[Unknownforce]

Originally Posted by sovereignty03

Sorry...never updated my post. I realized what av_index is after looking into the code some more. You know, you are trying to do something about the increase while charging, but most devices I have used just display some type of animation while charging and then display the percentage again when it is unplugged.

Sure, it just shows the animation, but when you go into the spare parts and look at the battery percentage (without my latest release) it's at least 40% higher than it should be... This is why I manipulated the code to forcibly bring that number lower. Because of this, you can charge it a lot more accurately while charging with android. I set it to be a FEW percent higher than the reading android has while on discharge, so that it will hit 100% when it's more like 95-97 and, if the code is correct, STOP charging at that percent and not fry the battery or something.

WITHOUT this fix, it would ready 100% when it's more like 50-60% and not charge beyond that because it thinks it's are 100% because of the extreme increase in the voltage reading while on the charger.

Originally Posted by sovereignty03

About keeping stable under varying loads, There is a solution that uses the output impedance of the battery. I am in the (slow) process of compiling the data to plot a curve for the output resistance as a factor of battery temperature. If one knows this curve it is painless to calculate the correct percentage of charge. I'll share it with you when I get it done. I haven't had much time to dedicate to it yet...

The problem here is that I don't think it's reading the proper discharge values as WinMo does... WinMo I believe pulls the mA that's currently being discharged and uses it in it's calculations among the temp and voltage readings, now that COULD be calculated FROM the temp and voltage readings, but again, I don't know... I still haven't had much time to do much with the dll file and see exactly what's going on... and with my limited knowledge of ARM ASM... it's going to take quite some time... which is why I'm only guessing at numbers for now to at least get it CLOSE to what it should be reading.