yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] RogerPodacter:
I think the whole problem is all related. Look at this huge jump from my log last week.

010 02:58:04 [INFORMATION] batt: 87%, 4167 mV, 115 mA (116 avg), 36.0 C, 1185 mA
08/18/2010 02:59:09 [INFORMATION] batt: 87%, 4167 mV, 112 mA (113 avg), 35.8 C, 1185 mA
08/18/2010 03:00:14 [INFORMATION] batt: 87%, 4167 mV, 108 mA (109 avg), 35.8 C, 1188 mA
08/18/2010 03:01:19 [INFORMATION] batt: 87%, 4167 mV, 105 mA (105 avg), 35.7 C, 1190 mA
08/18/2010 03:02:24 [INFORMATION] batt: 87%, 4167 mV, 102 mA (103 avg), 35.7 C, 1192 mA
08/18/2010 03:03:29 [INFORMATION] batt: 88%, 4167 mV, 98 mA (99 avg), 35.7 C, 1193 mAh
08/18/2010 03:04:34 [INFORMATION] batt: 88%, 4167 mV, 96 mA (97 avg), 35.6 C, 1195 mAh
08/18/2010 03:05:39 [INFORMATION] batt: 88%, 4167 mV, 93 mA (94 avg), 35.5 C, 1196 mAh
08/18/2010 03:06:44 [INFORMATION] batt: 88%, 4172 mV, 90 mA (90 avg), 35.5 C, 1198 mAh
08/18/2010 03:07:50 [INFORMATION] batt: 88%, 4172 mV, 87 mA (88 avg), 35.5 C, 1200 mAh
08/18/2010 03:08:55 [INFORMATION] batt: 88%, 4172 mV, 85 mA (86 avg), 35.5 C, 1201 mAh
08/18/2010 03:10:00 [INFORMATION] batt: 88%, 4172 mV, 82 mA (83 avg), 35.3 C, 1203 mAh
08/18/2010 03:11:05 [INFORMATION] batt: 88%, 4172 mV, 80 mA (81 avg), 35.3 C, 1204 mAh
08/18/2010 03:12:10 [INFORMATION] batt: 100%, 4172 mV, 78 mA (79 avg), 35.2 C, 1363 mAh
08/18/2010 03:12:10 [INFORMATION] batt: charging BATTOFF [FULL]
08/18/2010 03:13:15 [INFORMATION] batt: 100%, 4162 mV, 0 mA (0 avg), 35.2 C, 1363 mAh
08/18/2010 03:14:20 [INFORMATION] batt: 100%, 4157 mV, 0 mA (0 avg), 35.2 C, 1363 mAh

Somehow our battery got screwed up (limited during charging to full hint hint) and now this huge offset is throwing off the battery. Luke it was trained over time to have less capacity than it truly had. Not using the full range. I'm blaming the 80 mAh current check.
[Nexus One Android Development] theloginwithnoname:
I've started a new thread to discuss creating a battery calibration app - I figured it easier to discuss logic etc here and specific app code over there.

I have made some quite interesting finds whilst I was writing up a spec - including some custom HTC charging code! Go take a look.

I would be grateful for any developers interested in doing some coding and having an environment to compile heading over there - that's dvgrhl and pershoot that I know of so far!
[Nexus One Android Development] RogerPodacter:
I drained till the phone died and charged back up. I'm at 1390 ma with the 20 ma kernel. So it seems to definitely work to me. Now I'll test per shoots 40 ma one, though it may not get as high.

Also, my phone still died at the exact same point as weeks ago. It shut off at 3488 m volts at 16%. Identical to last time. Luckily, I exported the log 5 seconds before shut off, and no register change:-(

Actually ii hit 1393 and the timeout bug caused a unique condition that tripped the < 20 and cause it pulled negative off the battery for a minute, so tripped it to full battery. It was still at 33 ma and very smooth, it would have hit over 1400 easily:-)
[Nexus One Android Development] pershoot:
what's the status of this?

