yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] dharani1234:
After you download Os monitor

1) Open the OS Monitor app and click on the message tab ( 5th Tab from the left )

2) Hit the "options" soft button on your phone.

3) select "options"

4) Scroll down to the end and you will see - Filter (Dmesg) option. Click on it.

5) Check the "enable filtering" checkbox.

6) Hit the "Tag Filter" and an input box will be displayed.

7) Enter "batt" in that box and go back to the messaging screen ( hit back twice )

8) wait for 1-2 seconds and that should show the info you require.
[Nexus One Android Development] Markdental:
Great thanks. Will it only show if I am charging?
[Nexus One Android Development] pershoot:
already included:)
[Nexus One Android Development] dvgrhl:
Awesome. And thanks for jumping in the thread to help us out with this.
[Nexus One Android Development] Markdental:
Thought I would ask this here, and maybe you all are already working on this:

Any way to make the phone shut off at 1% battery left instead of ~5-10% using the kernel? Just wish we could use that extra % if needed.
[Nexus One Android Development] pershoot:
check your voltage when it gets there. it 'probably' wont coincide with what is reported by android. it designed to shutoff a bit before, for safety of the battery.
[Nexus One Android Development] RogerPodacter:
Where did you see the conditions for <10, was it on AOSP or the HTC developer site ROMs?

We really need to set the battery full flag when the ds2784 chip sets to full. But we don't know what that is yet.

Edit: nevermind I see the <10 condition in ds2760.c on AOSP site.
[Nexus One Android Development] RogerPodacter:
Yes exactly. We have to agree that these batteries won't pull more than they need till full. So when I'm charging and using my phone, it causes the current to dip if I put the battery and phone under load. This doesn't mean we should stop the charging though.

Really we should be using the ds2784's logic to stop the charge when full. But we don't know what that value is yet.
[Nexus One Android Development] RogerPodacter:
I'm convinced that jump is a problem related to all this. It's too much of a coincidence that we all just happen to top out at 1360 mAh, even when the phone was brand new (in my case). Also, a thread just popped up in the general nexus forum with everyone who's battery dies at 10%, or dies too early. Wouldn't it make sense if battery_full has been set too early, when 1360 mAh and
[Nexus One Android Development] RogerPodacter:
We can do this once we get the app working which can read the ds2784 register values and set the battery to learn mode. That's being worked on in the other thread.
[Nexus One Android Development] Markdental:
Can you point me to that thread?
[Nexus One Android Development] RogerPodacter:
It's talked about in depth earlier in this thread. Then a link branched off to that thread by login with no name. I don't have the link handy.
[Nexus One Android Development] RogerPodacter:
I found the change for my earlier question, but no date. Only thing it shows it it happened Feb or after.
[Nexus One Android Development] dvgrhl:
I was paying too much attention to other values in the battery_log that I didn't even notice how when the battery jumped from 92% to 100%, the reported charge also jumped significantly.

Check out my last log from just now:

9280 4182 91 93 1225600 295 90 ac fast 0x03 0
9330 4182 90 90 1227200 293 90 ac fast 0x03 0
9381 4182 88 74 1227200 293 90 ac fast 0x03 0
9431 4182 86 86 1228800 293 90 ac fast 0x03 0
9497 4177 39 8 1230400 296 91 ac fast 0x03 0
9547 4182 85 85 1356800 296 100 ac fast 0x83 0
9598 4182 82 82 1358400 296 100 ac fast 0x83 0
9648 4187 79 81 1360000 296 100 ac fast 0x83 0
9698 4187 78 78 1360000 295 100 ac fast 0x83 0
9748 4187 75 75 1361600 293 100 ac fast 0x83 0
9798 4187 72 74 1363200 293 100 ac fast 0x83 0
9849 4187 73 63 1363200 293 100 ac fast 0x83 0
9899 4187 70 72 1364800 293 100 ac fast 0x83 0
9949 4187 69 70 1364800 292 100 ac fast 0x83 0
10004 4187 68 63 1366400 291 100 ac fast 0x83 0
10055 4187 67 66 1368000 291 100 ac fast 0x83 0
10107 4187 65 65 1368000 291 100 ac fast 0x83 0
10158 4182 22 13 1368000 296 100 ac full 0x83 1
10208 4172 0 -52 1369600 302 100 usb full 0x83 1

