yashsingh1/xdaforums huggingface dataset:
[HD Mini General] munjeni:
Ok, I'm going to explain, first this:

Yes, the values ​​change with changing temperature, you are totaly right, but if you see pwel values is so close to w_values. important thing is that we have a formula that follows the Windows value! Just only need to make corrections to the level? But, hmm, if we use azXX values and his full battery 70%, what will be if his battery display 100% and after 2 minutes 60%? I think its real to use real battery level bassed on my level_table based on voltage! Why it must be 100% if battery voltage is not 4200mV? Understand me?

I think also!

no, I have snow in refrigerator! My phone during test was in refrigerator and battery was directly in snow!

I forgot to say that I left the phone after the fridge for a while to settle down, so I put it in the oven at a high temperature (>>40c), from there I got a value of over 55c. I produced this totally unnatural, and therefore the voltage began to rise after putting the phone in stove! In conclusion I can say that the voltage is smaller when the temperature is low and voltage increases with increasing temperature. I think batteruy.dll have no control over the battery , and I think battery.dll is used as a "read-only battery", but that control is exercised by the processor! Do you want to enable gpio charge, and I will test whether charging will be stopped. Do you have idea how to test it without risky?

your sdcard is renamed to sdcard2. Delete sdcard2 and turn=off your sdcard and turn on after 10-15 sec
[HD Mini General] pietje63:
PICS!!!111

But this is standard science: when temperature is higher batteries give more power.

If it's cold your battery will stop working earlier.
[HD Mini General] pwel:
the minimum from the data I looked at is 3600. I made an overview of data from raphael, data proposed earlier by cardsharing and a new proposal:

--	cs%	cs V	new	raph %	raph V

cri	1.5	3400	3400	1	3400

low	6.5	3615	3600	11	3600

min	19.5	3680	3850	26	3700

mid	40.5	3750	3950	39	3735

med	57	3815	4000	57	3800

max	76.5	3950	4100	86	4000

full	100	4155	4200	100	4140

see the line in the attached plot
[HD Mini General] schlund:
temperatures below 0°C and higher than 45°C can heavily damage your li-ion battery!

if you play around with those temperatures, take care that your battery is not fully charged or discharged.. (~40%)
[HD Mini General] munjeni:
Yes Schlund I know that, also I know it is fatal for the chipset and if they are sudden temperature changes, but I did it and I think I will not again:D

Now we have all the parameters, only remains to put them into practice!

Edit:

Please, what you mean by rawcurrent?
[HD Mini General] -r0bin-:
lol you're crazy :D

but useful anyway, we see we need a temp correction

this sounds good but what is the lastest correction? the last two columns?
[HD Mini General] pwel:
no, this is not the case. So this does not help
[HD Mini General] pwel:
sorry for the confusion:

the correction is the column with the header new: it starts at 3400 and ends at 4200:

-- % new

cri 1.5 3400

low 6.5 3600

min 19.5 3850

mid 40.5 3950

med 57 4000

max 76.5 4100

full 100 4200
[HD Mini General] munjeni:
I think its not ok! Please back to the values ​​azXX. If you use his full battery (70%) and his voltage (examle) (3940), and use your correction:

- mid	40.5	3750	3950	39	3735

- max	76.5	3950	4100	86	4000

his battery level will be displayed 40.5% or raphael 39%!!
[HD Mini General] pwel:
what do you mean with this? That the wTemp from the log file is incorrect?

I can see from this data that specifically the data at high temp deviate from the previous model. So if wtemp in the logging is ok, you can adapt your table according to your log file
[HD Mini General] pwel:
I agree, but his battery seems to be strange/bad(?) anyway, so why bother if not ok?

Also for bruce and r0bin (who are on the top side of the curves) there will be a big difference with windows: when windows says 20%, this model says 60%. That's because there is so much spread in the data: we cannot find one formula (yet) that covers all curves. But at least it seems to be covering the 100% region and 0% region quite well.
[HD Mini General] pwel:
this is the current calculated via my formula: that is able to go below 100mA, whereas windows cuts it off at 100mA.
[HD Mini General] -r0bin-:
regarding those value differences, i believe this shall be handled somewhere by the windows driver with min and max values stored in memory.

i have the feeling VREF, halfVREF and rID should be usefull in this case.

but i cant understand yet how VREF could affect the computed voltage yet
[HD Mini General] munjeni:
ok, I agree completely (if pwel_wCurrent == 0 -> battery is full)