is the logic working?

do i need to change anything around, etc.?
[Nexus One Android Development] dvgrhl:
I'll report my results a little later this morning. I am testing the slow charge after draining the battery down below 50%.
[Nexus One Android Development] theloginwithnoname:
Copied from Battery Calibration app thread:

I opened the HTC ds2784_battery.c (HTC Desire kernel code from developer.htc.com) and was amazed at what I saw!

Firstly, *their* battery_info struct contains:

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:

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.

Also, the HTC charging code (from line 854) uses the following logic:

if percent < 95
then 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. Thoughts?!
[Nexus One Android Development] theloginwithnoname:
can you see my posts 369, the bottom of 370, and 388 please, and then can I have a kernel with <=99, >= 10, and < 10 respectively please pershoot!
[Nexus One Android Development] pershoot:
ill look at it tonight...
[Nexus One Android Development] theloginwithnoname:
That OK pershoot?
[Nexus One Android Development] RogerPodacter:
I'm not askign you to waste time fixing possible google errors. i'm just saying to test the kernel the timeout skews the results. so my opinion is your new <40mA kernel should be perfect. so dont worry about wasting time on the timeout if you dont need to. :D
[Nexus One Android Development] theloginwithnoname:
agree - have a look in the code.

not sure about that - code comment above where it sets timeout = true (battery .c file, line 490) is:

/* The charger has probably stopped charging. Turn it
* off until the next sample period.
*/

Because we don't set chargemode = batt_disable when status_reg = full (without charge or percentage criteria being met), this is now coming up as a result of full battery.

In some ways it looks like you're lucky!
[Nexus One Android Development] RogerPodacter:
but is it not true that in my situation above, when the timeout error occurs, it DOES satisfy all 3 conditions. it doesnt happen in the timeout check code. but wouldnt it occur in the 3 conditional statement, reg stat, <80, and perc=100?
[Nexus One Android Development] pershoot:
login,

Ill look at your stuff too later on tonight.
[Nexus One Android Development] theloginwithnoname:
cheers fella
[Nexus One Android Development] RogerPodacter:
Loginwithnoname one last question. Based on what we now know. I'm going to buy a brand new battery, to start over in a way. What do we recommend the process is for the first boot up? Before I turn on the phone with battery inserted, I charge for hours to bump charge to max capacity, then turn it on?

Or I can wait till we can read registers, then buy new battery.
[Nexus One Android Development] pershoot:
the first block states, >80 or < 99, battery not full (di->status.battery_full = 0). chances are 99 is going to come before lower then 80 is reached, so this can probably be changed to both having to be true.

once you go over 99 and <80, you enter the second block, and these must all be true:

if register & 0x80

avg_UA <= 40

percentage == 100

in order for the battery to be set to full and charging to be stopped (di->status.battery_full = 1).

reason i specify 80 up there, is in hopes you dont have to stay plugged in past 100 for too long to get some extra charge. for a smoother transition, it probably can be 40.

reason its 40 is because i saw erratic behavior when set to 20.

every battery is going to be a lil different. i already see you all hitting close to 1400 which is an improvement.
[Nexus One Android Development] pershoot:
ill try putting a delay in there.
[Nexus One Android Development] pershoot:
http://droidbasement.com/nexus/kern...-cm_2635.3-oc-uv-xtra-btn-aud-ram-neon_fp.zip

i made the first block percent <99 and >40 avg ua for battery keep charging

i want to stay safe here, so i hope this isnt too much stress.

second block uses current ua now.

increased polling 40 * 40 after battery full

if ((di->status.percentage < 99) &&
((di->status.current_avg_uA/1000) > 40)) {
di->status.battery_full = 0;
}

......

if ((di->status.status_reg & 0x80) &&
((di->status.current_uA/1000) <= 40) &&
(di->status.percentage == 100)) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
}

.....

