yashsingh1/xdaforums huggingface dataset:
[HD Mini General] pwel:
munjeni, could you clarify what you believe is the formula that relates wCurrent to rVolt, rDischarge and rCharge? So far I have not been able to produce any combination that gives me paralel lines. Also, I wonder what the rID column from r0bin's program give me? That seems quite paralel to wCurrent, but not fully. Do you have any idea?
[HD Mini General] schlund:
340 (wtemp) to 352 is a difference of 1,2 degrees.. as far as i know :)

personally, i could live with that. but dont how how important it could to be for calculating other values
[HD Mini General] munjeni:
ok, that I made ​​in relation to log we have, but it is not 100% accuracy, but you have to admit that the very approximate value, right? It is easy to get 100% of true value if you modify the table generator, for example "please look in my php code":

<?php

$temp_table = array();
$c=4;

for ($i=0; $i<=2600; $i++)
{
$c+=4.00045;
$number = 638 - ($c / 14);
$temp_table[$i] = number_format($number, 0);

}
print_r($temp_table);

?>

or

<?php

$temp_table = array();
$c=4;

for ($i=0; $i<=2600; $i++)
{
$c+=4;
$number = 638 - ($c / 14.000765);
$temp_table[$i] = number_format($number, 0);

}
print_r($temp_table);

?>

Understand me? My effort was 70%, but values is good in any way, right? +2C or -2C is not big diference :)
[HD Mini General] pwel:
sorry, missed that 'detail':D

so the whole story is less of an issue. Still I would go for something that is average of all data we have. I will use the table as munjeni's data, that is then the highest we have so far! So maybe his current data may be interesting too. Munjeni, can you publish that as .txt?
[HD Mini General] munjeni:
txt? Why, you have array of this data, use any text editor and preg_replace data you no want with empty

For wCurrent i'm trying some tests, not 100 posto sure, but interesting thing is how chart is paralel for discharge, if you see + zone ($rDischarge/$rCharge) and - zone ($wCurrent/$rVolt)! There is a connection between all this, but hmm...maybe this formula?

$rDischarge/$rCharge)-($wCurrent/$rVolt) = X

or maybe

$rDischarge/$rCharge)-(X/$rVolt) = $wCurrent :confused:
[HD Mini General] pwel:
ok, I am also trying: it seems like wCurrent =A*rCharge-B*rDischarge work quite well for a single data set. Will try on more tomorrow.

Do you have any idea what rID is for?
[HD Mini General] munjeni:
hmm not have idea what is... I have to analyze. Also if you see what r0bin say about 70% and rest until 100mA, and you put charge data in my chart you also will see paralel data to 70% and "not paralel" after 70%...

Update:

Maybe we use "example formula" $rDischarge/$rCharge)-($wCurrent/$rVolt) as a control way to switch code to "fine charging after 70% (see not paralel chart) until it reach 100mA"!?? Some interesting things is inside:confused: This is mine opinion and is only one example!
[HD Mini General] pwel:
It seems we are on the right track: fitting the data with:

wCurrent=A*(rCharge-B*rDischarge) gives good results with the same fitting parameters (within 3%) for 3 datasets so far. I will continue with all the others and report it tonight.
[HD Mini General] pwel:
-

So here it is: I fitted all data with the formula: wCurrent=A*(rCharge-B*rDischarge). I averaged all values of A and B and I arrived at: A=0.237017

and B=3.025134. Then, I recalculated the fitted values of wCurrent for all datasets (just took the above formula, the above numbers, and for each set its own rCharge and rDischarge column) and plotted these values against wCurrent. This should be a straight line 1:1 and indeed it is, both for charging and discharging curves! Only some points are not on the line: the discharge curve of AZ35 does seem to give some hickups, but that data itself seems to be jumping up and down a bit. I added that wCurrent and fit curve vs time. Arrows indicate where the fit is a bit off.

These points still bother me, as does the fact that rID is not used, neither rVolt and or rVref. But nevertheless, it does not look too bad.
[HD Mini General] munjeni:
Pwel, I think your formula is ok! I will try to analyse with example before posted, maybe I will see something. Also our battery driver use the average of six values ​​obtained from one cycle, I think it is irrelevant if a some value deviates! See, I added your formula LINK , looking totaly great for discharging, for charging also, but maybe we will use "kill charging" at 1.85022959937 value, or maybe 0 :)

