This thread is for those following the battery calibration thread that would like to help build tools to read and set some advanced battery values, and ultimately recalibrate in learning mode.
It takes its inspiration from this forum thread over at precentral :
http://forums.precentral.net/palm-pre/256967-find-out-how-good-bad-your-battery.html
See HOW-TO in post 3 below, or in-thread post from mtw4991, for instructions on using app to calibrate
reference material
battery manufacturer technical info
DS2784 data sheet - http://datasheets.maxim-ic.com/en/ds/DS2784.pdf
Storing Fuel Gauge Parameters in the DS2784 - http://pdfserv.maxim-ic.com/en/an/AN4043.pdf
Lithium-Ion Cell Fuel Gauging with Maxim Battery Monitor ICs - http://pdfserv.maxim-ic.com/en/an/AN131.pdf
code
cyanogenmod github repository / kanged HTC code - http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/power/ds2784_battery.c
HTC Desire - http://developer.htc.com/ (use HTC Desire kernel source code download)
edit 2010/11/17: source code for battery driver mods - http://github.com/thelogin/n1batcal/
edit 2010/12/15: source code for app -
app availability
available from the Android Marketplace
link: https://market.android.com/details?id=net.jonrichards.batterycalibrator.ui (thanks, McFroger3!)
reference info
thread at precentral which was the inspiration for this thread - http://forums.precentral.net/palm-pre/256967-find-out-how-good-bad-your-battery.html
spreadsheet of registers - https://spreadsheets.google.com/ccc...VNzdXpqWVdFejNGM1pLWmc&hl=en&authkey=CJ_ItagO
related apps
Dr. Battery on the Pre - http://discussion.treocentral.com/homebrew-apps/260947-dr-battery.html
specific code references
(with reference to the manufacturer battery info above)
1 - CONTROL REGISTER FORMAT - page 12 - UVEN—Undervoltage Enable
1 - CAPACITY ESTIMATION ALGORITHM - page 21 - Figure 3: Top-Level Algorithm Diagram
1 - page 24
from Active Empty Voltage (VAE) - includes Aging Capacity (AC) and Age Scalar (AS)
CAPACITY ESTIMATION OPERATION - Learn Function ("A continuous charge from empty to full results in a learn cycle." then "First, the active empty point must be detected."!!)
1 - page 25 - STATUS REGISTER FORMAT
(to be completed)
with thanks to RogerPodacter for his help in compiling this list
progress status and useable findings
status
we have made mods to the kernel code (based on 2.6.35.x) to
make any register writable
make the following registers readable: AGE, Vae (ACTIVE_EMPTY_VOLT), and Status Reg (STS)
allow read/write of these registers via virtual files
remove pseudo-extended battery charging
edit 2010/11/17: created a "dumpreg" file to show all registers and their current values
edit 2010/11/17:
work is being done on a GUI app with the following initial functionality:
show when learn mode is hit
save age when learn mode is complete
the following functionality may be in:
option to restore age when app launched
HOW-TO
mtw4991 said:
How to calibrate your battery using the Battery Calibrator App....
(original text: http://forum.xda-developers.com/showpost.php?p=9583271&postcount=340)
1. Use the battery calibrator app v.1.3.0 to do the following:
a. Open the app and go to menu>settings and check all boxes. Auto-on airplane mode is optional
b. set your age to 100 using the battery app under the Learn Prep tab and press Save
c. set your full40 to 1452mAh in the same tab if using the stock capacity OEM battery and press Save
NOTE: set your full40 to 1650mAh or higher if using an aftermarket battery and save
2. In the Learn Prep tab:
a. set your aEvolts to 3201 (type on each line: Register:0x 66 Value: a4 and press save)
b. set your stop charging current to <20mA (Register:0x 65 Value: 06 and press save)
c. if Capacity/mAh drops to near empty prior to 3201mV being reached, the app will automatically raise capacity by 200mAh so phone doesn't auto-shutdown prior to reaching 3201mV
3. Achieving Learn Mode with the app:
a. turn learn mode on in Learn Mode tab
NOTE: to hit learn mode you must keep your current mA above -200mA draw at the empty point! The app will automatically enable GPS polling to keep you above the required minimum current draw.
b. wait for mV to drop to 3201mV (the learn mode pop-up box will appear & learnf button will light up)
c. insert charger IMMEDIATELY! (You will see a pop-up message saying Learn Mode is active.)
d. turn off and close any open apps you have running, but leave Battery Calibrator open.
e. put phone into airplane mode so that you don’t get unexpected current draw near the full point.
f. set SetCPU profile to disable overclocking. (set min/max to the same value, ie. 998\998max)
g. charge for a full 4 hrs with stock battery and screen off, 5 hrs for larger capacity batterys.
NOTE: if you want to, you can actually use your phone until the charge reaches 80-90%, then use airplane mode and DO NOT touch the phone, peek, turn on the screen....DO NOTHING but walk away til time is up.
h. unplug and reboot, your new age should be set automatically. Learn is now complete and your phone should now charge to 100% and die at 0-1%. Also, some have reported having to manually power down/power up with the new app to have age reset by the application. If age isn’t change upon reboot, try power off/power on.
4. Learn Failure:
If your new age shows 94% upon rebooting, then learn mode failed and you need to do it again, paying close attention as charging nears 80% and above. This is where learn mode can be lost by rogue apps, auto-updates, calls, etc pulling the current down below the minimum prematurely.
Note1: As current gets close to <50-60mA don't touch the phone or you may artifically increase the current draw pulling it below 20mA and it will end the learn cycle prematurely. Airplane mode helps prevent that.
Note2: Learn mode cannot be achieve with the phone off. Leave the phone on until learn is complete and the battery status register shows 0x81. Done!
How to perform a Capacity Test for your battery. Credit goes to the infamous Temasek!
Prepare for another learn cycle
This time we will do what I call a capacity test.
Perform another learn cycle.
Once cycle completed do not reboot. Check your battery log using an app like OS Monitor. See your highest achieved capacity at 99-100% before it completed its charge. The capacity should drop below your full40. Read the log properly. The highest achieved capacity before it drop below your full40 will be your new full40 value.
With your new full40 value, perform yet another learn cycle.
Enjoy your new calibrated battery!
Click to expand...
Click to collapse
HOW-TO2:
http://forum.xda-developers.com/showpost.php?p=24599586&postcount=284 (as requested by St4hli)
Initial investigation and analysis
OK, so I'm going to try and use the following repositories in github and in this order:
AOSP > pershoot > CyanogenMod > others
as I'd like it as generic as possible and ideally integrate any patches at the highest level.
Not being an expert in github, you'll have to excuse any obvious noobness! I couldn't see any of the 2784 battery stuff in AOSP so I'm guessing the CM team used the Desire kernel source from developer.htc.com to integrate the files. Actual code here:
http://member.america.htc.com/download/RomCode/Source_and_Binaries/bravo_54b7033a.tar.gz
------
At:
http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/power/ds2784_battery.c
we see device info struct as:
Code:
char raw[DS2784_DATA_SIZE]; /* raw DS2784 data */
struct battery_status status;
struct power_supply bat;
struct workqueue_struct *monitor_wqueue;
struct work_struct monitor_work;
struct alarm alarm;
struct wake_lock work_wake_lock;
with battery_status struct as:
Code:
u8 percentage; /* battery percentage */
u8 charge_source;
u8 status_reg;
u8 battery_full; /* battery full (don't charge) */
i.e. not many properties.
However, from the corresponding include file at:
http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/power/w1_ds2784.h
there are lots of defined registers, including several AGE and FULL_40.
Our 2784 code has both read and write functions (w1_ds2784_read/write), which are used in function ds2784_battery_read_status.
** Objective 1**
title:
to read some additional values such as AGE and FULL_40 and output them.
suggested implementation:
add in some other properties corresponding to AGE and FULL_40 values, populate these in the read function, parse them in the parse_data function, then output them at line 325 of the ds2784_battery.c file. Yes there will be lots of repetition, but the code is easily and quick to modify.
ideal implementation:
write a new app that outputs these but also outputs the status_reg value too. We can then use this to determine if and when our batteries go into "learning" mode. More below.
code-level:
1) modify struct battery_status, adding:
Code:
u16 age;
u16 full_40;
etc, with any other interesting ones too. Might as well grab all of them and output so we can hand-pick the ones that are useful.
2) from line 244 in parse_data, add something like:
Code:
s->age = raw[DS2784_REG_AGE_SCALAR];
etc
may have to convert from hex.
*****************
THEN I opened the HTC ds2784_battery.c and was amazed at what I saw!
*****************
*their* battery_info struct contains:
Code:
u8 level; /* formula */
u8 level_last;
u32 full_bat; /* Full capacity of battery (mAh) */
u32 full_level; /* Full level for battery control */
u8 guage_status_reg;/* guage status*/
u32 acr;
u32 active_empty;
their ds2784_device_info struct:
Code:
int guage_status_reg; /* battery status register offset=01h*/
int full_mah; /* battery full mah */
long full_charge_count; /* Full charge counter */
int acr;
int active_empty;
int full_level; /* Full level for battery control */
OK nothing earthshattering so far, BUT their Calculate_Full_mAh function uses the FULL_40 stuff.
** Objective 2 **
title: write values to registers
implementation: to be discussed once we have the values from Objective 1 and we still need it (i.e. learning mode does not exist or work to recalibrate).
Wrap-up:
The HTC charging code (from line 854) uses the following logic:
Code:
percent < 95, batt full = false
if status_reg = full and current <= 80 and percent = 100
then *IF IT HAS BEEN ONE HOUR OR MORE ON FULL CHARGE*!!!
then stop charging
WOW.
Nice thread. I'll give you a hand with this. Do you still need help getting your kernel compiling set up?
dvgrhl said:
Nice thread. I'll give you a hand with this. Do you still need help getting your kernel compiling set up?
Click to expand...
Click to collapse
yeah - how best to do this? what about gtalk? <mylogin>@gmail.com if you are OK with that. Will be online in two mins
loginwithnoname, very nice summary and overview. the HTC driver is what most interests me. i guess there would be zero chance of using the HTC code and logic, since it seems they A) use the better values of full_capacity, etc rather than the nexus "conservative" estimation. and B) theirs looks a little more straight forward than the nexus one.
where did you find the HTC driver? i cant seem to find it.
nice work!
just in case you still interested, here is the AOSP source code that pershoot used. well he used his code, then he posted this link in the other thread and said this is his current source he's using.
EDIT: sorry i meant this link
EDIT2: geez, still was cm code. i'll find it real quick.
finally:
http://android.git.kernel.org/?p=ke...54cfa3b22c61dd50eae;hb=android-msm-2.6.35-wip
RogerPodacter said:
the HTC driver is what most interests me. i guess there would be zero chance of using the HTC code and logic, since it seems they A) use the better values of full_capacity, etc rather than the nexus "conservative" estimation. and B) theirs looks a little more straight forward than the nexus one.
Click to expand...
Click to collapse
I think their code is old-hat given what we've done in the other thread, apart from the fact they wait an hour before deeming the battery "fully charged". I don't think as techies/devs we need that though.
thelogin said:
I couldn't see any of the 2784 battery stuff in AOSP so I'm guessing the CM team used the Desire kernel source from developer.htc.com to integrate the files. Actual code here:
http://member.america.htc.com/downlo...4b7033a.tar.gz
where did you find the HTC driver? i cant seem to find it.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
aw, come on Rog! that'll be http://developer.htc.com then click the download button for HTC Desire kernel source code
theloginwithnoname said:
I think their code is old-hat given what we've done in the other thread, apart from the fact they wait an hour before deeming the battery "fully charged". I don't think as techies/devs we need that though.
aw, come on Rog! that'll be http://developer.htc.com then click the download button for HTC Desire kernel source code
Click to expand...
Click to collapse
ha i found the HTC developer site, and grabbed the 74mb source kernel for the desire, but i'm at my work computer which i have no admin rights to do anything. how could i view that code? i was hoping for online repositories like github.
RogerPodacter said:
i'm at my work computer which i have no admin rights to do anything. how could i view that code? i was hoping for online repositories like github.
Click to expand...
Click to collapse
It's a .tar.gz so you need to unzip it then extract it. If you're on Windows, I'm told WinZip will unzip/extract it for you (I used 7-Zip); if you're on linux, tar -zxvf <file>.tar.gz will do it for you...
i wont clutter up this thread anymore, but winzip was the first thing i tried. its a strange winzip used here though, so its expected.
theloginwithnoname said:
** Objective 1**
title:
to read some additional values such as AGE and FULL_40 and output them.
suggested implementation:
add in some other properties corresponding to AGE and FULL_40 values, populate these in the read function, parse them in the parse_data function, then output them at line 325 of the ds2784_battery.c file. Yes there will be lots of repetition, but the code is easily and quick to modify.
ideal implementation:
write a new app that outputs these but also outputs the status_reg value too. We can then use this to determine if and when our batteries go into "learning" mode. More below.
Click to expand...
Click to collapse
rather than doing it at line 325, wouldnt it make more sense to modify lines 103-118:
PHP:
unsigned n;
mutex_lock(&battery_log_lock);
seq_printf(sf, "timestamp mV mA avg mA uAh dC %% src mode reg full\n");
for (n = battery_log_tail; n != battery_log_head; n = (n + 1) & BATTERY_LOG_MASK) {
struct battery_status *s = battery_log + n;
seq_printf(sf, "%9d %5d %6d %6d %8d %4d %3d %s %s 0x%02x %d\n",
s->timestamp, s->voltage_uV / 1000,
s->current_uA / 1000, s->current_avg_uA / 1000,
s->charge_uAh, s->temp_C,
s->percentage,
battery_source[s->charge_source],
battery_mode[s->charge_mode],
s->status_reg, s->battery_full);
}
mutex_unlock(&battery_log_lock);
return 0;
how easy would it be to just add on to this? i suck bad a code and talk out my arse, barely enough to see what's going on. i dont even know where to come up with
seq_printf(sf, "%9d %5d %6d %6d %8d %4d %3d %s %s 0x%02x %d\n",
which seems like where the actual data is coming from for each parameter being output. cant we just add our get_full40, scalar, etc onto that output string?
theloginwithnoname said:
code-level:
1) modify struct battery_status, adding:
Code:
u16 age;
u16 full_40;
etc, with any other interesting ones too. Might as well grab all of them and output so we can hand-pick the ones that are useful.
2) from line 244 in parse_data, add something like:
Code:
s->age = raw[DS2784_REG_AGE_SCALAR];
etc
may have to convert from hex.
Click to expand...
Click to collapse
I think the parse function is line 320, i dont see anything at line 244. so the parse and then pr_info is what is output when we see our dmesg log? for the simplest and quickest result, i think adding registers to the batt_log i posted up above would be the path of least resistence, no? (ignore if i make no sense, i'm noob with code).
then objective 2 would be writing back to the register...
this driver also talks about read/write the bits, which i dont know if we looked thru this one yet. its definitely part of all this i think.
cm-kernel / drivers / w1 / w1.h
http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/w1/w1.h
at least i hope it is relevant!
theloginwithnoname said:
yeah - how best to do this? what about gtalk? <mylogin>@gmail.com if you are OK with that. Will be online in two mins
Click to expand...
Click to collapse
Sorry man, I had a hell of a day at work and didn't even get on IM at all or check back on this thread. My IM is my name at gmail.com, so tomorrow I will make sure to be online if you want. I am PST. Have you tried following the guide here: http://wiki.cyanogenmod.com/index.p...m_source#Install_development_support_packages? I assume so. Where do you get stuck at?
Definitely looking forward to this
Something like the Desire one would be nice too,
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I've been wanting to check the "health" of my battery like how they do on Thinkpads forever.
It shows values like "Design Capacity" & "Full Charge Capacity" to let you see how much your battery is worn. Sometimes I feel like my battery life issues is not with Cyanogen but with the actual battery itself (bought it 2 months used so i dunno how well the other person treated it, came in box and had all original stuff (sealed) tho no scratches!! ) I was thinking to buy another battery and see but might as well get a Seidio then if that's the case
So in that case, the main battery should be "1400 mAh" battery but maybe it's current charge capacity is only 1000mAh so that's why my talk/usage time is low.
Not sure this helps, but just to spark some thinking i grabbed this from page 25 of the spec sheet for the ds2784.
http://datasheets.maxim-ic.com/en/ds/DS2784.pdf
STATUS REGISTER FORMAT
The status register contains bits that report the device status. All bits are set internally. The CHGTF, AEF, SEF, and LEARNF bits are read only. The UVF and PORF bits can be cleared by writing a zero to the bit locations.
PHP:
ADDRESS 01h
BIT 7 - CHGTF
BIT 6 - AEF
BIT 5 - SEF
BIT 4 - LEARNF
BIT 3 - X
BIT 2 - UVF
BIT 1 - PORF
BIT 0 - X
CHGTF—Charge-Termination Flag. CHGTF is set to indicate that the voltage and average current register values have persisted above the VCHG and below the IMIN thresholds sufficiently long to detect a fully charged condition. CHGTF is cleared when RARC is less than 90%. CHGTF is read only.
AEF—Active-Empty Flag. AEF is set to indicate that the battery is at or below the active-empty point. AEF is set when the voltage register value is less than the VAE threshold. AEF is cleared when RARC is greater than 5%. AEF is read only.
Click to expand...
Click to collapse
good spot Rog - I might need to decompile all the tech info and add it as a technical analysis post here. Will be a few days before I can do this though.
I'll post these links here for completeness, it kinda wraps everything up with examples of everything. You really should read when you have a sec.
http://pdfserv.maxim-ic.com/en/an/AN3584.pdf
http://pdfserv.maxim-ic.com/en/an/AN131.pdf
http://pdfserv.maxim-ic.com/en/an/AN4043.pdf
http://pdfserv.maxim-ic.com/en/an/AN3463.pdf
been looking over the code, and i'm pretty sure for phase #1, step #1, to grab the info we need we'd have to add the following line 51, line 224-226, and line 325 and 331:
we need to define the additional variable:
PHP:
48 int current_avg_uA;
49 int charge_uAh;
51 int full40_uAh /*This variable added*/
We need to parse the additional data (MSB and LSB for full40):
PHP:
221 /* RAAC is in units of 1.6mAh */
222 s->charge_uAh = ((raw[DS2784_REG_RAAC_MSB] << 8) |
223 raw[DS2784_REG_RAAC_LSB]) * 1600;
224 /* full40 has same conversion units of 1.6mAh */
225 s->full40_uAh = ((raw[DS2784_REG_FULL_40_MSB] << 8) |
226 raw[DS2784_REG_FULL_40_LSB]) * 1600;
and finally, simplest way i see it is to just add it to the dmesg log (at least right now, later we can do whatever with it):
PHP:
ds2784_parse_data(di->raw, &di->status);
324
325 pr_info("batt: %3d%%, %d mV, %d mA (%d avg), %d.%d C, %d mAh, %d full40 mAh\n",
326 di->status.percentage,
327 di->status.voltage_uV / 1000, di->status.current_uA / 1000,
328 di->status.current_avg_uA / 1000,
329 di->status.temp_C / 10, di->status.temp_C % 10,
330 di->status.charge_uAh / 1000,
331 di->status.full40_uAh / 1000); /*added this output to dmesg log*/
332 return 0;
333 }
the only thing i am not sure on is the conversion units for full40, i cant find it yet. we could just not convert it at all and end up with a large raw value, but that would mess up the dmesg log readability. for above i just assumed it was the same conversion as charge capacity (very well could be the same).
next i'll attempt the same for age scalar.
besides, there is another way to find the full40 value, its the one that your dmesg log jumps to when you hit full charge, but you have to be at +40 C temperature (that's what full40 is, its the max our battery can hold at 40C since the higher the temp, the more capacity our battery can hold). in my case, my getfull40 is 1369 mAh.
should i post this in the battery thread and see if pershoot would compile a test kernel for me? i'd try this out.
EDIT: i'm almost positive this will work, so i'll see how to add in age scalar before posting it in the other thread for pershoot.
Hi,
Here's a SystemUI.apk which seems to fix the high cpu problem when charging on P500 CM7. Note: I only edited the graphical icon not the battery percentage.
How to install: remove SystemUI.apk and SystemUI.odex in /system/app/, push the new SystemUI.apk to /system/app/
Possible cause of the problem:
On receiving battery change intent, cmbatteryminiicon creates a handler which causes redraw on scheduled time, the problem is, it should only create the handler once, since the handler schedules itself for execution next time. Therefore, we got increased amount of handlers triggering redraw over time which causes the increased cpu usage over charging time.
Also attached is the edited CmBatteryMiniIcon.java
Note: a simple way to check your cpu load when charging is to install an app that shows your CPU load in the statusbar, e.g. SeePU. Charge your phone for 30 minutes and then check your CPU load. If your ROM has the bug, SeePU will continuously shows your CPU load as a 100% (full red color).
Note: requires mik_os' CM7 beta 6.5.1, wipe dalvik cache in recovery.
Note: added a new flashable zip: systemui-faster-animation for those who feel the new animation is too jumpy (aka slow) to test
28/05/2011 Anyone with empty battery could please test this new zip . I have change the animation timer based on current battery level but since my battery is still full I cannot see the animation from the beginning.
It should be made flashable.
Testing it now.
Nice work. Now go get you self 10 posts and post it in mik_os thread.
Sent from my LG-P500 using XDA Premium App with missing Thanks Button.
Please create flashable zip, there is another file CmBatteryMiniIcon.Java, do we need to push that files also.
Thanks.
It's quite simple without flashable zip:
1. reboot into recovery
2. connect phone to computer
3. adb shell
# cd /system/app
# rm SystemUI.*
# exit
4. adb push SystemUI.apk /system/app/
5. reboot phone
You only need to put the apk, the java file is only required if you want to compile android.
Yes, we need a flashable zip, plz create one soon, thanks!
Ok I already installed it but with root explorer but I don't recomend root explorer method.(Only for those who knows what they are doing)
Sent from my LG-P500 using XDA Premium App
eagledipesh said:
Please create flashable zip, there is another file CmBatteryMiniIcon.Java, do we need to push that files also.
Thanks.
Click to expand...
Click to collapse
No u don't its source code. For developers.
Sent from my LG-P500 using XDA Premium App
4silvertooth said:
No u don't its source code. For developers.
Sent from my LG-P500 using XDA Premium App
Click to expand...
Click to collapse
Ok thank you both
How do we know that currently we are having high CPU usage while charging?
Sent from my LG-P500 using Tapatalk
lekhwani said:
How do we know that currently we are having high CPU usage while charging?
Sent from my LG-P500 using Tapatalk
Click to expand...
Click to collapse
Use Watchdog Lite.
Go to CPU usage in the app and you can see status bar using more than 30% CPU while charging. Sometimes it takes more than 50% as well.
Will try it now. Btw I am charging now and opened setcpu. It is showing frequencies between 320 and 600 and I am not doing anything. Does this behavior also confirm this? I am on 245/729 ondemand.
Sent from my LG-P500 using Tapatalk
Seems to have solved the high cpu. The charging animation isn't smooth anymore though, and flashes between animation frames.
A small price to pay to have the status bar use less than 1% of the cpu instead of all of it.
Thanks for this fix!
The high cpu usage doesn't start immediately but after some time of charging you can also use mini info app to check CPU usage. Setcpu just shows the clock speed and not CPU usage.
Sent from my LG-P500 using XDA Premium App
lekhwani said:
Will try it now. Btw I am charging now and opened setcpu. It is showing frequencies between 320 and 600 and I am not doing anything. Does this behavior also confirm this? I am on 245/729 ondemand.
Sent from my LG-P500 using Tapatalk
Click to expand...
Click to collapse
Probably yes.i.would use android assistant though it gives a exact graph and it's easy to see what the usage is sometimes when I plug mine in it it will ride on 90% milk of aware of the bug have you told him about the fix will he be putting it in his next beta version???? if so I'll probably wait for the official fix
LG-P500 using XDA Premium App running CM7, ungaze data2sd, over clocked at 787 quadrant score 2100
nogav said:
Seems to have solved the high cpu. The charging animation isn't smooth anymore though, and flashes between animation frames.
Click to expand...
Click to collapse
In the original code, the charging animation frame is updated every 1 second, so I don't think it's supposed to be smooth.
Flashed the zip
Before flash:
After flash:
In short CPU usage reduced to 1% from 35-60%.
This is kind of a genius work.
But after rebooting my 3g is working but not showing the h sign.
Scrolling lag while charge also seems to be gone.
Will check further.
Sent from my LG-P500 using Tapatalk
lekhwani said:
How do we know that currently we are having high CPU usage while charging?
Click to expand...
Click to collapse
If you are running adb you could:
adb shell
vmstat
{ctrl-c to exit}
The id column is the one that shows idle percentage.
# vmstat
procs memory system cpu
r b free mapped anon slab in cs flt us ni sy id wa ir
0 0 210600 51504 112456 9272 100 228 0 1 0 2 97 0 0
0 0 210600 51504 112456 9272 138 217 0 0 0 1 99 0 0
0 0 210600 51504 112456 9272 110 214 0 3 0 2 96 0 0
0 0 210600 51504 112456 9272 136 208 0 0 0 2 98 0 0
^C
In this example my OptT shows 1-4% CPU use (ie, 96-99% idle). So the charging cpu bug was not in effect during this demonstration.
I've de-emphasised the first line because traditionally the first line of vmstat output shows since-boot average or something, and the subsequent lines are snapshots. Dunno if it's that way in this shell (busybox?) or not but thought I'd mention it.
so maybe i was not supposed to do this but i just flashed the zip (didnt do the other steps) and now my notification bar is gone???? but it did fix the charging bug ... how can i fix??????? i saw the posted steps but then i saw the sighed zip and figured you can just use that
dislplin01 said:
so maybe i was not supposed to do this but i just flashed the zip (didnt do the other steps) and now my notification bar is gone???? but it did fix the charging bug ... how can i fix
Click to expand...
Click to collapse
I didn't test the flashable zip, so I don't know if it works or not. If your statusbar is gone then android cannot run your com.android.systemui process. You can either flash your ROM again or use adb to replace the systemui.apk
Here's my updater-script:
Code:
mount("yaffs2", "MTD", "system", "/system");
delete("/system/app/SystemUI.odex");
package_extract_dir("system", "/system");
unmount("/system");
Hmm, is this apk tied to a special version of mik's CM7 build? I use Beta 6.5. Installed with adb shell (removed SystemUI.apk and SystemUI.odex and then copied new SystemUI.apk to /system/app). I get constantly get FCs.
Will try to wipe dalvik cache and reboot again...
Here is an enhanced version of the battery gauge driver. It will likely work with all kernels. A couple of bugs have been fixed and new sysfs properties have been added. These changes are in large part based on enhancements of the Ubuntu battery gauge driver for the original Nexus 7.
The following new properties are added to '/sys/class/power_supply/battery/':
charge_now: remaining battery charge in uAh; compensated for load current/temperature (higher load current = lower usable capacity)
charge_avg: remaining battery charge in uAh; uncompensated
charge_full: charge in uAh, when battery is fully charged (as determined by battery gauge -> will go down as the battery ages)
charge_full_design: design value of battery charge (the capacity a new battery is supposed to have)
energy_now: remaining battery charge/energy in uWh; compensated for load current/temperature
charge_counter (signed value): coulomb meter measuring amount of charge that has flowed into or out of the battery; periodically set to 0, when battery has minimal load (e.g. on USB power and fully charged or during deep sleep)
power_now (signed value): amount of power flowing into or out of battery in uW (updated by the gauge every second); useful to see how fast/with how much power the battery is being charged
cycle_count: battery charge cycle count; around 4000mAh worth of charging correspond to a full cycle (e.g. when the battery is charged 50% = 2000mAh two times, you get a full cycle)
Reading the sysfs properties results in the battery gauge driver requesting the current value via I2C from the battery gauge. AFAIK, the I2C transaction uses software I2C and will block the CPU for a few dozen micro seconds.
A public datasheet for the battery gauge exists:
http://www.ti.com/lit/ds/symlink/bq27541.pdf
Disclaimer: The changes are not extensively tested and missing locking has been added to the driver (previously, concurrent requests via sysfs could result in wrong values) - there may be deadlocks lurking. The driver plays a role in controlling the battery charger, use it at your own risk (if your N7 burns and takes your house with it, don't come running to me).
Feel free to submit these changes to Google, I won't. The Ubuntu enhancements for the original N7 were submitted in January and have been ignored.
reserved
This looks awesome!
Sent from my Nexus 7 using xda app-developers app
This sounds interesting, I don't know if it is though!
Sent from my 2014 Nexus 7 using Tapatalk 4.4
For the non-kernel developers a bit more explanation. This is a kernel patch that modifies the battery gauge driver.
The kernel exposes certain information via sysfs, which is a virtual file system. If you have a kernel with this patch, you can open a terminal window and do something like:
Code:
cd /sys/class/power_supply/battery/
cat power_now
This will print the current amount of power used (in micro-Watt). You can also use a root-capable file browser (e.g. ES Explorer) to look at the sysfs files; you can open /sys/class/power_supply/battery/power_now like a 'normal' file (same thing with other properties mentioned in the first post).
If you want to try this, ElementalX 1.6 beta has this patch applied:
http://forum.xda-developers.com/showpost.php?p=45944453&postcount=1034
tni.andro said:
For the non-kernel developers a bit more explanation. This is a kernel patch that modifies the battery gauge driver.
The kernel exposes certain information via sysfs, which is a virtual file system. If you have a kernel with this patch, you can open a terminal window and do something like:
Code:
cd /sys/class/power_supply/battery/
cat power_now
This will print the current amount of power used (in micro-Watt). You can also use a root-capable file browser (e.g. ES Explorer) to look at the sysfs files; you can open /sys/class/power_supply/battery/power_now like a 'normal' file (same thing with other properties mentioned in the first post).
If you want to try this, ElementalX 1.6 beta has this patch applied:
http://forum.xda-developers.com/showpost.php?p=45944453&postcount=1034
Click to expand...
Click to collapse
any others aswell?