if (di->status.battery_full == 1)
di->last_charge_seen = di->last_poll;
else if (di->last_charge_mode != CHARGE_OFF &&
check_timeout(di->last_poll, di->last_charge_seen, 40 * 40)) {
[Nexus One Android Development] RogerPodacter:
your current_uA looks very smooth and linear, you must have charged without turning on the screen too much. you should do a obump charge to see how full the battery can truly take. then compare that to your "turned-on" charges. but generally yes, a li-ion battery will only pull charge until its full, whatever value that happens to be. in your case 1380 was only pulling 33mA which is getting close to stopping completely, i.e. your battery's truly full. That's pretty good still…. does your phone make it all the way down to zero percent? or does it die too early like mine?
[Nexus One Android Development] dvgrhl:
This will reintroduce the issue of a temporary drop prematurely ending the charging even though the battery is not full. This happened to Roger where he had a momentary drop from around 80 mA to 10 mA, so his battery stopped charging. Using averages prevents that from happening. I think you need to leave avg in the second if block.

For the first if block, if you are wanting to stay safe then set the avg amount to 80 mA. That will let the battery safely get to 99%, then start down into the second if statement for the remaining portion of the charge to full.

if ((di->status.percentage < 99) &&
((di->status.current_avg_uA/1000) > 80)) {
di->status.battery_full = 0;
}

......

if ((di->status.status_reg & 0x80) &&
((di->status.current_avg_uA/1000) <= 40) &&
(di->status.percentage == 100)) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
}

.....