Notice how it goes from 1290 mA at 91%, to the very next line jumping to 1356 mA at 100%. Something isn't right with that.
[Nexus One Android Development] RogerPodacter:
Yeah that happens to me too, only when I charge from zero after I killed it. I swear that jump is all related to the 80 mA issue in the old driver. Similarly when I drain completely my battery dies with 200 mAh capacity left. It's like the entire 0-100% range got artificially shifted down because battery_full was set too low over time, so the whole range was shifted down. That's why it dies around 10%. And after shut off, charge back up to full, and it corrects itself back at the top which is the jump we see.

If that's not right, its something close to that, and all related I think.

Notice the new driver uses ONLY battery_full == 1 as the condition, no more current mA checks. Our batteries got goofed over time using that old driver. Only way I see it.
[Nexus One Android Development] dvgrhl:
Ok, so if it only happens when you let the battery go all the way down to zero, then I just missed it last time as that's the only other time I did that when testing. There's still something significantly wrong though. The current charge of the battery should be an absolute number: at this instance in time the charge is exactly ______. I can understand the percentage not being accurate, as the battery doesn't know for certain what it's peak capacity really is since there are many factors that affect it (age, temp, etc...), so it has to guess. But I expected the current charge to be accurate.
[Nexus One Android Development] RogerPodacter:
Well my opinion is that in old driver, when all 3 conditions were met, it set battery_full = 1 which writes to the ds2784 register saying that's "full charge". But really it isn't full. So over time the register values are stored as incorrect, thus our current problem.

I'd bet a brand new battery used with recent driver would not have this issue. And we see some people around the forum who claim no problems, their battery goes to zero properly.

Is that possible?

Edit: in fact I think I have proof. I just reached full charge, mine jumped from 1200 something right to 1372. But before we started these tests this week, that number it jumped to was 1361, EVERY time. The last few days we've been getting it up higher and the register is slowly being re written. No way have I ever seen mine jump to that before. It's learning its new proper full charge mAh capacity. I'll post the log shortly.
[Nexus One Android Development] RogerPodacter:
To put it another way, yes the battery should know "this is my value" no matter what. But if the driver continually tells it otherwise, and writes that new incorrect value to ds2784 memory, it now throws off the whole thing. I'm convinced that's why there's this offset problem from the 2 fighting each other over time.

I Notice when mine dies at 10% there's about 200 mAh left, but I hit the under volt 3.4 value so the phone shuts down.

The ds2784 is programmed with all proper info for a 1400 mAh battery, with all the correct stats for that. It's using all those values correctly except for battery_full which is now wrong because of all this.

The ds2784 has a resistor which uses to read and calculate the energy going into and out of the battery. It's tracking the capacity being charged, but then it seems to jump up because its been told falsely that full charge is this (1361 in this case, which likely is value when all those conditions are met,
[Nexus One Android Development] theloginwithnoname:
It does - it is the FULL_40 value Pre and the HTC code refers to. This will get re-set if we can do the calibration thing. Then we should be able to rely just on the battery reporting full or not.
[Nexus One Android Development] RogerPodacter:
i just cant quite figure it out. i know that "range is shifted" theory doesnt really make sense. but for some reason i'm determined to correlate the <80 mA with our battery-reading-jump/die-too-early problem together.

so if we removed all those conditions and just left the ds2784 dictate when the battery is full, i found the following from the ds2784 data sheet:

and more importantly for our die-too-early problem:

finally, the data sheet confuses me, because it states that CHGTF = charge-to-full. but then it refers to it as charge termination flag. the latter makes much more sense, considering our latest driver code is:

/* shut off charger when full:

* - CHGTF flag is set

*/

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

di->status.battery_full = 1;

charge_mode = CHARGE_BATT_DISABLE;

} else

di->status.battery_full = 0;

i guess "chg to full" and "chg term flag" mean exactly the same thing. but based on above code and the data sheet's wording, i think it is termination flag, so in our code its saying STOP. therefore i would love to be able to read what value is set for VCHG (charge volt) and IAVG (current avg) are actually set to in the register.

also i found that average current looks like its averaging from the last 28 seconds:

so we might want to make sure we see 2 consecutive readings before we kill charge, to add stability (though i'm sure we're done at this point, pershoot i think is using the final version most likely).

anyway i'm trying to figure out why my battery can be incorrectly shutting down early (at 10%, 200mAh remain, 3.4 volts). re-reading the data sheet really has a lot of info to pick up on...

EDIT: i'm completely wrong on my lame theory. reading ds2780 and maxim application guides, everything is explained in extreme detail, inclluding active empty vs standby empty and why our batteries die before reaching 0 mAh. i'll drop it now:)
[Nexus One Android Development] pershoot:
my battery stopped charging (was at 10% when plugged in, and at 67%, stopped). a phone call came in and it jumped it back to starting again.

ill amend the code a lil later and we can test.
[Nexus One Android Development] RogerPodacter:
We probably should add the condition that it must be <40 for two consecutive readings in a row. This help erratic dips etc.
[Nexus One Android Development] dvgrhl:
Do you have an idea of what caused that condition, or where you are thinking of making adjustments?

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;
}

Nothing there would seem to account for you being able to stop at 67% charge. It would seem like you had a situation where battery_adjust_charge_state() somehow stopped being called. Or, maybe somehow you hit a condition somewhere else where charge_mode got set to CHARGE_BATT_DISABLE, like a temperature condition.

Maybe we should add in something like this:

if (di->status.percentage < 99) {
if (di->status.charge_source == SOURCE_USB) {
charge_mode = CHARGE_SLOW;
}
if (di->status.charge_source == SOURCE_AC) {
charge_mode = CHARGE_FAST;
}
di->status.battery_full = 0;
}

because it seems like even if di->status.battery_full = 0, if charge_mode = CHARGE_BATT_DISABLE then the battery won't charge. Does that seem correct?
[Nexus One Android Development] RogerPodacter:
Pershoot can you post the log for that shut down? It may have been some completely random and unrelated circumstance. Or its another bug that was there all along.
[Nexus One Android Development] RogerPodacter:
I found out why our battery jumps during a full charge, as well as where the <80 mA requirement came from. I won't clutter anymore, but a lithium ion is considered charged at C/20 or in our case 70 mA (however 80 was used if you refer to the below links).

So I'm wondering if we should just left it the way it was, as the estimated mAh and percentage reading is given with that value assumed. Though there's no harm leaving it, but could make our percentage meter off even more.

Also, loginwithnoname, we can find the value to set the learn flag, take a look at the links (we need to drain to active empty at whatever temperature we're currently at).

Also explains how our calculations are being made. Also shows how the register values are written and associated values for different battery ratings.

It's all pretty interesting, but do you guys think we should just leave it alone? Take a bit to read if you have time.

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
[Nexus One Android Development] theloginwithnoname:
I would suggest a few things to do with the existing code:

update the code to one if else statement as above

reduce the threshold to 20 or 10

use current_average *and* current uA values for check - i.e. add an additional condition thus: (( current_avg_uA <= 10 && current_uA <= 10))

before declaring the battery full, make sure we see the full condition twice - i.e. set a "full_count" as per code at

http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/power/ds2760_battery.c

code from line 249.

is for readability

is to see if we can squeeze some more juice out of the battery, as the 10 threshold is used for other batteries in the 27xx family

is to use a more complete/thorough check

is to ensure blips are dealt with

I believe this would give us the best and most-consistent charge levels. Though I would install this code onto my device in a heartbeat, I am unfortunately at the mercy of a kind kernel compiler at present - I will hopefully be in a position to compile on Tuesday.
[Nexus One Android Development] Lazat:
Hi guys! thanks for your awesome work with trying to fix so the battery can be charged up to higher levels then 1361 mAh! :)

i get up to 1372 mAh with your kernel pershoot. after that OS-logger report that batt charge off. and i havent had any problems with that the charge stops around 67% or something.

i also have a little question to you pershoot, is it best (for battery life) to use interactive or ondemand governor with your current kernel from droidbasement?
[Nexus One Android Development] dvgrhl:
I don't know if there is any definitive answer to this (and I would actually like to see some experimentation done to support the different cases), but I have found on demand to be the best setting for my use.
[Nexus One Android Development] pershoot:
ondemand. havent tweaked interactrive much.

