yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] xguntherc:
So if our phone is over 89% and we plug it in. Its not suppose to charge right? Or does it.. I've noticed if I plug it in when its at like 96%. Ill check on it and its at like 92 in 25 minutes of " charging" it charges when it drops below 89%.

I have terrible charging habbits. If its under 60% I plug it in. Everyday after work I top it back to 100 at least twice between 5 and whenever I go to bed.
[Nexus One Android Development] RogerPodacter:
right you are correct. but the problem is that after exported 5 days worth of battery logs, its pretty much a slam dunk that A) the phone always hits 100% and reaches 1361 mAh. and B) that we know by turning the phone off and letting the charge continue, that the internal battery pack fuel gauge IC allows the remaining capacity to be charged.

what i'll do is add some plots tomorrow showing the current into the battery against mAh to get a better idea. either way this is all just testing.

you made me think of something. are you saying that the new modified code in cm has this condition removed completely? i wonder if its possible that earlier builds had the original battery driver. and since i have not wiped my ROM at all during all my upgrades, that i never flashed the new driver to my phone. not sure that would even happen.

then again, it seems like others who probably have fresh installed latest cm are having the issue still. so oh well...

EDIT: also there are a bunch of other files that the battery driver calls. it could be possible this function got moved somewhere else. i'm looking thru them. but i seriously doubt that.
[Nexus One Android Development] RogerPodacter:
the other question is, how is it possible that my phones continues to stop charging when the current goes below 80 mA? i would think i'm running these newest files since i'm on cm rc3. but its totally reproduceable that my battery continues to shut off at 79 mA. anyone know how this is possible? could it be that condition still buried somehwere in the driver? i'd think it must be based on that...
[Nexus One Android Development] dvgrhl:
I don't know where the charge to full flag is set, but it looks like that is happening before the battery is truly full. One modification to the file you could try out is this:

if ((di->status.status_reg & 0x80) && (di->status.current_uA <=20000)) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
} else
di->status.battery_full = 0;

I have no idea how this will work in practice though. If you do test this out, I would carefully watch what happens as the battery charges and nears 100% true capacity. I think the battery will protect itself from overcharging regardless of what the OS does, the same as if the phone was turned off.
[Nexus One Android Development] RogerPodacter:
i dont know if i'd trust adding that and it actually working. who knows what could happen. adding that condition seems like it would work. but unless i'm crazy, the condition is already being met as it is.

this is either the craziest coincidince ever, or something is missing/overlooked.

i'm sitting here charging and continually running the dmesg log manually repeatedly as the charger approches 1361 mAh at 100%. and i can actually speed up or slow down running dmesg, and the mA draw is hovering right on the border at 93 mA, 81 mA, and i just let it go, it hit 79 mA on the next cycle. and shuts off. i purposely kept running the dmesg for a while as to try and keep up the current draw, and i was able to get the mAh up to 1372 mAh. then i relaxed running dmesg, and it drops to 79mA, and bam->shut off on the next line. its just too much of a coincidence, that code must be somewhere that we just havent seen. i mean hell it was there originally for a reason.

oh and i just flashed a fresh cm rc3 and did a full wipe. so should be using current ds2784_battery file. i now have so many dmesg logs showing the charge cutoff at precisely 80 mA that its gotta be in there somewhere.