About r0bin battery_charge_survey:

- his first value is:

0 10 236 3655 -165 265 1421 2849 0 243 1238 615

-last values is:

30833 100 245 4211 100 275 1374 3285 578 74 1238 615

- if you compare first volt value (3655) with my level_table, its 32%

- if you compare last volt value (4211) with my level_table, its 100%

My opinion:

- I think his battery was recovered before he joined AC charger, it is clear that the charge start from 3655 wVolt.

Pay attention to the following:

- use my charge and discharge survey

- first use discharge survey and look for wVolt when my phone was shutdown!

- open charge survey and look for first wVolt value

- what you see? I think my battery is also was recovered before he joined AC charger! I'm right?

How we will solve this, hmm, I dont know, but maybe from this way:

- example:

if (pwel_wcurrent > 100) use_level_table;
else level_table_bassed_on_pwel_current[ pwel_current ];

level_table_bassed_on_pwel_current = array(0=>100%, 10=>90%, 20=>80%, 30=>70%, 40=>60%, 50=>50%, 60=>40%....etc etc);

this is only idea, I dont know how we will make it for "marketing reason" to display azXX value as a 100%, understand me?
[HD Mini General] munjeni:
Ok, we have one big problem: what will be happen if azXX battery not reach pwel_wCurrent=0 ?? If battery is not controled by procesor, his battery will explode :eek: I do not know how we will prove this! Maybe:

The only way is risk. We need to enable pwel_wcurrent on android screen, and azXX need to strict concentrate on the screen and pwel_current value, if value is not going to 0, he must to stop charging manualy!

Other:

although, I think his battery at one point reached pw_curr=0, I think charging was stopped, but from some time was gone to discharging! I think r0bin need in his program to add another set where to display whether the charging is enabled or not. I forgeted where is memory addrese for detecting ac, only know it is after 0x0fffc000, I think r0bin know where is, or maybe add gpio value or something where we know when charging is active or not because his program working after full charge and is not stoped (maybe we see last values from discharging?)

Edit:

I have idea for level compute, example:

- if on battery:

function percentage($value)
{
$minv = 3300;
$maxv = 4000;
$vrange = $maxv - $minv;

if(isset($value)) $vtt = $value;
else $vtt = 0;
if ($vtt < $minv) return 0;
else if ($vtt > $maxv) return 100;
else return ((($vtt - $minv) / $vrange) * 100);
}

- if on AC:

function percentage($value)
{
$minv = 3700;
$maxv = 4210;
$vrange = $maxv - $minv;

if(isset($value)) $vtt = $value;
else $vtt = 0;
if ($vtt < $minv) return 0;
else if ($vtt > $maxv) return 100;
else return ((($vtt - $minv) / $vrange) * 100);
}

Need correction for minv and maxv
[HD Mini General] az35:
I can put my phone in a tupperware box, and observe :-)

Anyway I confirm that my battery has some problem: I can't charge it to 100%

anymore. If you want I can log battery charge again, eg. for one night, and see if the battery reaches pwel_wCurrent = 0 or not.
[HD Mini General] munjeni:
az35 do you see green led after full charge??
[HD Mini General] pwel:
Another strange thing I noticed: your charging current (wCurrent) goes below 100mA. For some other people, this happens every now and then in a spike, but yours just continues down to 32mA. I don't understand this at all?

In addition, MQD's data does not show any decrease of charging current, even at 100% level. Although his data reaches only 4100mV, so maybe he has to charge longer to see current going down?
[HD Mini General] munjeni:
that is why I suggest somehow to try to insert into r0bin program one column where we know exactly whether the charging is in progress or the charging is full (example: green led or red led), if is possible. If not possible, we need new log for az35 and MKD data_charge_survey (and confirmation that the green led is shining!). Maybe their battery.dll is different from our (new or older):confused: In any case we must not ignore their batt value
[HD Mini General] pwel:
I just noticed I can't run any .exe or instal .cab files from my resco explorer. it does so from the built-in explorer though. Will reinstall it.
[HD Mini General] -r0bin-:
i think so, az45 you should try to charge longer and see what happens.

as long as you see a current value not equal to 0 (or negative) you can continue to charge. dont worry the charge will stop when batt is full.

what ROM do you have? which country?

was it working before?

