yashsingh1/xdaforums huggingface dataset:
[HD Mini General] munjeni:
Ok, I started new battery driver project here -> https://github.com/munjeni/photon-battery/commits/master ,I analysed aria dmesg log and found interested thing: aria use values for battery from smem same as photon, but for level and cable update aria use rpc call . So I want to create new battery driver and need your help. First I need all algorithms colected in one post: formula for raw smem values, formula for voltage, formula for current, formula for... etc...etc
[HD Mini General] pwel:
in principle, the algorithm I used uses a factor of 0.27 where you use 0.32. I will add that to my fitting parameters. But I am quite convinced the windows battery driver uses the segmented approach that I used. In the end it will not matter much. Indeed it would be good to apply some more refinement like you suggest, to get rid of the peaks in the percentage vs time plot.
[HD Mini General] munjeni:
Project deleted, Schlund found rpc server for battery... waiting him to give me more infos
[HD Mini General] old.splatterhand:
Does this mean you dont need recorded data?
[HD Mini General] swissly:
munjeni, are you in contact with schlund? Is he still around? His thread seems to be dead...

What does rpc server mean? Will this be a perfect solution for the battery?
[HD Mini General] munjeni:
Yes that is perfect solution... but Schlund not responding to my pm (maybe is busy)... I'm still waiting... he say he found rpc server for photon (we can read directly battery level, voltage, current, vbus...etc without needs for algorithms).
[HD Mini General] munjeni:
EDIT:

ok I found an interested irc log and found (vbat_read() rpc 30000005 that exist in photon) http://irclog.netripper.com/htc-linux/786/ so maybe rpc 300000005 will give something for battery... I never played with rpc calls but I will try to understand how it working or if it is possible to call from an native android application (system/bin/xxx) for example to create an simple aplication that will be ussed to send call to rpc and read back response from him... is it possible ?
[HD Mini General] old.splatterhand:
And does he share this with us or is he still working on it? :confused:

We all hope to get this project finished with a happy end!
[HD Mini General] munjeni:
He found rpc servers but I found nothing there about battery... Allso I think he stoped working on photon like all other devs... but why you not ask him?
[HD Mini General] munjeni:
Found wince aplication (rpcinfo)... if someone want to try this app on wince and try, maybe app give info for battery rpc server !
[HD Mini General] old.splatterhand:
Flashed back to WM, but i not really know what to do.

I started the arm version, but in the upcoming window i cant really do something. Its showing me "localhost" and thats all.
[HD Mini General] mqd:
Salut Robin

voila mes logs

merci pour tout ton travail et bonne chance pour la suite
[HD Mini General] Smudoooo:
here are the new files.
[HD Mini General] pwel:
hi Smudoooo, how did you set your mini during discharge? I see you had a discharge current of 440mA which was about 2x higher than mine; I had wifi on, backlight on at 100%, BT on and opera running.
[HD Mini General] yowojtas:
ok here is main file of discharge. The charging i'll give you at wekend. I tested it on wifi on and i have been watching two movies to discharge the battery.
[HD Mini General] Smudoooo:
hi pwel.

when you start a navi software and search for satellites with gps, that drains the battery very fast
[HD Mini General] Ciccius:
here are my data.
[HD Mini General] -r0bin-:
thank you all for your help i'm impressed to have so many results :-)

i think i have enough data from now on

now need to find the magic formula

i already have ideas, but if you are good in mathematics, you can help me too, i'll explain you how:

the idea is to make the raw values (named rVolt, rTemp, etc) match with the windows values (wVolt, wTemp, wCurrent etc) because we dont have the algorithm.

so i need to find this problem:

wVolt = rVolt * (???)

wTemp = rTemp * (???)

wCurrent = rCharge (or rDischarge) * (???)

normally, the ADC_REF value is used in the computation

this is the first step.

then second step is to determine on which cycle we are of charge/discharge to determine the correct percentage. but for this i already have an algorithm.