i know that 0x80 is some register value, but its the closest thing to something being set to "80 mA" that i see. could that be it?
[Nexus One Android Development] theloginwithnoname:
Wow, there is a *lot* of technical information there. I am very glad I read the Pre thread before it (and especially for reading through somline's calibration script*), as much of the diction is recognisable after understanding the thread. For example, terms like LEARNF and authentication (which, btw, both of which our battery has - which is promising).

and more-importantly, over on the Pre thread they have figured out how to set registers responsible for age, capacity, etc (though these can be/are overwritten when learning in progress)

Follow the post on if you have the time to read, to page 7 which redirects you to page 11. Alternatively, if you really can't spend the time reading all the info, just go to the first post which has all the "headline" info.

There is also mention of people's batteries jumping from 9x% to 100% and 10%+ to 0%/shutdown - as Roger, myself, and others have seen. This is touched upon in point (2) of the first post. The battery is reporting (say) 1400 but actually only has (say) 1300 capacity.

somline talks about a very small window when the battery switches into "learning" mode just before shutdown (I think this is what the CHTF flag is, as mentioned by @dvgrhl). If the charger is plugged in at the right time and a full-charge done, the battery will re-learn/"recalibrate" the max capacity (and/or age ratio/%, not sure at this stage). I would guess this would solve the 10% -> 0% and the 9x% -> 100% issues.

*His script link is in post 208 - the script checks the registers continuously until the flag has been tripped and then notifies to start the charge. The script won't work straight on Android, as the files aren't 1:1 mappings. I've had a dig around and can find some of it, but will post separately if I find any info that people can use.

interesting files I've found:

/sys/kernel/debug/battery_log - since boot?

/sys/devices/platform/ds2784-battery/power_supply/battery - readonly snapshot of values

first file has "reg" and "full" columns (on mine it shows 0x87 and 1 until it hits 89%, then it goes to: 0x07 and 0 on usb slow charge, and back to 0x87 and 1 when 100% again). However, I think the code Roger mentions ("you can see the code actually pulls raw battery data from this EEPROM register") could be used to set values, but we'll need to look further into this, as it's likely read-only for the majority of time.

Another interesting point over in Pre-land was, the device decided to stop charging when it reached a particular voltage.

So, it should be possible to set a new capacity value (I would probably start with the highest value you've all individually seen in dmesg, as you *know* your battery can achieve that value) and it should be possible to do a learning charge to calculate the "age", so that in combination with the capacity the battery will once again report accurately.

I'm going to carry on reading the Pre forum - I will add/update anything here as a result
[Nexus One Android Development] theloginwithnoname:
registers?

Throwing this in, no idea if useful:

http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/power/w1_ds2784.h
[Nexus One Android Development] RogerPodacter:
Yes that was gonna be on my reply to theloginwithnoname. Notice there are registers there with slope 1 thru 4 among many others.
[Nexus One Android Development] RogerPodacter:
Ive been reading that thread, great stuff for sure.so ive abandoned the 80 mA code as just a crazy coincidence.

To give some info, the common number we all see in this thread is 1361 mah. This is what it stops at charging with the phone on.turn it off from that point and you get up to around 1420 mah in general.

The pre thread talked about 4.191 volts cutoff. its possible when we charge with our phone off that the full voltage allows the extra capacity to be charged, or maybe with no load it changes something. The other common number is 4.172 volts, seems the dmesg log has never once gone above that.mostly it tops at 4.167 everytime.

Yes I looked thru the ds2784-battery files, too bad they are read only. And the battery_log seems to only be the current charge cycle from what I've seen.

Its too bad we can't easily read the register values.

One last thing. Tonight I hard reset and flashed completely, and my full charge mah actually changed to 1370 mah, and the percentage scale shifted for real. I know earlier in this thread I plotted some graphs saying these values never change. But I was dumb cause I haven't wiped my phone in a few months now. So it seems like a true wipe resets the registor values,or at least some of them. That should be proof of concept right there,if you could figure out how to read the registor values we could have some great data to look at.
[Nexus One Android Development] theloginwithnoname:
yep, have been googling hard to find the equivilent of getage et al, but no luck.

My gut feeling is 'placebo' but I'm willing to full wipe and test mine! Does "hard reset and flashed completely" mean a complete wipe in recovery and new ROM flash? If not, can you describe the steps you took and I'll reproduce here.
[Nexus One Android Development] theloginwithnoname:
Question: do you think the time frame when "learning mode" is activated could be when our devices show a red crossed battery icon just before shutdown?

Might try and get hold of battery_log at that point to see if the register changes...
[Nexus One Android Development] RogerPodacter:
i wont discount it could be placebo. but because i have about 35-40 dmesg exports from last week, i can name every percentage range from then. 1361/1359 mah = 100-99% for example, each and every day i exported. that's typical of what its been for the last few months, so i just thought it was "hard coded". but i am willing to bet these registor values can change this.

the next step is to do the true full bump charge and get up to 1400 mAh, then leave the phone plugged in and do the hard reset. that could give results we need.

all i did was rather than simply hard reset, i first hard reset, then went into recovery, wiped all cache, hard reset from recovery, then flashed ROM from zip on sd card. wanted to make sure nothing was left behind. i'm going to try the bump charge and flash next.
[Nexus One Android Development] RogerPodacter:
i would really doubt it. i searched all the files on AOSP github and dont remember anything specifically about it that. i couldnt even attempt to get the register value if i wanted, since my phone alwys shuts down at 10-15% :D. if you can get down that low, be quick about getting to that file!
[Nexus One Android Development] RogerPodacter:
question: is it possible that the reason the "bump charge" works is because when we turn the phone off to complete the charge, the temperature drops? looking thru the code earlier, there are voltage limits based on different temperatures in the code. and i'm sure the battery pack IC has controls of its own. could it be that simple that the cooler battery can be charged up just a little bit more?

the other possibility is that the battery is under zero load with the phone off, no OS to run or any components...
[Nexus One Android Development] dogiedogie:
Nothing technical here, but would just like to say that even with the calibration via charging tips someone had reported from HTC [which did work for a bit], im STILL shutting down at 11%, even with battery stats wiped etc etc.
[Nexus One Android Development] dvgrhl:
It's actually not being met as is. What that is saying is if charge to full flag is set AND the current draw is <= 20 mA, only then stop charging. If the charge to full flag is set but you're still drawing more than 20 mA then keep charging - as presumably there is more charge that the battery can still hold. My suspicion is that the charge to full flag is being set by a condition met somewhere else that is happening earlier than when the battery is truly full.

Unfortunately, the "80" in 0x80 doesn't have anything to do with 80 mA, or a register either. 0x80 is hexadecimal for a binary number to do the bitwise AND operation with the value of di->status.status_reg. I am really rusty on my bitwise operations, but I think 0x80 is -128, which I think is being used for a two's compliment. I really need to brush up on this to have a better understanding of what is happening, but either way it's not something related to 80 mA.

I don't think it has to do with temperature, as if it did then the phone would stop charging at all sorts of different intervals, not just close but not quite to 100%. Since this happens consistently at the same point, temperature, which a variable condition, can be removed as a suspected source.

Similarly, I don't think it has to do with the load the phone is under as when just sitting idle the phone is using far less power than the power coming in from the wall charger. The fact that it charges to where it should when the phone is off but not when the phone is on tells me that this is a software issue.
[Nexus One Android Development] theloginwithnoname:
That is a valid point. I still think the phone would revert to slow charge or stop charging if a certain temperature is hit, but I'm guessing you'd need to be charging in *very* hot direct sunlight to get close to it!

There are three issues here 1) that an on-charge does not charge as fully as an off-charge, 2) that the battery does not get charged to similar levels each time an on- or off-charge is done, and 3) that battery levels are not being reported correctly/accurately.