if (di->status.battery_full == 1)
di->last_charge_seen = di->last_poll;
else if (di->last_charge_mode != CHARGE_OFF &&
check_timeout(di->last_poll, di->last_charge_seen, 40 * 40)) {
[Nexus One Android Development] dvgrhl:
That's my next test, to let it get all the way to 0%, or as close as I can get. I'm working on that now. I'll try to make that happen tonight, watching it closely towards the end.
[Nexus One Android Development] RogerPodacter:
Yes exactly. Good catch I agree.
[Nexus One Android Development] RogerPodacter:
Please post when you're done. We desperately need to read register values. I want to see what voltage shut off is. Last night mine died at 3.48 volts with 200 mAh capacity left. We need to enable learn mode too.
[Nexus One Android Development] RogerPodacter:
I think there's a problem with the charge mode, using the 40mA current_avg from last night. It shows as FAST charge, but it actually seems to be in SLOW charge mode, as my current values are much lower than normal like they used to be.
[Nexus One Android Development] pershoot:
my logic is that the drop when factored in to the average would not exceed 40 in the first. that and both must be true now in order to exit.

could you all pls test this?

i am testing myself, and will post logs.
[Nexus One Android Development] pershoot:
this is why i want a definitive number for charging to be stopped, and let avg be used on top while floating to 99.

it'll poke it if something goes ary in the process. the frequency of poll is faster now for that section.
[Nexus One Android Development] pershoot:
dont flash that. i found an issue. it stopped charging at 81. amending.
[Nexus One Android Development] RogerPodacter:
What I mean is right now I'm at 51% and charging with wall plug. But its only pulling 250-300 mA. Yesterday and historically, fast mode pulls 500-700 mA, especially down low like 50% where the battery pulls very hard.

Did you make any edits to the mode logic? Is it possible its switched itself up somehow?

I'm not talking about the upper range near full charge if that helps. And I'm using the newest kernel posted today.
[Nexus One Android Development] RogerPodacter:
Ok that makes sense. Something is very wrong with current kernel. I'm at 51% and its not charging the battery at all now.
[Nexus One Android Development] pershoot:
updated link. using dgrhl's logic, keeping the and condition on top and increase polling back to 60 * 60

http://droidbasement.com/nexus/kern...-cm_2635.3-oc-uv-xtra-btn-aud-ram-neon_fp.zip

if ((di->status.percentage < 99) &&
((di->status.current_avg_uA/1000) > 80)) {
di->status.battery_full = 0;
}
.......
if ((di->status.status_reg & 0x80) &&
((di->status.current_avg_uA/1000) <= 40) &&
(di->status.percentage == 100)) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
}
.......
if (di->status.battery_full == 1)
di->last_charge_seen = di->last_poll;
else if (di->last_charge_mode != CHARGE_OFF &&
check_timeout(di->last_poll, di->last_charge_seen, 60 * 60)) {
[Nexus One Android Development] pershoot:
android says charged at round 1355mah, but it continues to charge (it states 100). we should look at how to time it right.
[Nexus One Android Development] RogerPodacter:
Yes that's part of the problem I believe that the old driver artificially set the "full charge" lower than it should be due to the false
[Nexus One Android Development] pershoot:
Finished at 1366.

Ill let it discharge completely b4 filling up again and report back.
[Nexus One Android Development] pershoot:
i also recieved a TIMEOUT. im unsure if that was always there, before we started fiddling.
[Nexus One Android Development] RogerPodacter:
Hmmm maybe I'm wrong, or your battery is older. I have old logs before we started. I can look for time out errors to see if it always existed.

Since our update I've been hitting high 1300's most of the time. Weird.

Also usb vs ac might make a difference...? Dunno, I'm very confused why it sometimes works and others not.
[Nexus One Android Development] pershoot:
im using ac.

pls report back on the latest kernel i posted.

we can start chopping away from this point and fine tune it.
[Nexus One Android Development] RogerPodacter:
Yes I'm testing new kernel now. At 91% so far.
[Nexus One Android Development] chowlala:
Would make sense. My phone reached 1377 mAh. But I get mails in the middle of the night. Maybe what we could try now is to turn off sync. Or rather, what I could try. Haha.
[Nexus One Android Development] RogerPodacter:
Well we have to code for the least common denominator general use case. Does this mean that HTC put that original value there for a season?

Question is doesn't the new driver totally remove the current check completely, instead checking only for battery full == 1? When does it stop if we ran that version? Maybe that would be a more universal way to handle this, and maybe that let's the battery decide what true full is.
[Nexus One Android Development] dvgrhl:
I don't think situations of where a call comes in or where the phone syncs are going to happen so frequently that getting a full charge will be interrupted. It's fine if a time here or a time there it interrupts it. I think most of the time you won't have that stop your charge.

As for the new driver, isn't that the one that just checks the charge to full flag? If so, then the problem is that it's getting set somehow sooner then when the battery really is full. Or is there a different version you are referring to?
[Nexus One Android Development] RogerPodacter:
Yeah I guess that's true. The most this will help out is when we plug in our phones over night and will have a full charge now in morning.

Yes the single status reg check. It's my thought that that is the newer driver, and the old one with the 80 mA check was what we were using on eclair. So I believe we tripped the status full early over time and conditioned our battery to this lower full state capacity. I'm repeating myself though...
[Nexus One Android Development] pershoot:
Ill revert completely back and test. If its not a significant loss then we can look for other avenues...
[Nexus One Android Development] dvgrhl:
If you mean revert to just using the status register condition only, I don't think you need to test that. We know that the charge to full flag is getting set before the battery is truly full.

Taking a look at the code we have tested with good results

if ((di->status.status_reg & 0x80) &&
((di->status.current_avg_uA/1000) <= 40) &&
(di->status.percentage == 100)) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
}

we know from the battery_log that the (di->status.current_avg_uA/1000) <= 40) condition is what finally stopped the charge. Both (di->status.status_reg & 0x80) and (di->status.percentage == 100) were already true. As soon as the average current dropped below 40 mA, all three conditions were now met and charging stopped.
[Nexus One Android Development] pershoot:
yea...

going to yank the 80ma on top. doesnt look like its needed.

il post one more test final then ill commit.
[Nexus One Android Development] RogerPodacter:
So my question is with only the status register check in place with nothing else, what sets it to true, ie what current or mAh value? Just theoretically I mean.

Pershoot do you know when the driver changed, was it eclair to froyo?

