[UTILITY] Battery calibration tools - Nexus One Android Development

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.