if you think you can help don't hesitate :-)
[HD Mini General] -r0bin-:
for example, i have wVolt=4042 and rVolt=3148 (Vref=1237)

i found this from raphael driver, gives an approximates result:

adcvref=(vref*4096)/1250=4053

wVolt= (rVolt*adcvref)/3156 = 4043, almost 4042

this formula gives good results for all the values of the file i was analysing.

there must be simpler ways ;) but im not expert in maths

edit: see in attachement results of formula, not bad :)

(i made it with excel)
[HD Mini General] Ciccius:
i don't know nothing about these values and i need some instructions. please be patient. :)

i created a datasheet where i'll write down the formula but i need to know if the numeric values are constants or values written only as example values.

obviously, I refer to the values highlighted in red, blue and green:

adcvref=(vref*4096)/1250=4053

wVolt= (rVolt*adcvref)/3156= 4043, almost 4042
[HD Mini General] pwel:
tried that, but did not get more than 280mA whereas you showed 440mA? I guess it may depend in situation and the specific software type. At least I am glad it is not draining as much as yours;)
[HD Mini General] pwel:
linearity of wVolt vs rVref*rVolt

I took all data I found with the 1.1 version of RoBin's programme.

I plotted wVolt versus rVolt*rVref. See the graph attached. It seems there is some spread in the data. The behaviour is linear. charge and discharge curves always fall on the same line. For all curves, the slope is similar to what robin suggested: 4096/(1250*3156)=1.038E-3 is within 5% for all data (min-max): lowest value 1.013E-3 for MQD and highest 1.062E-3 for bruce. The value Robin reported is exactly in the middle. However, there is like an offset of 200mV between the extremes of the data (mqd and Bruce).

I also plotted wTemp vs rtemp: data is nicely on one curve, but it is not straight; it fits nicely with the following parabole (red line): wtemp=788-0.603*rTemp+0.00015289*rtemp^2.
[HD Mini General] yakamoz:
pwel, could you please publish your excel-file?
[HD Mini General] pwel:
no, it is not in excel, it is in Origin. Much easier to make these plots and fits
[HD Mini General] MobileMini:
Just something I thought of while looking at the plots, it could be complete nonsense what I am saying :).

Could the differences in mV be because of the differences in battery quality? Not all batteries have the same age, which could lead to different discharge behavior between batteries of a few months old and batteries that are over a year old. Also the temperature differences can lead to differences in discharge rates.

Maybe it is handy to specify how old the battery is, or how many charge/discharge cycles it already has had in its life and specify the temperature.
[HD Mini General] -r0bin-:
warning, there is a parameter that is supposed to be unique for each device: you must update the vref in formula it *could* be more accurate (1237 was ismail, its 1222 for bruce and 1251 for mqd, etc)

yes, either batteries have not same age, or batteries are different (different brand?) or chipset that calculate the battery voltage is not accurate.

yeah your algorithm gives good results

i had one like this: wTemp=(-rTemp/3)+670

it is more simple, but i didnt tested yet with all values to validate it. and maybe i should include in the formula the "vref" value that changes for every phone.
[HD Mini General] bruce2728:
My phone is 11 months old and still has original battery
[HD Mini General] pwel:
deleted due to confusing content
[HD Mini General] -r0bin-:
how did you computed those different values?

they are supposed to be provided in the logs (see vref column)

there are so many values, tell me which ones :)
[HD Mini General] pwel:
r0bin, sorry to confuse you (and myself too); I will remove the previous mail because it is too complex to explain; this mail will fully replace it.

I did a linear fit, neglecting the fact that the rVref value is constant.

I have done it again: according to your formula, the linear prefactor should be:

4096/(1250*3156)=1.0383E-3

I did linear fits of all data (y=a*x+b) and this is what comes out, you still have to divide them by 1000 to arrive at the above value. So you can see that your formula predicts the data well, it is right in between the two extremes:

mqd discharge	1.013121

mqd charge	1.013666

pwel charge	1.016138