Robin, do not misunderstand me, I regarding all your work, what we talked about "raw smem" I think you are wrong, it is not the raw data because it has already made ​​corrections by this function, I'm right?

htc_raph_batt_corr
[HD Mini General] pwel:
Munjeni, I have difficulties in understanding your link! It asks me to paste something in the field: what should I paste? I only have the output as generated with r0bin's program, but if I paste that, it does not accept?
[HD Mini General] munjeni:
Paste, for example all values from battery_data_survey_charge.txt and delete first 2 lines

RefTime= 9:27:19
Time wPercent wTemp wVolt wCurrent rID rTemp rVolt rCharge rDischarge rVref rHalfVref

becouse words is not accepted, only numbers is accepted!
[HD Mini General] pwel:
Indeed, my formula is only valid for wCurrent>=100. If it ends below, wCurrent remains 100mA.
[HD Mini General] munjeni:
Ok, if you see its ok to 90%, and this is what r0bin say "until 100mA"! Also, when you look at the table colone obtained from your formula, you will see that there is some logic to stop charging when the value 0 or maube 2:)

Now we will use:

$punjenje = values_from_your_formula;
if ($wCurrent < 100) $wCurrent = 100;
if ($punjenje == 0) kill_charging

This is only example code and my idea!
[HD Mini General] superzuan:
you guys are very smart. when i look at al that numbers i don't have any idea where you guys are talking about. thumbs up great job.
[HD Mini General] pwel:
Just found one possible source for deviating data points: the discharge data by AZ35 does very often show two points within 1 second, whereas the normal time spacing is 30s. And most of the deviating points are in these points close together. So far, this dataset is the only one that does it. Also his charging curves are clean, with nice points every 30s.
[HD Mini General] munjeni:
Ok, thanks!

I'm finished temp_table and I could not get it beter. Only got deviation < 1C. I'm tried to increase table from +80C to -20C but without sucess LINK Maybe I will add support to +80C but we dont have log data with rTemp negative value, also I think we not need temperature > 63C!
[HD Mini General] munjeni:
Yes, I implemented this, tested, working great! Now, I'm trying to implement fomula for wCurrent and wVolt and waiting r0bin to enable charging, I think it is more accurate and faster than...

I think battery will be completely fixed when r0bin come from weekend!
[HD Mini General] pwel:
I am traveling right now. Will check before the weekend. Will let you know!
[HD Mini General] munjeni:
Ok. I have problem with this:

buffer->batt_vol = 1587.1 * buffer->batt_vol / batt_vref;

but if I use this I have no problem compiling:

buffer->batt_vol = 1587 * buffer->batt_vol / batt_vref;

Anyone know how to compile with numbers like 1587.1 or 55.1775...etc:confused: I know that is easy to define but I'm not c coder
[HD Mini General] pietje63:
I'm no c coder as well, but maybe the variable is defined as an integer and 1587.1 is not an integer?

Or maybe you should use 1587,1?

Just some wild guesses.
[HD Mini General] pwel:
you could do 15871/10 or 551775/10000, then it is all integer?
[HD Mini General] utsavkoju:
Here 1587.1 is not an integer in c programming. we cannot define decimal number with integer. you should use float or double for declaring them.

EXAMPLE

int 55

float 55.1775

double 1587.1

note:

double and float can be used for the same for this case but int can't be used.

just try it and let me know if you have got any problem.
[HD Mini General] pwel:
munjeni,

it seems the relation between wVolt and the percentage depends on other factors too; see the plots I attached. The line represents your table. I believe r0bin mentioned before he knows how to calculate the battery percentage. So let's wait for him to return in the weekend?
[HD Mini General] munjeni:
Ok guys, thanks, I think some guys lost his battery cappacity, I created this bassed on empty_battery=>3420mV and full_battery=>4200mV, this is only my opinion, maybe I'm wrong, but this is real and linear based on voltage(empty-full), understand me? For wCurrent I think also your formula is 100% ok and we need to kill-charging if wCurrent is 0 becouse your chart and my table show that! Here is modified code if some of you is interested to see....in any way I will wait r0bin and other guys for their opinion

Update:

Kernel compiled, voltage displayed ok, but current is not, only I see for current current=0, and nothing after comma

Update:

uf, something is wrong with kernel becouse I made it quick and sure I did something wrong in batt code
[HD Mini General] pwel:
I tried a view things: it seems that if you integrate the current over time, this is more or less linear with the percentage. Maybe we have to look into that direction?
[HD Mini General] munjeni:
rVolt has something to do with all that, I just do not know what. Also not know what is rId
[HD Mini General] munjeni:
Maybe this code without using table?

typedef unsigned char u8;
const double minv = 3420.0;
const double maxv = 4200.0;
const double vrange = maxv - minv;

static u8 get_batt_level( struct battery_reply *buffer )
{
double vtt;
vtt = (double)buffer->batt_vol;
if (vtt < minv) return 0;
else if (vtt > maxv) return 100;
return (u8)(((vtt - minv) / vrange) * 100);
}
[HD Mini General] pwel:
first for r0bin! we are glad you are back, hope you had a good time and a refreshed mind!

then about the charging:so far with all the formulas, we had a good match with all data using a single set of parameters. if you look at the wvolt vs percentage plot, there is a huge spread (10%). Also, the remark on 70% does not seem to match the data. Unless the effect of temperature is very large. I will check tomorrow. I don't feel comfortable yet
[HD Mini General] -r0bin-:
unfortunately, this is not so simple :)

yes, but keep in mind that windows only have steps of 10%

yes we need to accomodate the formula. but looking at the current charge, you can see windows declare the phone charged 100% even thought the current is higher than 100mA! definately not accurate.

i spotted on the WinMo driver the code responsible to compute percentage from voltage/current/temp. it's quite complex, i dont know if its easy to translate to linux, ill check that later
[HD Mini General] munjeni:
I think this steps is "only" displayed under screen, but windows have steps of the 1%!

Other, I think battery is controled by itself and-or by procesor and we only need is: "read smem values like r0bin-battery-loger-program" and "to kill_charging in proper time" and we need to try from this way:

- property read "raw" smem value to example array with 5 keys "0=>rBatt_id, 1=>rBatt_temp, 2=>rBatt_volt, 3=>rBatt_charge, 4=>rBatt_discharge becouse something is wrong with this!

- use pwel formula for wVolt, example: wVolt = (15871 / 10) * array[2] / raw_smem_batt_vref;

- use temperature table for temperature

- use pwel formula for wcurrent, example: wCurrent = (237017 / 1000000) * ( array[3] - (3025134 / 1000000) * array[4])

- becouse we have pwel line chart and mine value table "see last pwel line chart on page 9" you will se for charging that line chart display: "if current is 0, battery is full"! My opinion for wcurrent is: we only need for charging, to kill charging if current is 0 (see my last link with pwel values - page 9!)".

It would be good if r0bin put pwel formula into his program and to verify the accuracy of formulas for volt and current.

I'm tried to get temperature value and I got it with deviation +-1C, and I would like if I knew how to make other changes to code but I'm not c programer to be able to implement pwel formula, but from line chart i understand how it works! If what we have done is not true, I really understand nothing. I just want to point out what Pwel and I was concluded, please don't misunderstand me!
[HD Mini General] _Madmatt:
Robin, could you post the WinMo code here? I know C# and it's family of C++ so I'd like to take a look. For the implementation, I'll however need you because I don't know what to do with the code. Can you maybe give a short explanation on the variables used in Android too?
[HD Mini General] -r0bin-:
there is no winmo code. there is only disassembly code (asm) that you can get using IDA Pro on our battdrvr.dll

implementation in android is not an issue, the issue is to find one algorithm to generate the battery percentage like done in Windows:

that's what we are trying to do :)
[HD Mini General] munjeni:
Another opinion, see this link.

If you see, his battery is full at 70%:) . I think mine calculation for battery percent (only idea) is ok, maybe I'm wrong, but the fact is that it is based on the volt principle of full-low battery like 4200mV-3420mV. His battery stop charging at 70% becouse his battery have lost capacity (mV)

Also if you use his battery_charge.txt and use his battery last volt value (70%) and compare with mine level_table, you will see

[4011] => 76

it is 76%, becouse windows have level step of 10% this is displayed as a 70%
[HD Mini General] munjeni:
Ok, I created complete battery logic. It is bassed on all formulas we have, also added logic if (wcurrent <= 0 && percent > 20) stop charging! Please see link hdmini.webhop.org/bat
[HD Mini General] pwel:
I looked through the battery code at http://87.238.52.168/linux-on-qualc...778fa4600ff2572211bc32f05629a4151784557/diffs but I can't seem to make any logical formula for the mini out of it.