I think we're all agreed with your assumption wrt point 1, and I think it's in code somewhere.

As far as 2 and 3 are concerned, the debate rages on!
[Nexus One Android Development] ram130:
+1..you know we don't have a voice in this debate. :D
[Nexus One Android Development] RogerPodacter:
if that code would actually function properly, i will try it just for the hell of it. this guy was nice enough to recompile my original request, maybe he'd do it again.

http://xdaforums.com/showthread.php?t=762005

so i bump charged with phone off this morning and got it up to 1408 mAh, then i completely flashed a new ROM. it definitely works it seems. i'm at 2 hours 50 minutes and still at 98%. and the mAh reading is still in the high 1300's. i'm just curious if that wipe will reset my 100% charge to that high value. somehow i doubt it...

couldnt the driver on that note related to the palm pre thread, isnt it possible that someone could edit ds2784_battery.c driver and add in a function that simply calls each variable or whatever that is assigned to each register value so that someone could make a small utility to interact with it? i'm talking out my arse, so that probably makes no sense. i just figured if the source is available...

about the 80 mAh thing, i keep checking every time, and it still cuts off exactly at that point. i bet what happened was in that earlier driver, google used that value as a recommendation from the manuf for whatever function they were performing until they could re-write it at a later date. and that this condition is actually coming from the battery IC itself. so that's why they used that value to begin with...who knows.i'm all cached out.
[Nexus One Android Development] RogerPodacter:
i'm a maroon. i went thru all that trouble of doing a full flash to test out the battery re-calibration. so i got up to 1408 mAh, flashed, and used the phone. and for some reason at work i decided to plug the phone into usb charger at only 85%. so i didnt even let it go the full range down to discharge.