I bet if a brand new phone or battery were tested now, with the status register check only, and do a complete full charge right off the bat, the ds2784 fuel gauge would do its job and allow true full charge correctly. This is why we need to get the register value app going and pull all register values and see what we've got :-). Just like they did for the palm pre ds2784 battery. I can't wait heh...
[Nexus One Android Development] dvgrhl:
Ok cool. I'm draining my battery to 0% right now, or as close as it gets - we'll see. Then I'll flash your new test kernel and charge it back up to full while watching the logs. Most likely that will happen tomorrow.
[Nexus One Android Development] pershoot:
http://droidbasement.com/nexus/kern...-cm_2635.3-oc-uv-xtra-btn-aud-ram-neon_fp.zip

charging for 30-60 mins past 100% i think is sufficient.

if (di->status.percentage < 99) {

di->status.battery_full = 0;

}

....

if ((di->status.status_reg & 0x80) &&

((di->status.current_avg_uA/1000) <= 40) &&

(di->status.percentage == 100)) {

di->status.battery_full = 1;

charge_mode = CHARGE_BATT_DISABLE;

}

.....

if (di->status.battery_full == 1)

di->last_charge_seen = di->last_poll;

else if (di->last_charge_mode != CHARGE_OFF &&

check_timeout(di->last_poll, di->last_charge_seen, 60 * 60)) {
[Nexus One Android Development] pershoot:
dunno.. i believe its been like this for some time.
[Nexus One Android Development] theloginwithnoname:
Given other ds27xx batteries set the battery as "full" after two [< 10mAh] conditions, I would like to test the above code with my suggested values - I've slightly revised the code below as I think the above code is a bit ugly!

...
/* shut off charger when full:
* - CHGTF flag is set
*/

if ((di->status.status_reg & 0x80) &&
((di->status.current_avg_uA/1000) <= 10) &&
(di->status.percentage == 100)) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
}
else
di->status.battery_full = 0;