maybe if you try to upgrade your battdrvr.dll with the latest one, you would get better results.
[HD Mini General] -r0bin-:
do you have the win32.dll with my app?

otherwise i have no magical rod for that, it looks like memory corruption :-/
[HD Mini General] -r0bin-:
my program does not control charging process, it just read values.

charge stops automatically when battery is full.

you can check my battery charge log:

i reach the maximum of my battery.

then, the raw current is equal to 0, charge stops, thus phone run on battery.

some time later, battery discharge a little (because phone is running) and charge starts again until reaching full batt.

(see enclosed pic)

that's why it's safe to ask az35 to perform a longer charge on his battery (stay all night) because on your last graph, i can see he kept charging only 2hrs45 !
[HD Mini General] munjeni:
r0bin, please reread my post, I think you not understand me what I tried to say for your program. I was say (I sugested for this): if is possible to read with your program for example led status (when green lamp is on or when red lamp is on or for example: when charging is in progress or when discharge is in progress), do you understand me? precisely, I do not know exactly when the charging process is interrupted, so I thought if it were possible to add something to read for example when charging is interupted
[HD Mini General] -r0bin-:
no i dont know how to read status of the lamp, but in case you didnt noticed, the green light is displayed as soon as windows displays 100%

charge continues slowly in background

so, if you read my previous post, the only true indicator is the raw current charge. when equal to 0 charge stops. and my app displays raw current. so you have your indicator
[HD Mini General] munjeni:
ok I understand it but what is raw current, you think pwel current or?
[HD Mini General] munjeni:
please confirm
[HD Mini General] -r0bin-:
raw current is named "rCharge" on my app.

to have an idea of real current value you can use pwel algorithm, but when it is 0, it is 0, no need extra algorithm ;)
[HD Mini General] munjeni:
ok thanks but please be precize next time
[HD Mini General] Ciccius:
slightly OT (it's mostly a my curiosity ...)

well, I don't know how windows (or android) works in this case but, when the device is charged while it's turned off, what device's component check the battery charge?

I mean, some OS module works in backgroud or the charge state is controlled by an hardware component?
[HD Mini General] -r0bin-:
next time you are allowed to use your brain a little more :D

otherwise i found a great website regarding li-ion charge and why windows displays 100% earlier:

http://batteryuniversity.com/learn/article/charging_lithium_ion_batteries

in our case, windows driver uses "extended life" and does not charge upon saturation. in android, we can choose to charge our battery longer for better performances, but lifetime will be reduced.

that's probably the case with our HTC phone

Now regarding battery capacity:

i guess they mean that, reading voltage when battery charge is not accurate, thus its difficult to read the exact capacity when charging.

good to know we are allowed to be wrong :-)

Regarding battery aging:
[HD Mini General] pwel:
I believe that charging stopping can be seen if you record the curves long enough: see r0bin's data: at some stage far after 100%, the voltage drops shortly (because charging stops), and shortly after that it increases again (charging starting again). I did a similar charge now with a lower current and see the same; also my wVolt vs wPercent curve looks very like my previous one. So indeed I believe there is some parameter that is different for each phone that plays a role. I attached my latest plot with wCurrent, and the values from my formula: you see current going negative when charging stops and going back positive when it starts again. So the calculated current is a good indicator, but you could get it from rCharge and or rDischarge too. Indeed, rCharge becomes 0 and then the current becomes negative (due to my formula). Apparently, the battery itself tells when the charging is stopped and current inverses automatically. The current at it stops charging is not constant: every next time, the current decreases a bit: 1st at 26.3mA, then at 19.0mA, 16,7ma and 15.7mA. So absolute current is not an indicator to stop charging.

I also added the wVolt vs percent plot: this time, my wVolt started lower: I paid more attention to draining the battery completely. You see my curve is similar to my previous one: though it moves earlier to the bruce/r0bin line (70%).
[HD Mini General] -r0bin-:
yes, but see my previous post:

we don't want to charge completely the battery, because battery lifetime will be reduced!

i suggest we keep on the windows behavior (display 100% when current goes below 100mA and voltage to its max)

then it means every time you charge your batt, and if you use AC or USB, the curve is different :-/

maybe instead of using voltage to determine battery percents, we could use the current over the time?
[HD Mini General] -r0bin-:
heeyyy that's pretty accurate!

i tested it on pwel, munjeni, r0bin, az35, bruce, ismail