pwel discharge	1.016894

yowojtas discharge	1.021656

15MA1L charge	1.034649

smudoooo charge	1.035356

15MA1L discharge	1.036678

smudoooo discharge	1.041753

Ciccius charge	1.043129

Ciccius discharge	1.043775

bruce2728 charge	1.058021

bruce2728 discharge	1.062319

the thing I don't know how to handle is the offset: because I fitted with an offset (b in y=a*x+b), whereas your formula does not give it (y=a*x). If one would force the curve to go through zero, the values change a bit, but less than 1%. I will still work that out.
[HD Mini General] pwel:
I can now confirm: using a fit while forcing point 0,0 on the line (y=a*x) gives the same results as using the off set (y=a*x+b). Therefore, the lines with a slightly larger coefficient (like bruce's) lay a bit higher, and the ones with a lower value (like mqd's) lay a bit lower. On average, alle lines lay around the value predicted by r0bin. Can we therefore conclude that the formula he proposed will be correct for general use?
[HD Mini General] pwel:
I added your linear fit (blue line) to the plot where I had the parabolic fit (red line). You can see there is quite some deviation in the lower temperature range. If it is easy to implement, the parabolic one is preferred: wtemp=788-0.603*rTemp+0.00015289*rtemp^2.

But I just took one curve that was in the middle, I could also put all points by all contributors on a heap and find the best average value to be used. Will do that later.
[HD Mini General] pwel:
r0bin,

do we need a similar exercise on wCurrent vs rCharge and rDischarge?
[HD Mini General] pwel:
I have discovered something more: I looked at the relation between the slope of the wVolt curve shown before and rVref. It appears that for small rVref (like Bruce's 1222), the slope is large (1.06E-3) and if rVref is small (like mqd's, 1251) the slope is small (1.01E-3). This means that if you plot wVolt vs rVolt*rVref as I did, the spread is enlarged. If you plot wVolt vs rVolt, there is much less spread (100mV iso 200mV). I don't know what the impact is yet. Any idea?
[HD Mini General] -r0bin-:
yes, that would be great!

i think having 10+ data survey samples like we have is enough to validate an accurate formula.

you seems to have a very good knowledge in statistics, therefore if you found a better formula, I'll be glad to implement it in the driver.

To be honnest, I took VREF into account because it was made so in the Topaz/Raphael driver, so probably it was used in the windows DLL.

But if your formula don't use VREF and has a better result, then I don't see why we should not use your formula and kick VREF out :-)
[HD Mini General] munjeni:
I understand all of your logs because is totaly linear, but.... see this, this is totaly not-linear.

How I got this values? I got this using crontab and some kernel code "line 1491" adapted to catch values at same time after dex call. Maybe help you in future.

How to setup crond

#!/bin/sh

export PATH=/bin:/system/bin:/xbin:/system/xbin
cronn=`which crond`
crontabb=`which crontab`

echo "root::0:0:root:/data:/system/xbin/ash" > /etc/passwd
mkdir /var
mkdir /var/spool
mkdir /var/spool/cron
chmod 755 /var
chmod 755 /var/spool
chmod 755 /var/spool/cron
ln -s /sdcard/crontabs /var/spool/cron/crontabs
$crontabb -c /sdcard/crontabs /sdcard/crontabs/root
$cronn -l 0 -L /sdcard/crontabs/cron.log -c /sdcard/crontabs

How I catched dmesg with smem dump:

#!/bin/sh

export PATH=/bin:/system/bin:/xbin:/system/xbin
dmesgg=`which dmesg`

tt=`cat /sdcard/dmesg/start.txt | awk '{print $1+1>"/sdcard/dmesg/start.txt"; print $1}'`
$dmesgg > /sdcard/dmesg/dmesg.$tt.log

start.txt

1

/sdcard/crontabs/root

*/13 * * * * /path/to/script
[HD Mini General] pwel:
bingo! If I plot wVolt vs (rVolt/rVref) all points fall on 1 line!