interesting info is that when it charged back up from 85% to 100%, it did not go back to where it started at 1408 mAh. it only made it to 1361 mAh and then shut off, of course with a current reading of 74 mA (that < 80mA always seems to kick in for some reason).

i guess i goofed up the whole test. i dont know if i have the energy (stupid pun) to flash and try again...
[Nexus One Android Development] dvgrhl:
If you do want to test it and that guy isn't available to compile it for you, then I can try to set up an environment to compile it for you. It's something I've wanted to do anyway, just might take me a few days to get to it. I'll also try to find where the charge to full flag is being set in the code.

You're a slightly darker shade of red? :P

I'm thinking that the Cyanogen irc channel might be a good resource for getting some answers to these questions. They're certainly going to be some of the most knowledgeable people about this issue. I haven't don't the extensive work you have on researching when the battery stops charging, but I have started checking my logs. Once I feel like I have a better grasp on what to ask, I might give it a shot. If you get to that point first, go for it and report back.
[Nexus One Android Development] RogerPodacter:
That might be the key to testing this whole thing if you can setup a wworking build environment.the problem currently is what code do we test? I almost want to flash the older rom just to test it.

Yeah I'm a maroon is just an old goofy saying I used to use.

Anyway at this point I've exported so much battery data its crazy.interestingly in the file El_ds2784 there are 4 variables called slope1, slope2, slope3, slope4. However I'm more convinced that the maxim fuel gauge IC is doing all the calculations and battery reporting.in fact we know this for sure especially from the palm pre thread.also reading thru the ds2784 data sheet there are a few things in there that could explain the 80 mA cutoff. Ugh we need an expert.
[Nexus One Android Development] houmles:
Guys, no problem to compile anything. I have testing environment on server with 16core processor and 16gig ram so it takes couple of minutes co compile whole ROM from scratch :)
[Nexus One Android Development] theloginwithnoname:
Yes, maroon is one word for it! :D

I wouldn't worry too much about it Rog, I don't think it will have any massive effect. Over in pershoot's kernel thread, we always allow a new ROM and/or kernel two full cycles before we judge the battery life anyway.

the fact that your device reported 98% after 2h 50m is a bit misleading - because it was probably 1hr 40 mins above 1360 (between 1408 and 1361) and therefore still showing as "100%" - until it gets below that, it doesn't register. Therefore, if my 1hr 40 is approximately right, you've dropped 2% in 1hr 10 mins (which is about 3.8mAh per minute) - about right.
[Nexus One Android Development] theloginwithnoname:
not jealous!
[Nexus One Android Development] theloginwithnoname:
No, it's good brainstorming. We could:

take the logic from somline's bcm.sh script, use the registers from somline and/or the battery .h file, and output every 1 second/10 secs/1 minute (whatever). that would tell us if the registers are the same and/or what is going on - we need the equivilent of dumpreg first which, as Rog indicated, could be:

static void ds2784_parse_data(u8 *raw, struct battery_status *s)