if (temp >= TEMP_HOT) {
...

(I've quoted the line above and below the affected code)

I think the first if statement in the first quote is redundant.

I would revert all other code (i.e. polling periods).

If could compile myself, I would but at present I haven't got a working environment. pers, could you please use 10 as the cut-off for average_uA so I can see what it does?

My phone is about to dip to 99 from a full off-charge, so would be a good opportunity...
[Nexus One Android Development] pershoot:
well we tested 20 and it really started acting quite erratic.

but i can put those in for you, if you like. ill try to do it in the morning. have to work in a few hours...
[Nexus One Android Development] theloginwithnoname:
thought: what about the following logic:

if (status == full and percentage == 100)
{
if (current_uA >= 20)
then charge_mode = FAST
elseif (current_uA >=10 and < 20)
charge_mode = SLOW
else
charge_mode = DISABLE
}

??
[Nexus One Android Development] theloginwithnoname:
Given it's around £20 ($30) here for a battery, if you can afford to, I'd just buy it and see.

There is some code in the HTC source - and there may be in the AOSP, I haven't looked since I saw it in the HTC - that does do some sort of calibration the first time the battery is charged. (it goes through the FULL_40 registers).

However I would probably do an off-charge of the battery overnight. Then I would turn it on and let it discharge completely til dead. Then off-charge it overnight again. Then discharge completely again. Then off-charge it overnight again. Then see what you have!

Charge the existing fully beforehand in case you are caught short when the new battery dies.
[Nexus One Android Development] theloginwithnoname:
I think my logic is correct - work through the code logic and see if I've read it wrong.
[Nexus One Android Development] theloginwithnoname:
1400-1379 (from your log) = 21 -> 1.5%

The formula is given here: http://forums.precentral.net/palm-pre/256967-find-out-how-good-bad-your-battery-6.html#post2582809

Given your phone continues to increase its capacity, even though the battery is saying "I'm full and at 100%" I would say there is more in there! Hence why I want to try 20 and 10.

People in the Pre forum are reporting that they have between 5 and 50% loss after 2 years. And 0-10% loss after 6 months. So, as XDA devs, we want to see how far we can push, right?!!
[Nexus One Android Development] theloginwithnoname:
Given he went to 49 after 58432 seconds, for the test to be conclusive I would like to see two or three values in the 30's - Roger has posted logs that show 9 then it goes back up to 80s and 90s!
[Nexus One Android Development] theloginwithnoname:
here's my log. as you can see, much better but it will go more!

interesting mV went to 4182

timestamp mV mA avg mA uAh dC % src mode reg full
8 4094 -288 -180 1318400 278 97 none off 0x87 0
68 4070 -411 -269 1315200 278 97 none off 0x87 0
124 4148 162 167 1315200 283 97 ac fast 0x87 0
184 4153 160 166 1318400 286 97 ac fast 0x87 0
244 4157 168 165 1321600 285 97 ac fast 0x87 0
304 4162 159 163 1324800 286 98 ac fast 0x87 0
364 4162 152 155 1326400 286 98 ac fast 0x87 0
424 4162 145 149 1329600 286 98 ac fast 0x87 0
484 4162 139 140 1331200 286 98 ac fast 0x87 0
544 4162 133 135 1334400 286 98 ac fast 0x87 0
604 4167 128 130 1336000 285 98 ac fast 0x87 0
664 4167 124 126 1337600 285 98 ac fast 0x87 0
724 4167 119 121 1340800 285 99 ac fast 0x87 0
784 4167 114 117 1342400 285 99 ac fast 0x87 0
844 4167 110 111 1344000 285 99 ac fast 0x87 0
904 4172 106 107 1345600 283 99 ac fast 0x87 0
964 4172 104 88 1347200 283 99 ac fast 0x87 0
1024 4172 99 100 1348800 283 100 ac fast 0x87 0
1084 4172 96 97 1350400 283 100 ac fast 0x87 0
1144 4172 92 94 1352000 283 100 ac fast 0x87 0
1204 4172 89 91 1353600 283 100 ac fast 0x87 0
1264 4172 85 88 1355200 283 100 ac fast 0x87 0
1324 4172 83 84 1356800 283 100 ac fast 0x87 0
1384 4177 80 81 1358400 283 100 ac fast 0x87 0
1444 4177 66 60 1358400 283 100 ac fast 0x87 0
1504 4177 75 76 1360000 281 100 ac fast 0x87 0
1564 4177 72 73 1361600 280 100 ac fast 0x87 0
1624 4177 70 71 1363200 280 100 ac fast 0x87 0
1684 4177 67 68 1363200 280 100 ac fast 0x87 0
1744 4177 65 65 1364800 280 100 ac fast 0x87 0
1794 4177 63 64 1366400 281 100 ac fast 0x87 0
1864 4177 60 61 1366400 276 100 ac fast 0x87 0
1924 4177 59 59 1366400 276 100 ac fast 0x87 0
1984 4182 57 58 1368000 276 100 ac fast 0x87 0
2044 4182 55 56 1368000 276 100 ac fast 0x87 0
2104 4182 54 54 1369600 275 100 ac fast 0x87 0
2164 4182 52 52 1371200 273 100 ac fast 0x87 0
2224 4182 50 50 1371200 273 100 ac fast 0x87 0
2284 4182 48 49 1372800 273 100 ac fast 0x87 0
2344 4177 34 37 1372800 271 100 ac full 0x87 1
2404 4172 0 0 1371200 268 100 ac full 0x87 1
2464 4172 0 0 1371200 268 100 ac full 0x87 1
2524 4172 0 0 1371200 267 100 ac full 0x87 1
2584 4172 0 0 1371200 266 100 ac full 0x87 1
[Nexus One Android Development] pershoot:
received 1377 this time (charged from 70's). been sitting at 100 for ~40 mins (off charge).

good stuff.
[Nexus One Android Development] ratson:
for me 1384 with your latest kernel
[Nexus One Android Development] Markdental:
How do you check using os monitor?