Formula : wVolt=1587.1*rVolt/rVref

Maybe the 1587.1 is again some product or quotient of some integer numbers.
[HD Mini General] -r0bin-:
great!

if we could have the same for current, that would be awesome!

Regarding the formula for temperature, here is what they say on the driver:

in order to save the CPU time (many operations), they used a pre-computed table with pre-defined temp values, we could do the same since temperature is not really critical in the percentage formula.
[HD Mini General] az35:
hi all!

And thanks for the great job you're doing!

I see you have enough data, so didn't post my battery logs. Tell me if you're interested in some more inputs.

Anyway I checked (using excel) pwel's formula for wVolt and indeed it works great!

For wCurrent : wCurrent=(-0.7)*rDischarge

is quite accurate.

Regards,

Az.
[HD Mini General] -r0bin-:
yes i'm interested :)

i uploaded my charge log.

interesting to see that:

- phone is considered as "fully charged" once wCurrent is equal to 100mA.

- windows declare it "100% charged" a little bit before this step

see also visually the charge log, very interesting to analyse.

i will do the same for all the logs i have later on.
[HD Mini General] munjeni:
Ok, thanks, your work is great, I'm regards all your work! I'm updated page and I see "Battery info" is totaly linear like values from wince, but I have one quostion for you if is posible you reaply me. If you look in htc_battery_smem.c and

line 1482

and

line 1491

Who raw data from printk line 1482 and data from printk line 1492 is different but is got at same time? Is raw data from line 1482 raw data from smem, or is corrected from formula? Specifically, the value obtained from printk line 1482
[HD Mini General] az35:
here are my logs.

BR,

Az.
[HD Mini General] -r0bin-:
correct SMEM value is line 1482

thanks, but your charge log stops at 70%. the most important is to see when the charge stops to better calibrate the percent indicator.

discharge is good :)
[HD Mini General] munjeni:
Ok thanks, another question. Is it values "from line 1482" are totaly raw "directly from smem", or is it corrected with some formula or some another function? Please be precise, thanks!

Another. Maybe gpio for enabling charge is 44, see this

-> Creating node list
-> Update uses and definitions
-> Live register analysis
-> Finding DU chains
-> Data flow analysis
Basic block list:
10006a70 sub_10006A70:
10006a70 R1 = 0x1bfe2e8;
10006a74 R0 = * R1;
10006a78 R3 = * (R0 + 0x41c);
10006a7c R2 = R3 - 1;
10006a80 Cond = R2 - 4;
10006a84 if (Cond > 0) goto loc_10006AFC;

10006a88 /* Low-level instruction of type 44 */

10006a9c loc_10006A9C:
10006a9c R2 = 0x44c;
10006aac * (R0 + 0x458) = R2 | 0xe10;
10006ab4 * (* R1 + 0x420) = R2;
10006ab8 return R0;

10006abc loc_10006ABC:
10006abc R2 = 0x546;
10006acc * (R0 + 0x458) = R2 | 0xe10;
10006ad4 * (* R1 + 0x420) = R2;
10006ad8 return R0;

10006adc loc_10006ADC:
10006adc R2 = 0x866;
10006aec * (R0 + 0x458) = R2 | 0xe10;
10006af4 * (* R1 + 0x420) = R2;
10006af8 return R0;

10006afc loc_10006AFC:
10006afc R2 = 0x4c4;
10006b0c * (R0 + 0x458) = R2 | 0xe10;
10006b14 * (* R1 + 0x420) = R2;
10006b18 return R0;