{

short n;

/* Get status reg */

s->status_reg = raw[DS2784_REG_STS];

try setting the age of the battery to 100% using somline's technique ("echo 0x1480 > setreg")

find some code that would set a register (the status reg?)

contact the bloke at HTC to read the thread and get his thoughts

get the tech specs on our battery and use them to get the battery into learning mode, thereby calibrating properly

If I had a spare battery I'd likely try point 2 first. Most likely it will not work, if it fries battery, I use spare!
[Nexus One Android Development] theloginwithnoname:
From w1_ds2784.h:

#define DS2784_REG_AGE_SCALAR 0x14

Seems that it uses the same register to set the age! ;)
[Nexus One Android Development] theloginwithnoname:
when "dC" hit 300 or uAh went to 116800 (somewhere between 8 and 9%), "reg"/"full" changed to 0x27 and 0...

edit: Was at uAh=100000-odd/7% when it shutdown. Powered back on after connecting charger and uAh = 0, with reg 0x77. On second line, it then showed usb/slow with reg = 0x67.

edit2: at uAh = 78400 (6%), reg went to 0x27. At uAh = 200000, reg went to 0x07
[Nexus One Android Development] RogerPodacter:
great thoughts for sure:D. aside from pulling the battery register values, i'm going to actually give this code a test try which was posted earlier:

if ((di->status.status_reg & 0x80) && (di->status.current_uA <=20000)) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
} else
di->status.battery_full = 0;

my theory is that this original code had those 3 conditions set, 100%, <= 80 mA, and set the CHGTF flag to 0x80. well if we used our phones (assuming on eclair 2.1) all that time. then the battery was being told that status.battery_full turned from false to true when those conditions were satisfied. and over time artificially learned that 1361 mAh just happened to be where it stopped. afterall, many of us on this thread see 1361 mAh as the top charge. that's too much of a coincidence. ideally we would all have different upper limits based on how we each use our phone, how old our battery is, how many charge cycles we go thru, etc.

i think those conditions artificially limited our true full charge somehow. at least that would make sense for me as to why i've always had my battery die at 10%. i've never gotten the full top capacity of true 100%. so the battery's learning that 100% is really lower than the true 100%. hence when it gets down to 10% it knnows it should have 10% more but it really doesnt.

its probably a stretch, but i'm gonna give that code a try anyway. i'll just be very careful for sure. anyone know the best way to make a simple flashable file or something to push to the phone? it is line 450 on ds2784_battery.c.

original:

if (di->status.status_reg & 0x80) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
} else
di->status.battery_full = 0;

new:

if ((di->status.status_reg & 0x80) && (di->status.current_uA <=20000)) {
di->status.battery_full = 1;
charge_mode = CHARGE_BATT_DISABLE;
} else
di->status.battery_full = 0;

the other interesting thing is that the original file had BATT_OFF mode, but the new as BATT_DISABLE. a few lines down from all this is the switch / case function with 4 modes, DISABLE, OFF, SLOW and FAST. the original file only had 3, OFF, SLOW ad FAST. possible DISABLE does something different than OFF.

EDIT: actually this is very possible if that mode outputs to the file when status.battery_full is set to either 0 or 1, and i think it does do this.
[Nexus One Android Development] theloginwithnoname:
agree about the coincidence, not sure about the first bit ;)

I think it's the opposite, actually, Rog - see post 1 of the Pre thread, it means the battery is reporting it has a greater capacity than it actually has. If it says "I have 1400" and is charged at 100%, it's likely it only has 1300. So when it gets to 10% left, it thinks it has more left but it actually only a little bit, and when that runs out, the battery probably signals to the device it's empty, hence why Android just shuts down.

Put another way, your battery needs calibrating by learning the new full capacity/age!

I think this will work and make it charge a little more, however I think it will make the shutdown-at-greater-than-0% problem worse!!

Could this be related to the "don't charge between 90 and 100%, just provide power" functionality that was included in the more recent kernels?
[Nexus One Android Development] RogerPodacter:
are you trying to possibly find the learning function? that's interesting that you got 100 mAh at 7% because the lowest i've ever seen wsaa 175000 (175 mAh) and then my phone shuts down, at around 3.5 vlts. but when boot back up, it says 3.4145 volts. i could never get to the battery log in time qquick enough to get the values by the time my battery shut down. man i hope you find the learning function!