everytime, when windows displays 100% i have counted 1100mAh in battery!

i think we have a working algorithm for charging :)

but now we need an accurate algorithm for discharging, let's see if we can use voltage...
[HD Mini General] munjeni:
Yes I use my brain but we do not read minds...is not difficult to be precise, right:cool:

Agree obout your constatation "current over the time"

Maybe we use ( percent_current_over_a_time + percent_bassed_on_voltage ) / 2
[HD Mini General] pwel:
The only problem I have with current over time is that it depends on the state you are in when charging is started. You could use the percentage at that moment, but it is not precise at all. I think i did it before, but aslo with big spread. But anyway, I will also give it another try. For my curves I have 1070mAh and 1250mAh.
[HD Mini General] munjeni:
I think you are right. Example: how we calculate percent based on current_over_time if charging is started for example at 60% of battery?
[HD Mini General] -r0bin-:
if you start charging at 60%, 720mAh remains in the battery at this moment (60% of 1200 = 720)

so you only need to charge 480mAh to have full batt (1200mAh).

but we dont want full batt because we lose battery lifetime, so we charge to 1100mAh, so we count 380mAh and we declare the battery 100%. easy.

How to count mAh in my log:

- take one windows charge current (wCurr), it is instant current, and you have the time in seconds on first column

- now take the next line's time (in seconds), it gives you the time in seconds you got this current.

- the gain in mAh is: (wCurr*(Time-nextLineTime))/3600

Compute this for each line and add to the previous result to have the current capacity. if batt percent is 5%, start from 50mAh. if batt percent is 10%, start from 100mAh.

now the only problem is, we need to have accurate algorithm for discharge.

and we still have variations of up to 200mV between users :-/

i'll check raphael algorithm, it look simpler when discharging.

edit: see curve of mAh vs windows percents in attached pic
[HD Mini General] pwel:
I thought I understood it but apparently not: when you continue charging in windows (like r0bin and myself did), at some stage, the rCharge value returned from the chip drops to sero, indicating that the charging stops. I thought this was a value given by the chip, and not set by ourselves? is that not directly protecting the voltage from going too high? Won't we get the same in Android, that rCharge is protecting us from too high voltages? I would say that wVolt and wCurrent are not used to stop charging, only rCharge is.

Please correct me if I am wrong.
[HD Mini General] pwel:
I integrated the wCurrent data of r0bin and myself and plotted it vs wPercent. See attachment: it is indeed on a straight line! And the offset maybe due to different starting situation: I completely drained the battery before charging.

I will continue analysis but this is hopeful
[HD Mini General] munjeni:
Yes this is totaly hopeful and I agre but (next time you are allowed to use your brain a little more:D) we not know what is current percentage!:) I used robin log, charge started at 10%. If I understand r0bin say when it is 10% it is 120mA/h right? Ok. Next. Based on r0bin log and time step of 30s I created this for test:

$overtime = 120;
if ($rCharge != 0)
$overtime += ($wCurrent*30)/3600;

First line of your log (becouse is 10%) = 120mA/h, line when charging is stoped (rCharge=0) I got current=1279mA/h. I dont know how you got 1100mA/h

Update:

I got it working with our if-else statement, but current (mA/h - upper value) = 1300mA

if ($rCharge != 0)
$overtime += ($wCurrent*(30))/3600;
else if ($rCharge == 0 && $wPercent > 90)
$overtime = 1200;

Here is link
[HD Mini General] -r0bin-:
nice webpage!

well first of all you can count on windows to give you values that are not accurate. when you see 10%, you have to understand it can be a value between 7,5% and 15% (because steps of 10%).

secondly, some values are wrong because windows don't count below 100mA (you know, when pwell current says "30mA" windows count 100mA, thus value is lower).

but even though, if you take your webpage, you will see im right: when windows shows "100%" then you have ~1120mAh

what you don't take into account is, the real current at the end of charge is lower than 100mA, that makes capacity lower.also, you should stop charging when you first reach 1120mAh, which is 100% in windows scale.

there is no secret, current is associated to percentage, pwel confirmed it too.

now the thing is, we must work on an accurate discharge algorithm, that will give us accurate percentage.

like this we will be able to have the complete algorithm, even better than raphael and topaz one.

but just a reminder, because it seems some people dont understand:

REMINDER: what the driver do

- battery driver enables/disable charge when cable is detected

- battery driver read voltage, current, temp from battery chipset