Running The Desquirr decompiler plugin
-> Creating instruction list
10006B20: Analysis: Instruction Type 5
10006B20: Analysis: Instruction Type 6
10006B24: Analysis: Instruction Type 6
10006B28: Analysis: Instruction Type 6
10006B2C: Analysis: Instruction Type 6
10006B30: Analysis: Instruction Type 6
10006B34: Analysis: Instruction Type 6
10006B38: Analysis: Instruction Type 6
10006B38 - using conditional: 12
10006B3C Warning: label without name
NOTE: created new label loc_10006B3C
10006B3C Warning: label without name
NOTE: created new label loc_10006B3C
10006B3C: Analysis: Instruction Type 6
10006B40: Analysis: Instruction Type 6
10006B44: Analysis: Instruction Type 6
10006B48: Analysis: Instruction Type 6
10006B4C: Analysis: Instruction Type 6
10006B50: Analysis: Instruction Type 6
10006B54: Analysis: Instruction Type 6
10006B58: Analysis: Instruction Type 6
10006B5C: Analysis: Instruction Type 6
10006B60: Analysis: Instruction Type 6
10006B64: Analysis: Instruction Type 6
10006B64 Unhandled instruction
ea=10006B64, [color=red]itype="ADR" (44)[/color], condition=E
Operands[0]={type=o_reg, dtyp=2, reg/phrase=R3/3}
Operands[1]={type=o_imm, dtyp=2, reg/phrase=PC/15, value=268462960}
10006B68: Analysis: Instruction Type 6
10006B6C: Analysis: Instruction Type 6
10006B78: Analysis: Instruction Type 5
10006B78: Analysis: Instruction Type 6
10006B7C: Analysis: Instruction Type 6
10006B80: Analysis: Instruction Type 6
10006B80 Unhandled instruction
ea=10006B80, itype="ADR" (44), condition=E
Operands[0]={type=o_reg, dtyp=2, reg/phrase=R3/3}
Operands[1]={type=o_imm, dtyp=2, reg/phrase=PC/15, value=268462988}
10006B84: Analysis: Instruction Type 6
[HD Mini General] az35:
yeah I know! for some unknown reason I can't charge more than 70% (sometimes 80%). Probably need to calibrate the battery (if it's possible with a Lithium battery)
[HD Mini General] pwel:
I made plots of wCurrent vs rDischarge for the discharge curves and wCurrent vs rCharge for the charging curves. See images. We still need to sort out how to handle them, it is more complicated than for wVolt. There does not seem to be a fixed reference value.

I also plotted the charging curves vs time and there seems to be a quite some different behaviour which also makes the wCurrent vs rCharge curves unclear. There is a difference in charging current. Could that be due to the type of charger used?

I looked into the formula but cannot make something of it easily. So if a lookup table is the easiest, we better do that
[HD Mini General] -r0bin-:
based on the current driver we use, here are the formulas:

htc_adc_range = ( ( VERF + 1250 ) * 4096 ) / 2500;

if using AC-charger:

wCurr = (((rCharge*2600)/htc_adc_range) * 10) / 55

if wCurr > 240 then wCurr = wCurr + 250

if using USB charger

wCurr = (((rCharge*2600)/htc_adc_range) * 10) / 55

if running on battery

wCurr = (rDischarge * 2600) / htc_adc_range

this is to be adapted of course. maybe we could take into account that:

rCurrent=rCharge-rDischarge

another reflexion is, at the end of charging, windows says wCurr=100mA while rCharge=0, so there must be some special cases.

the idea is to find a formula for the most cases, and fine tune for the special cases.
[HD Mini General] -r0bin-:
I insist, it is totaly from SMEM

we already use GPIO 44 for charge detection, and dont worry I have other gpio values to enable charger.

I dont want to activate charger now because the battery driver needs to be calibrated: if you don't stop the charger at the right time, your battery can explode.

just be patient...
[HD Mini General] pwel:
Great! I will work on them later tonight.
[HD Mini General] -r0bin-:
look at the pic enclosed:

it is very clear how charge works.

initially, you put the maximum of current to fill the battery up.

then, when reaching 70%, the amount of current slowly decreases until reaching a minimum of 100mA, indicating that battery is full and cannot take more.