We can do 2 things:

1) wait for the perfect formula that suits anyone

2) go for a more simple formula (like munjeni's) and try to improve later on

What do you think? I still have 2 questions on this topic: 1) what is needed to make charging absolutely safe? So do we need to input a level at which it definitely stops charging 2) what about the level during discharge? How do we define the level at which the mini switches off?
[HD Mini General] munjeni:
I think we need only wCurrent for stoping charging, but simple we will add (if wvolt > 4210) or 4200...I dont know what is critical up level value for wvolt- not analysed this! Definitely if we use pwel_wcurrent <= 100, I think it is a safe! We can also add logic (if the temperature exceeds (example) +50C or +55C, stop charging (or pause charging until temperature <50 0r <55)

this is so simple (we analyse from logs what is critical down value for wvolt)
[HD Mini General] -r0bin-:
guys, i will tell you something:

we do not really control when charging stops.

there could be two options, i dont know which one is true yet:

- EITHER we do not control when charging stops, it is done by chipset

- OR when the driver says "100%" then android calls the driver to stop charging

same thing happens with the discharge:

- when the driver says "there is only 5% remaining" then android will shutdown handset

that's why we need to be really accurate on the percentage and not provide an algorithm that is not really accurate.

munjeni, your algorithm is good for one particular case, but if you use your phone below 25°C, or above 35°C it wont be valid anymore. that's my worry.

we have the algorithm for raphael, just need to calibrate it and it should be enough i think.
[HD Mini General] munjeni:
No r0bin, please, if you see values is with different temperature and are quite equal with windows values. Did you see my link? Did you paste battery_charge_survey.txt data in imput? Only level differs becouse I use 3420 as a empty constant

Pwel is tried it but line chart is not ok! Also I think raphael algorithm is too complicated and I think it is unnecessarily complicated.

Ok, i will put my phone in refrigerator and will turn on your program, we will see if it values differs...someone must do this hehe :)
[HD Mini General] munjeni:
Ok, here is mine battery survey. Pay special attention to the temperature obtained from temp_table, FACT that the refrigerator temperature is 3 or 2 degrees Celsius!! See the value of data with a temperature difference of 45 degrees from totaly full battery to totaly empty! For our test, I think that is enough! I'm increased percentage calculator:

function percentage($value)
{
$minv = 3400;
$maxv = 4200;
$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);
}

Now my opinion:

- shutdown phone if wVolt < 3400

- temperature given from temp_table is more precise and more realistic than the one in Windows!

- pwel formulas is totaly great:)

- I think we have different battery.dll (different rom), (different shutdown voltage from different battery survey, right?)
[HD Mini General] -r0bin-:
ok i went deep inside the raphael algorithm

this is a lot of code for not a lot of things :D

in a few words:

- they use voltage to determine batt percentage (similar to munjeni algo)

- when charging, they remove ~100mV to the voltage before computing percentage

- when running on battery, they add a "resistor discharge" that is added to the voltage before computing (related to the discharge current)

volt_discharge_resistor = ( abs( ccurrent ) * batt_param->volt_discharge_res_coeff ) / 100;

- if temperature is below 25°, then apply a correction that is removed to the voltage before computing

temp_correct_volt = ( temp_correct_volt + ( ( batt_param->temp_correction_const * ( ( 250 - temp ) * abs( ccurrent ) ) ) / 10000 ) );

- they have various protections to avoid high computation differences (like going from 60% to 30% in one second)

so its seems easy to do it, and simplify the code.

my only worry is, every battery sample we retrieve has different voltage values...

its difficult to build a universal driver since everybody has different battery values!
[HD Mini General] munjeni:
Are you tried all battery_surveys here? => hdmini.webhop.org/bat I think we not need voltage correction bassed on temperature!

battery 1.5 years old and battery 0.2 years old is big diference. If you see user azXX have broken battery (with capacity of the 70%, also something with his battery is not ok becouse his line chart display total nonlinearity). I do not know what would be happen if the azXX battery went up to the pwel_wcurrent <= 0 :confused: but if pwel_wcurrent <= 100 i think is ok and safe
[HD Mini General] Ciccius:
can we post our battery age so we can use this parameter to understand why the voltages are so different.