pls dont flash the latest as of now. need to fix up some things and ill refresh it and you can dload it.
[Nexus One Android Development] pershoot:
<=20 is too low. we tried 20, and it was acting quite bizarre. i think 40 is fine (for now), but it can be reworked some to provide for more consistency.
[Nexus One Android Development] theloginwithnoname:
Out of interest, who (apart from yourself, pershoot) had issues with 20, and for those of you who did, what issues did you see?
[Nexus One Android Development] pershoot:
scroll up in the thread. RP posted the log from the event. its a lot of pages up tho. ill see if i can grab it in a bit.
[Nexus One Android Development] dvgrhl:
Is there a reason you don't make ondemand the default mode instead of userspace?

Also, did you ever figure out why you stopped at 67% charging?
[Nexus One Android Development] pershoot:
no reason at all. been meaning to change it. it was carried over from the cm stock config.

going to charge back up as im almost at 10, and will try to reproduce it.
[Nexus One Android Development] RogerPodacter:
If you want to test more of the <20 mAh I would do it. I should have prefaced my only result I posted for that one was testing with a car charger since I was out, and it does not provide as much current, causing dips in current_mA. Average current could fix that. I think that result was very linear till the end when the phone rang and tripped it off.
[Nexus One Android Development] RogerPodacter:
Man there is just really something wrong with the way our batteries read percentage and mAh. My battery still dies at 10%. I've been pushing it everyday now to see. After reading those 4 links I posted few days ago I'm pretty much an expert with maxim/Dallas fuel gauge chips, quite literally. Every single thing is explained with demonstrations and examples. And I really don't necessarily agree with some of the way they do things with our battery. Whatever, the learn function is what we desperately need.

Also once we get read write access to the registers, we can go to town. We won't need pershoot to edit the driver, we can change the terminating current in the battery itself. Right now the <80 mA comes from the battery itself, we are overriding it in our updated driver. But we can edit the register number itself. We also can and should change the terminating voltage as well, just bump it up slightly to 4.191 volts. Currently its just too low to me.

I just ordered a new HTC battery today since I had 20 dollar free amazon gift card. I'm debating on how I should first charge it up.

I also think we have the same cell pack as the mugen 1400 battery, as pretty much every palm pre user shows 1363 mAh for rated capacity. I think ours are over rated and we have the same one. For my usage, I have 200 unusable mAh at the lower end, and at least 50 mAh unusable at the top. It's unacceptable.

How in the world does the iPhone 4 get such good battery life with only 1430 mAh battery?maybe its the lithium polymer difference? Very impressive.
[Nexus One Android Development] ram130:
I say give up. Guess what guys I got 1580mAh today!!:eek: Felt like doing my thing to the battery since the situation presented it's self. Anyway I took some screenshots and played with the phone for 30mins and after 1hours I'm still at 100%. I'm gonna upload the screenshots(cause logs are editable) as soon as my battery reaches 95%, I'm curious at what % it's gonna die at this time.

btw, this is using my own charging method. Well kinda :cool:
[Nexus One Android Development] RogerPodacter:
the problem with doing the bump charge for me is that my phone actually dies at 17-18% doing that, rather than 10% with a regular charge. the numbers assigned to the ds2784 are screwed up and should be changed, and learn mode turned on. but i agree, its just a fun project to mess with:D.

i ordered a new battery from amazon yesterday! i'm gonna bump charge it to 5000:)
[Nexus One Android Development] ram130:
Here are the pictures:

Just turned on the phone:

After some mins of playing with it:

After an hour:

After two hours:

and finally lost a percentage lol:

And FINALLY after 8 hours:

Sorry for the long post!!

Yes I think your right about that. I didn't get to catch at watch percentage my phone died, but last time I checked *about 20min before it died* it was at 23%. If you guys are wondering, I teetered the rest of the battery away lol about 2hrs or so..

I'm gonna try this again tomorrow and this time note at what percentage it shuts off at.
[Nexus One Android Development] theloginwithnoname:
it will stay at 100% whilst > 1360 - this has been stated before. I expect it to go to 99% from around 1348.

Are you intimating that your method of charge has caused this massive capacity?