(current is in purple, percent is in blue, temp in red and voltage in green)
[HD Mini General] pietje63:
This does make sense. In practice I notices many times that you can quickly charge your battery for a day-use (60%), but it does take 2-3x more time to fully charge the battery.
[HD Mini General] pwel:
But if you look at my previous post, there is a big variation between the various users?
[HD Mini General] munjeni:
hmmm, I do not understand why because hex showing cid ... etc correctly, which means that the hex is properly read and written to the log, but ok thanks in any way!

ok thanks
[HD Mini General] -r0bin-:
lol that's interesting

can you also draw charts with the windows values?
[HD Mini General] munjeni:
I do not have time right now but I will try tomorrow. Simpler way - I will create function to export it to excel, if you want, tomorrow?
[HD Mini General] -r0bin-:
thanks but you don't need a function for that:

just copy and past in a new excel sheet, and call the function "text to columns" with space as a delimiter: it will put all the values in columns

select your data and click "draw chart", it draws it also :)

but it takes time to configure chart for each data survey
[HD Mini General] munjeni:
ok I'm working now with draw chart
[HD Mini General] pwel:
I still don't see how to fit all data with the present formulars. I can only start looking at it again on Monday night.
[HD Mini General] munjeni:
Have problem with arithmetic function "tried to create imput box for formula input - inserting formula you want - on the fly" but this is hardest part, but ok i will try to find solution :)
[HD Mini General] -r0bin-:
thanks

but if its too complicated dont worry we will manage without ;)

ok thanks

on my side i'm going in vacations for one week without access to internet, ill analyse this again in one week :cool:
[HD Mini General] munjeni:
yes, it is difficult to make logic, but am going to do it. Currently I made multiple chart, next, trying to add support for multiple persons log and imput for formula.

Some interesting things about wCurrent/rVolt - rDischarge/rCharge, chart from it is totally paralel, this is formula for wCurrent from that !!:) Please see discharge LINK

About wTemp. If you see table for wTemp and rTemp you will see:

- if rTemp value is biger, wTemp value is smaler

- if rTemp is smaler, wTemp is biger

I think formula is very hard, only lookup table will fix temperature dilemma! I will create lookup table from 30-41 c as a example from values we have

Update:

I have good news, I'm finished lookup table for battery temperature (from +63.7C to -10.5C) , please see and correct me if I'm wrong, I think this is OK! LINK

Algoritam is inside this code, maybe you create formula without using lookup table. Deviation of temperature values is +- 0.1C :)

<?php

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

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

}
print_r($temp_table);

?>
[HD Mini General] munjeni:
Edited batt driver, code cleaned, tested, working great! If you want to see battery status just dial *#*#4636#*#*

Source changes:
[HD Mini General] superzuan:
just copy to sd card??
[HD Mini General] munjeni:
No, this is source
[HD Mini General] pwel:
munjeni,

I added your table data to my rTemp vs wTemp plot. See attachment, green line. Specifically in the middle section e.g. rTemp=1000 I see deviations: your table says 352 but from the data it seems more like 340 which is 12 deg difference. Did I do something wrong?
[HD Mini General] munjeni:
Hi, so you can not put it in the plot because its lookup only table, see link from previous post, you will see how it work. We not need formula if we use table!
[HD Mini General] schlund:
i think what cardsharing is trying to say is, that he is taking hardcorded table instead of a formula. Correct me if i am wrong, but i think its not a valuable table from photon ?
[HD Mini General] munjeni:
Yes its hardcoded table, please use logs survey, you will see its a totaly ok, but there is a slight deviation

+-1C, but i think we will not get any better than this! Also I'm compiled kernel with this changes and temperature working good! Lookup table. Also, we can change the multiplier with a mean value until we have an ideal table!
[HD Mini General] pwel:
No, Schlund is right, I (not Cardsharing) used your table: I took one of the columns and added that to the plot I made before: and you can see the deviation: the green line comes from your table, the red line from a parabolic fit and the blue line from a linear fit. If you want, I can update your table based on the formula I used to get the red line? So look at the point where rtemp=1000. Check your table and look at my graph: you see 12 degrees difference