mine is 12 months old (june 2010)
[HD Mini General] _Madmatt:
Posting battery ages won't help, because a battery can be 6 months old but only charged twice a week, or it can be 3 months old and charged 3 times a day (on very intensive use). Battery 2 will be more broken than Batt 1, but however it is "younger".
[HD Mini General] munjeni:
Hey r0bin, see mine battery charge survey, wCurrent is reached value 100 and is constantly 100 from 80% to 100% of battery capacity :confused: This confirms the inaccuracy of the theory for Raphael wCurrent= 100

Maybe battery is controled by itself or by procesor?
[HD Mini General] pwel:
Maybe you are right munjeni. I remember from the earlier days we had difficulties in finding the chip that should give us the battery data. So maybe things are quite different in the mini than in the rafael.

I also looked through the code as r0bin did: all corrections are around 10-20mV whereas the differences between curves become as large as 300-400mV.

So in this I agree with Munjeni that I don't see the link between the data and the Rafael code.

So I did another analysis of the data, now also including Munjeni's.

First I kicked out the data of AZ35 and MQD: AZ35 did not reach more than 70% and MQD did not show any current decrease during charging although the battery was full. In included the resulting plot in this post (percent vs wVolt).

My observations:

1) the charging always ends at wVolt=4200 (and 100%)

2) the start of the curves is not well defined; maybe this is due to a different situation at the start of charging

3) the traces towards the end point (4200mV 100%) is different, but several are very similar:

- bruce's and r0bin's start at higher voltages and are quite similar.

- 15ma1l's and munjeni's start at lower voltages and join the first 2 at around 70%

- ciccius's does the same but joins only at 90%

- Smudoo's and pwel do the same but joins only at 100%

- AZ35 (not in plot) follows ciccius/pwel and smudoo but stops at 70 and shows a lot of noise on the data

-mqd (not in plot) remains below all lines up to 100%

So there is some communality/grouping of the data. I don't know the reason yet; maybe a difference in USB charger / AC charger? I did mine with USB. What about the others?
[HD Mini General] munjeni:
There are certain things in all this that confuse! If you open my data charge survey, you will see: wvolt is 4200, wcurrent is 100 and percentage is 80% (where is logic?)! Only good thing is wcurrent from your formula because it is close to 0. I think battery.dll is not perfect and that a little cheating values!

I used computer usb for charging!
[HD Mini General] Ciccius:
I charged with USB, too. Tomorrow I'll collect the charge/discharge data again with the same load than my previous survey but with standard AC charger. May it help to compare the data?
[HD Mini General] -r0bin-:
of course battery.dll is cheating a little!

for example, at the end of charge, it wont go below 100mA, even though the raw current is going below.

you can really see the moment the battery is full, the raw current is equal to zero.

this is the REAL indicator.

but maybe for marketing reasons, or for users ease-of-use, they choose to display "100%" even though the battery is not completely full, so that users think battery is full faster.

i think we can take the minimum battery voltage (3550?) and 4200 as minimum and maximum values, and use a bit of raphael algorithm:

because the charge curve is not linear, they define 6 points (critical, low, mid, med, high, full) on the charge curve, and emulate the curve with 6 linear lines. this way it is more accurate.

i need to analyse a little bit more the algorithm, but we are close to have a first clean version :-)

munjeni, what did you said about temperature, does it affect your voltage or not?
[HD Mini General] -r0bin-:
mine is done with AC charger.

easy to determine:

with AC charger, you get max current = 850mA

with USB charger, you get max current = 350mA. also some computers can deliver up to 650mA.
[HD Mini General] -r0bin-:
dude, first of all the refrigerator temperature is 4°C to 10°C

secondary, your phone produces temperature!

it is possible it heat a lot depending on the usage (specially if reception is bad in the freedge) and the temperature gauge is inside the phone!

i checked your log, you can see that, when temperatures goes from 10°C to 55°C, your voltage goes up! (to 3664 until 3825)

which means, if I follow your formula, you will display 60% then 70% while your phone is DIScharging ???

im afraid we need a temperature correction :-/
[HD Mini General] pwel:
my previous curve was with with USB, but not on a computer, but on my alarm clock. right now it seems that the higher voltage curves are done with AC and the lower with USB. So this looks like a parameter in the model. I wanted to re-run the program with AC charger; but the program does not run anymore? I get a message with a lot of squares, also somewhere reading: this program cannot be run in MS-DOS mode. Can you explain that r0bin? Of course I re-downloaded it, with no success.