If so, I'd appreciate you repeating your method on your next charge. If you can repeat, definately post your top figure and your method.
[Nexus One Android Development] theloginwithnoname:
Build progress

Just a quickie to say, had lots of problems with my dev build under Slackware. Persisted with it until I got into an X11 build cul-de-sac!

Completed a bare build of Ubuntu last night and left it bringing the various required packages down, so hopefully will have something that builds CM6 today.
[Nexus One Android Development] theloginwithnoname:
Quick update on my device. The past two times when I have let the battery drain right down, it seems to be powering off as it hits 6% - this is above 3400mV and the last time was on ~90mAh. 6-7% is "better" than the 10-11 it used to be. Just an obervation.

From a charge perspective, last night when it died, I started an off-charge and charged overnight. This morning it's "full" charge was 1267. If I was speculating, I may suggest that this could be my new upper capacity after I hit the learning function on the battery (1267 is 90.5% of 1400, which would be an appropriate age ratio for the battery after nearly 8 months).
[Nexus One Android Development] RogerPodacter:
Yes you're exactly right. I posted 4 links before, it seems our get full40 value is 1369 at 40 celsius, 1361 at 35c, etc. These numbers are coded during manufacture and setup of the battery and not changeable.

However that bump charger is in fact doing something as the ICA current accumulator is in fact registering that extra current being put into the battery.

I re read the palm pre thread and they too have the problem where their phone dies too early, at 18%. Mine dies at 18 lately too. They say the battery meter is lying. My friend with his palm pre today said his died at 30 percent. The learn function is what fixes it.

The pre's learn mode flag gets set at active empty which is 3.4 volts cutoff. Problem is I can never get there before shut off. They temporarily raised under volt to 3.41 to trick learn mode to turn on. Back to needing register values.

Read those 4 links, you'll then be a complete expert with these batteries:-)
[Nexus One Android Development] RogerPodacter:
Ah yes, I agree. We've seen the battery jump. Those links I posted explain what happens during a complete discharge and complete charge. At empty, the active empty is set to zero, and at full charge the full point is set to getfull(temp) which is why it jumps to 1361 etc which is our pre programmed getfull number. Like you said, our true full is the before jump number, 1200 something.

This is the capacity our battery can actually hold now.
[Nexus One Android Development] ram130:
Yes exactly, it's kinda of a know method but I modified it a bit. Now when I got up I turned on my phone, charge a lil to my threshold and turned it off and bump charged it. Turned it back on and it was at exactly 1360mAh.

my method is this:

1. Charge battery upto 100% while off.

2. Turn on and let it discharge to 90% exactly.

3. Turn off and charge for 20min

4. Wait until you see green(exactly on time)

5 Unplug

The mistake I did today was let it go down to 89% and bump charge it. Apperently that was what cause the 1360mAh and not the 1500mAh I'm looking for.

Anyway, guys I have a theory. Maybe this bump charging method is actually pushing back the current in the battery making the phone think charge is added when its actually not. That 18% it cuts off at might be the 18%(in my case) 1587mAh the phone rated it at. So in case, it's actually still 1400mAh if I'm calculating right, it's just 18% off in telling you the percentage. Anyway gonna try bump charging again and see what percentage it shuts off at.
[Nexus One Android Development] Markdental:
Oddly enough, I was using pershoots kernel and one day it let me get to 1389 mAh, now it won't let me get past 12xx. No idea why.

I have a feeling that even if we can get our batteries up to 13xx mAh, that they will dies at 15% vs 5%, so either way we only have the same total % use available over the total spectrum.
[Nexus One Android Development] Markdental:
Oops, stupid computer
[Nexus One Android Development] theloginwithnoname:
kernel compiled!

OK ladies and gentlemen, I have finally got a build system and have fastboot boot'ed a kernel I have just compiled (nice to have your username/hostname in Settings/About ;))

With any luck it has the logic I referred to in post #477.

I am going to run my current capacity/charge right down to see if, based on my findings from my full off-charge this morning, the battery goes down past 6%.

I will then fastboot this kernel again and on-charge it all the way up, and report back with my findings at the end of the charge.

p.s. this is the "stock" kernel that comes with CM6, with just the charging logic modified.