- based on those params (volt, curr, temp) the battery driver compute capacity of the battery in percents (%)

REMINDER: what the driver don't do

- battery driver do not control how battery is charged, it is done by hardware

- battery driver do not control how current is sent to battery, it is done by hardware. or maybe there is a "slow" and "fast" charger, but that's all

- battery driver do not switch off android when batt is low. Android does it.

- battery driver do not stops charge. Maybe Android does it when driver says "100%", maybe charge continues like on windows

Most of the complicated stuff (current alimentation, temperature control etc) is done by hardware

see we don't have much to do :-)

and the charge will stop by itself when battery is full, because there is a hardware protection against this (battery could explode otherwise)

warning, you have those mecanisms in geniune HTC batteries, but if you buy a low cost battery i wont guarantee this statement ;-)
[HD Mini General] munjeni:
Ok I updated and updated logic for stoping charging

if ($rCharge != 0 && $wCurrent != 100)

But what about percentage, percentage is big problem now becouse percentage is needed for "current over time"!!!

Also

How we will stop charging to increase battery life time? GPIO disable charging? I think battery driver stop charging! Also we dont know what is done by driver until we make first driver and try

What you think about this:

10677 100 243 4215 100 273 1386 3288 344 77 1238 615 26 232 4215 100 enable 1176mA
10707 100 243 4191 100 268 1384 3267 0 75 1238 615 -54 233 4188 99 disable 1200mA

I think rCharge is not indicator to stop charging, I think this is indicator only for: "charging was disabled !!!"...see wVolt value!

no, pwel value current is 100 == wcurrent is 100, see your log from my link, you will see it
[HD Mini General] munjeni:
r0bin, there are unused addresses in SMEM! Please pay attention to this two pictures

http://img225.imageshack.us/img225/4645/50762394.jpg

http://img90.imageshack.us/img90/5738/97124428.jpg

From pictures if you see, we use only blye line (bat_id, bat_temp, bat_volt, bat_charge, bat_discharge)

but if you see red line, (we not use these addresses from SMEM for our driver!)

maybe it is in conjunction with r_id...etc etc?? For example for percent calculation!?
[HD Mini General] pwel:
I hope it is the case! Although the integration of current gives a nice linear relationship with the percentage, it remains an issue that once you start either charge or discharge, you need to determine the start percentage. and that should be possible from the battery data. I don't think the latest known percentage is stored in the phone?
[HD Mini General] munjeni:
just that!
[HD Mini General] -r0bin-:
:-( sorry to dissapoint you, but those values are used for DEX calls (see msm_proc_comm_wince.c)

we have similar mapping than Raphael, see here:

http://htc-linux.org/wiki/index.php?title=RaphaelMemoryMap

i searched a little bit if this value could be somewhere on smem but so far couldnt find it.

but don't worry, i have good news, i fine tuned the raphael algorithm, and it shows very good results for discharge.

now im working on temperature correction, and thanks to your data survey at 10°C in the freeze, i will build a nice algorithm :-)
[HTC Inspire 4G] cdogg44:
I've had my HTC Inspire for two months after switching from a Blackberry for several years prior. So far the phone is great, but I am having a problem with "Messages" and "MessagesCS" running wild and taking over the phone.

I have had Watchdog Lite installed since almost day one and am consistently getting alerted at least once per day (usually 3-4 times) that one of the two programs are using over 50% of my cpu (50% is where I set my threshold limit to alert me).

I uninstalled Watchdog as an experiment, and it was still happening and required me to reboot my phone to get it to go away.

I am new to Android and have bone stock phone. I have installed a few apps but nothing weird.

Please help me with this problem as it can be very frustrating during the day.

Thanks!
[HTC Inspire 4G] psyc0:
ive never seen that one....had sys idle ...but from what i understood that the percent is just the overall percent that that 1 app was using of the battery since last boot...dosent nessesarrly mean that its drainin that much battery thatts just whats usin it....but i may be wrong
[HTC Inspire 4G] cdogg44:
I'm not talking about battery usage, I mean CPU.

My phone usually gets noticeably slower, sometimes to the point of where it won't do anything, and Watchdog Lite alerts me that either "Messages" or "MessagesCS" are over their 50% cpu threshold I have set for alerts.

Sometimes it just alerts me when the phone is idle and I have to go kill one of the two programs. Already happened 3 times today...

Please help.

Thanks!