thunderysteak has quit [Ping timeout: 260 seconds]
akossh has quit [Quit: Leaving.]
thunderysteak has joined #maemo-leste
uvos has quit [Ping timeout: 268 seconds]
SuperMarioSF has quit [Quit: Client closed]
<Wizzup>
uvos: heh ok my d4 still had the pa echo cancel loaded, hence the power draw
<Wizzup>
somehow the gst stuff also pulls elogind it seems
<Wizzup>
I guess we'll just have to switch...
<Wizzup>
ah no, it's gvfs
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #maemo-leste
thunderysteak has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 260 seconds]
SuperMarioSF has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
buZz has quit [Remote host closed the connection]
norayr has joined #maemo-leste
joerg has quit [Killed (lithium.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
thunderysteak has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
mardy has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
Twig has joined #maemo-leste
norayr has joined #maemo-leste
<freemangordon>
uvos: PR is fine as code, but does not follow the coding style of the library. I will fix that, but please, next time try to adhere to coding style of the code you are fixing.
norayr has left #maemo-leste [Error from remote client]
<freemangordon>
Wizzup: don't want what to say
<freemangordon>
5.15 is LTS, but I don;t know when we will hit it
<freemangordon>
uvos; re SOC estimation - it seems for lower values this estimation is even worse
<freemangordon>
calculated 49 reported 31
<freemangordon>
for Ri ~= 0.1 that seems to be about right
alex1216 has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
freemangordon: huh, it follows the coding style as far as i can tell
<uvos>
i reindented hildon_mime_open_file_with_mime_type since it is indented with spaces while everything else in that file uses tabs
<freemangordon>
yes, but you mixed declarations with code
<freemangordon>
also, original coding style has space between function name and bracket
<uvos>
ah is ok
<uvos>
*i see
<freemangordon>
also, it has empty lines before and after if() blocks :p
<uvos>
freemangordon: good question, i really dont know. i gues motorola thought they needed a table for eatch battery.
<Wizzup>
maybe support to load a table in power?
<freemangordon>
uvos: what makes you think that?
<freemangordon>
you know what?
<uvos>
freemangordon: eatch battery type
<freemangordon>
I think we can implement in battery applet
<uvos>
freemangordon: well they put the table into the eeprom
<freemangordon>
no
<uvos>
that suggests they think so no?
<BlagovestPetrov[>
:)
<uvos>
no? whats the other data in the eeprom then?
<freemangordon>
uvos: ah, you mean 'each battery type'?
<uvos>
yes
<freemangordon>
ok, yeah
<uvos>
your polynomal needs to work on eatch battery there can be
<freemangordon>
yes
<uvos>
eb41 nexus4 hw4x bw8x etc
<freemangordon>
but, lets scratch upower
<freemangordon>
and implement in battery applet
<uvos>
check
<freemangordon>
Wizzup: ^^^?
<freemangordon>
they will never accept as self-learning estimation algo, I believe
<uvos>
yeah
<uvos>
maybe we can implement it as a shim around upower, libestimator or something instead of directly in upower, so if we find another place soc is used we can just reuse it
<uvos>
but thats details
<uvos>
*directly in the status applet
<Wizzup>
freemangordon: how will this help mce decide when to shut down?
<Wizzup>
or do we not need it?
<uvos>
mce will continue to use the kernel low signal or voltage to shut down
<uvos>
it dosent use soc
<Wizzup>
freemangordon: how will you sync upower selecting the right battery with battery applet selecting the right one?
<uvos>
soc estimator will use upower for the information
<uvos>
so no issue
<Wizzup>
can other applicaties read this percentage?
<Wizzup>
we have many other applications that rely on upower to read/send battery
<Wizzup>
for example for bluetooth it exposes the battery status to the car
<uvos>
ok
<uvos>
so i suggested makeing the estimator a lib
<Wizzup>
and we have apps that read it (navigation apps)
<Wizzup>
it's not a problem if we don't have it only during calibration btw
<Wizzup>
just stating the potential non obvious
<uvos>
navigation apps reading soc is a good point
<freemangordon>
doe upower support plugins?
<freemangordon>
*does
<tmlind>
uvos, freemangordon: kernel has a dts binding for open circuit voltage table, i think it has some generic kernel functions too to handle it
<freemangordon>
voltage->soc?
<freemangordon>
what kind of table is that?
<uvos>
dts is the wrong place anyhow
<uvos>
how yould that work with xt875 that can have hw4x or bw8x
<freemangordon>
we can overlay
<uvos>
i dont see how thats usefull with devices that can change battery type at any time
<tmlind>
battery specific data can be in dts if always the same, nothing stopping initializing it in the driver based on the battery type
<freemangordon>
anyway, blood sugar levels are dropping...
<freemangordon>
ttyl
<uvos>
tmlind: ok yeah
<uvos>
but i dont find haveing a table in dts for every possible battery type that apealing really
<tmlind>
ok
<tmlind>
fyi $ git grep ocv drivers/power/supply/
<freemangordon>
uvos: we can load dts overlay
<freemangordon>
that is battery specific
<uvos>
theres a voltag->soc table in samsung-sdi-battery.c
<uvos>
multiple drivers it seams
<uvos>
so mutch for "no synthesized values" :P
<freemangordon>
:)
<uvos>
kernel battery.yaml
<uvos>
ocv-capacity-table
<uvos>
An array providing the open circuit voltage (OCV)
<uvos>
of the battery and corresponding battery capacity percent, which is used
<uvos>
to look up battery capacity according to current OCV value. And the open
<uvos>
circuit voltage unit is microvolt.
<uvos>
so yeah
<freemangordon>
is that handled by the framework?
<freemangordon>
or each driver have to support that?
<tmlind>
oh cool samsung-sdi-battery.c also has the samsung_maint_charge_table with a timer :)
<freemangordon>
ttyl, lunch
<uvos>
freemangordon: framwork can do it
<uvos>
the implementaion in samsung-sdi-battery.c is "old" or "wrong"
<uvos>
see power_supply_ocv2cap_simple
<uvos>
struct power_supply_battery_info.ocv_table
<uvos>
havent found where ocv is supposed to be calculated
<uvos>
i honstly find upower geting off thair asses and implementing soc estiamtion would have been better than shoveing in into the kernel
<uvos>
but this solves the immidiate problem
<uvos>
freemangordon: it would seam sc27xx_fuel_gauge is the only current user of these framework features
<uvos>
freemangordon: so i gues the course of action then is to get some tables. we can write something that creates them from mesured values on device (i can do that if you like) or we can figureout the format in the eeprom by reing battd and grab those (you would have to do this one)
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
uvos has quit [Remote host closed the connection]
buZz has joined #maemo-leste
buZz is now known as Guest7155
Guest7155 is now known as buZz
uvos has joined #maemo-leste
<tmlind>
well at least batteries with no rom need tables generated
<freemangordon>
uvos: I think that we can generate and load dts overlay in run-time
<freemangordon>
tmlind: do you know how userspace loads dts overlay?
<freemangordon>
so it seems it accounts for the temperature as well
<uvos>
yes
<uvos>
both ri and ocv2cap can have multiple tables
<uvos>
per temperature
<freemangordon>
but I don;t see how to put that in the framework
<uvos>
why not? it could have a dts value as phandle to an iio device
<freemangordon>
no, I mean - how to plug it without drivers knowing about it
<uvos>
?
<uvos>
fw has a wrapper around get_property that replaces -ENODATA with estiamtion
<uvos>
if all values are present
<uvos>
dont see why not
<freemangordon>
does it have it?
<freemangordon>
where?
<uvos>
no - it dosent, i could
<uvos>
but lets not rock the boat here and try change the framwork
<uvos>
*it could
<freemangordon>
I think this is what shall be implementd
<freemangordon>
if there are tables but the driver either does not support or returns -ENODATA a fallback patch shall be taken
<freemangordon>
*path
<uvos>
i think this would be better
<uvos>
but i fear us trying to merge any framework changes
<freemangordon>
we can try at least
<freemangordon>
at the end of a day, if linux maintainers had become so stubborn that random patches are no longer welcome, we can try to make some noise with FSF or dunno
<freemangordon>
but, beiong afraid to send patches to lkml...
<freemangordon>
it should not be like that
<freemangordon>
me personally, I will wait till next week and will start making noise
<buZz>
are we going to make the battery data defined by DTS?
<freemangordon>
buZz: something like that
<buZz>
ooo thats a nice idea
<freemangordon>
well, I am not sure we share the same idea, but at least my idea is userspace to load DTS overlay with voltage->SOC tables
<sicelo>
this will be a voltage to SOC mapping?
<freemangordon>
yes
<freemangordon>
and we can teach power supply framework to fallback to those if driver does not provide capacity level data
<freemangordon>
how we will generate such tables is another story
<uvos>
notably all the code for voltage->soc mapping is allready in the kernel, its just usually not used.
<sicelo>
ok. i actually wonder how important SOC really is. for a long time, i felt upower should support making decisions based on voltage, and make this configurable
<sicelo>
this way, any random fg, no matter how limited it may be, will not shutdown device at wrong time
<uvos>
im not sure how accurate soc is not important
<freemangordon>
sicelo: SOC, in terms of energy, is maybe the most important parameter
<freemangordon>
s/parameter/value
<buZz>
what does SOC stand for?
<uvos>
state of charge
<buZz>
ahhhh
<buZz>
yes
<freemangordon>
% capacity, IOW
<buZz>
just by voltage :O
<freemangordon>
% remaining capacity
<freemangordon>
yes, it can be done
<uvos>
buZz: kernel can do same thing android dose
<buZz>
hmhm
<sicelo>
i am not sure it's that important ... hence some FG don't natively provide it. what am i missing? :-)
<uvos>
buZz: by using the voltage internal resitance and current in a table
<uvos>
to provide soc
<freemangordon>
sicelo: they have couloumb conters, no?
<freemangordon>
how do those 'gauges' actually measure anything?
<freemangordon>
a chip providing voltage is not really a gauge if you ask me
<uvos>
yeah imo a guage has a counter and a palce to store the value
<uvos>
thus cpcap is almost a guage
<buZz>
are the current_avg etc all based on voltage as-is?
<uvos>
current is based on current
<uvos>
cpcap has a shunt
<sicelo>
now we're going towards terminology... I'm k
<freemangordon>
uvos: btw, why calibration is being reset after restart?
<uvos>
freemangordon: we have no where to store it
<uvos>
and the counter is rest to 0 on cpcap rest
<freemangordon>
sicelo: no, it is about functionality
<buZz>
we could store it somewhere?
<uvos>
no
<uvos>
since we dont know if the battery was removed or if android used it etc
<buZz>
right
<freemangordon>
sicelo: what functionality provides a so-called gauge that provides neither SOC nor couloumb counting?
<freemangordon>
'fuel gauge' comes from cars, no? so, how useful is such gauge if it provides you with the resistance of the fuel sensor? yes, it depends on the fuel level, but that's all
<freemangordon>
you don;t actually know how much fuel you have left in the tank
<freemangordon>
the same is with battery voltage and remaining capacity IMO
<buZz>
especially if you only look at voltage 'now'
<buZz>
as currentdraw might be high atm
<freemangordon>
that one as well
<buZz>
its not a easy problem to know capacity of a battery usually
<uvos>
hence us discussing this very problem for like 3 days now :P
<buZz>
ohh btw, adding the 2250 instead of 1740 , increases weight of d4 by ~4 grams :)
<freemangordon>
ummm, what?
<buZz>
uvos: honestly feels like forever ;)
<uvos>
the nexus 4 battery is hevier than eb41
<buZz>
freemangordon: the battery is slightly heavier
<uvos>
noticably so
<freemangordon>
ah
<buZz>
about 3% heavier, you can notice it if you have two devices
<freemangordon>
yeah
<uvos>
i gues einsteins law stipuates that the battery is lighter when empty
<uvos>
since there is less engery in the molecular bonding forces in this state
<uvos>
but its not 4g xD
<freemangordon>
do we have the same number of electrons?
<uvos>
sure, but energy levels are higher in the bonds
<freemangordon>
I guess yes, but in lower energy state
<uvos>
yup
SuperMarioSF has quit [Quit: Client closed]
<freemangordon>
actually, initially I understood buZz' comment to be something in that regard
<uvos>
me too, at first
<uvos>
thus the comment
<freemangordon>
like, if the battery is charged to 2250 instead of 1750 it becomes heavier :D
<buZz>
freemangordon: i'm quite sure there's just more layers of lithium stacked into the cell
<freemangordon>
which most-probably is true, but not something we can measure
<buZz>
why not? we have a scale :D
<buZz>
i pretty much doubt it'll be measurable
<uvos>
i dont think you realize the degree of small this change would be
<buZz>
it'll be <0.1gr i guess
<freemangordon>
no
<freemangordon>
something like 1*10^-100
<sicelo>
the table will be v & soc only, or include other parameters too?
<buZz>
thats <0.1 then :P
<freemangordon>
no, thats << 0.1 ;)
<freemangordon>
sicelo: I think there is some temperature tables as well
* sicelo
whispers *serial* to Wizzup... managed last night?
<freemangordon>
but even with one table that's dynamically updated, it should be pretty much correct for the purpose we use it
<freemangordon>
+/- 2-3 % should not matter
<buZz>
btw its kinda funny to see 'current_avg' on disconnected vs gprs connected vs wifi connected
<uvos>
looks like for a 1750mA battery that thus contains about 400J of energy
<buZz>
its ~170000 on disconnected, ~130000 on gprs connected, ~180000 on wifi connected
<uvos>
the change would be about 1*10^-12 g
<buZz>
so weird to see whole device use less on gprs connected vs nothing active
<uvos>
thats more than i expeced
<buZz>
i guess thats the same as the 'no sim card makes modem use more power' ?
<buZz>
uvos: with screen active, btw
<uvos>
yeah no idea whats up with modem power consumption
<uvos>
its really wierd
Juest has quit [Quit: Client closed]
<sicelo>
Wizzup, also just out if curiosity, I wish to see pictures of that serial jig. What does it use to power the device? Sebastian's contraption reuses the battery
<freemangordon>
uvos: the difference would be ~1.8*10^-14
<freemangordon>
((2.25-1.75)*3600)/(10^-17)
<Wizzup>
sicelo: I thought I made photos before, but I can make them again
<uvos>
freemangordon: hmm for the exact value i get 2.59*10^-13
<uvos>
battery has 6.475Wh of engery, 6.475Wh*3600 = 23310 Joules
<freemangordon>
thats not the difference between 2250 and 1750 charge
noidea_ has quit [Remote host closed the connection]
<uvos>
m = E/c^2 = (23310) Jouls / (300*10^6 m/s) = 2.59*10^-13 kg
<uvos>
freemangordon: right i was going empty -> full
<uvos>
gocha
noidea_ has joined #maemo-leste
<uvos>
still first value was wrong because i converted wh - > joule wrong
<uvos>
ok yes our values agree :P
<freemangordon>
:)
<Wizzup>
freemangordon: if you have a moment, can you look at mafw-shared build fail? I can't quite figure it out
<Wizzup>
it's not urgent
<uvos>
probubly more urgent can caluclateing the change in mass of a battery based on special relativity
<freemangordon>
yeah, linear approximation is totally off
<freemangordon>
it says 50%, but algo is from 30 %
<uvos>
linear approximation form 50% also dosent jive with a lipo discarge curve at all
<uvos>
since its the least linear its ever going to get around 30%
<uvos>
or maybe closer to 20
<buZz>
oh, about % and voltages ; the statusmenu displays a % of charge when not calibrated based on voltage, but its using 'max design voltage' and not what its actually able to charge to (as in, 4.349V vs 4.33V) , leading to having '98%' at max charge :)
<buZz>
havent checked if this happens with a 4.349v-charging-to-4.2v too
<freemangordon>
it is upower, not status menu applet
<freemangordon>
uvos: ugh, actually formula gives 21 % for 3757
<freemangordon>
so linear shall start @ 20, not @ 50
<uvos>
freemangordon: ok yeah i see
<uvos>
freemangordon: but im not sure why you care about the formula at all at this point
<uvos>
freemangordon: would using kernel fw tables not be better anyhow
<uvos>
freemangordon: since it works with upstream upower
<uvos>
or is this to generate a fallback table if the battery is unkown?
<freemangordon>
as a stopgap patch in upower
<freemangordon>
yes, for fallback table too
<freemangordon>
uvos: also, isn't 3.3 too low for 0%?
peetah has quit [Ping timeout: 264 seconds]
<freemangordon>
ok, that's better:
<freemangordon>
calculated 13 reported 10
peetah has joined #maemo-leste
<uvos>
freemangordon: no 3.3 is fine
<uvos>
this is open circut voltage
<freemangordon>
ah, right
<freemangordon>
hmm, calculations show 15 %, driver reports 7 %, lets see who is right :)
<uvos>
well mce also shutsdown early on purpose so im not sure how your going to get "ground truth" really
<uvos>
in the single diget % range
<freemangordon>
I will stop mce :)
<uvos>
still the signal that the kernel acts upon is also quite nosy
<uvos>
so not sure thats any better
<uvos>
but it is hopefully close enough
<uvos>
the real test here is to use Wizzup's fancy imaxb6 to charge to specific soc
<uvos>
and then then test that against algo :P
<freemangordon>
yeah
<freemangordon>
ok, this is the first time I hear " recharge battery" sound :)
<freemangordon>
uvos: ok, but if we shut down @ 3350, shouldn't that be our 0% point?
<freemangordon>
btw, I think calculated value is more correct
<freemangordon>
as now calibrated shows 3% @ 3566mV
<uvos>
freemangordon: sure but thats a mapphone quirk
<freemangordon>
right
<Wizzup>
uvos: damn sounds like I should have send one to you
<uvos>
Wizzup: i have one ;)
<Wizzup>
sounds like you do the test then?
<Wizzup>
you can*
<uvos>
i can, but seriously tedious mesurements are best left to someone else xD
<uvos>
anyhow, i can do it :)
<Wizzup>
I haven't been able to use the device yet, won't be for a while, so better if you do
<Wizzup>
btw, with mpd and mpris-proxy I can control mpd from my headphone by swiping on the right ear (feature), kinda cool
<uvos>
Wizzup: ok
<uvos>
Wizzup: that is cool
<uvos>
Wizzup: bluetooth integration would be neat
<Wizzup>
yup, later though
<Wizzup>
I think it's best to do chimaera first
<Wizzup>
it's just too annoying to maintain both chimaera and beowulf
SuperMarioSF has quit [Quit: Client closed]
<uvos>
yeah wasent a now thing, just museing
<sicelo>
I'm not sure changing to pw/xsession will be well-timed with the move to chimaera. there are valid reasons why even fast-moving distros do a feature freeze just before changing versions
<sicelo>
unless there are specific issues that force/require such change to happen asap
<Wizzup>
tmlind: I will send two xt912 since I am not sure if they both work
<Wizzup>
i mean they start :)
<tmlind>
ok cool
Juest has quit [Quit: Client closed]
SuperMarioSF has joined #maemo-leste
<freemangordon>
uvos: calculated 10 reported 0
<freemangordon>
that was maybe half an hour ago
<freemangordon>
now it is 'calculated 4 reported 0'
<freemangordon>
so calculated seems to be more correct :)
<uvos>
uh whats calculated here
<uvos>
estimation?
<freemangordon>
yes
<uvos>
ok
<SuperMarioSF>
maybe reported value is attempting to preserve more power for something else?
<uvos>
great
<uvos>
no
<freemangordon>
wrong calibration
PureTryOut[m] has quit [Quit: Bridge terminating on SIGTERM]
MartijnBraam[m] has quit [Quit: Bridge terminating on SIGTERM]
stintel has quit [Quit: Bridge terminating on SIGTERM]
BlagovestPetrov[ has quit [Quit: Bridge terminating on SIGTERM]
mogolobogo[m] has quit [Quit: Bridge terminating on SIGTERM]
<uvos>
its just that the low irq is noisy
juustohiiri[m] has quit [Quit: Bridge terminating on SIGTERM]
humpelstilzchen[ has quit [Quit: Bridge terminating on SIGTERM]
mighty17[m] has quit [Quit: Bridge terminating on SIGTERM]
bumpkinbye[m] has quit [Quit: Bridge terminating on SIGTERM]
<uvos>
so it callibrates somewhat wrong
<SuperMarioSF>
btw my new battery was calibrated but seems wrong, had almost 100mAh less capacity.
<uvos>
freemangordon: maybe pr charge-mode :P
<freemangordon>
yeah
<freemangordon>
will do
<SuperMarioSF>
but more durable than before.
<SuperMarioSF>
strange
<freemangordon>
uvos: so, shut down happened @ 4% estimated
<freemangordon>
this is 3350mV
<uvos>
i mean that sounds about right
<freemangordon>
so, about right
<freemangordon>
mhm
<uvos>
@4% reserved by mce
<freemangordon>
yeah
MartijnBraam[m] has joined #maemo-leste
<SuperMarioSF>
seems right
PureTryOut[m] has joined #maemo-leste
<SuperMarioSF>
my phone also shut down at 4% (reported from android side)
humpelstilzchen[ has joined #maemo-leste
BlagovestPetrov[ has joined #maemo-leste
stintel has joined #maemo-leste
mogolobogo[m] has joined #maemo-leste
bumpkinbye[m] has joined #maemo-leste
mighty17[m] has joined #maemo-leste
<freemangordon>
uvos: I don't think charge-mode bug is fixed
juustohiiri[m] has joined #maemo-leste
<uvos>
i mean a bug is def fixed
<freemangordon>
did you push to repo?
<uvos>
let me check
<freemangordon>
I mean - did you rebuild?
<freemangordon>
bbiab
<uvos>
sure 1.2.6
<uvos>
its in the repo
<freemangordon>
oh, what level it waits for?
<freemangordon>
10%?
<freemangordon>
uvos: I think it shall animate something
<freemangordon>
to show that it is charging
<uvos>
we could blink the lighting bolt if you like
<Wizzup>
check_el.c: In function 'test_add_event_fn':
<Wizzup>
check_el.c:196:14: error: too many arguments for format [-Werror=format-extra-args]
<Wizzup>
196 | fail("Failed to create event.");
<Wizzup>
| ^~~~~~~~~~~~~~~~~~~~~~~~~
<freemangordon>
weird
<freemangordon>
cannot look at it RN
<Wizzup>
I can also stop for today with chimaera stuff, but I threw away half an hour already
<Wizzup>
there's about 80 errors like this
<uvos>
new infra is seriously fast at building mce
<uvos>
i gues it was a rpi before so no suprise . still
<Wizzup>
most of the time in almost all the builds is the whole cow stuff
<uvos>
yeah
<Wizzup>
it's also faster than amd64 but only because amd64 is not on ssd atm
<uvos>
ok
<uvos>
anyhow its just about as fast as a local build on d4
<uvos>
thats pretty good
<Wizzup>
should be much faster really
<uvos>
well it has to do mutch more
<Wizzup>
keep in mind it does a lot of pkg fetching and dpkg action
<Wizzup>
yeah
<freemangordon>
uvos: is it normal that soc prediction is very inaccurate on charging?
<uvos>
no
<uvos>
should be the same really if ri is correct
<uvos>
except at very high charge rates > 1c
<uvos>
there is increasing non liniarity
<freemangordon>
1c is? 1200 mA?
<uvos>
for you 1c is 2.2A
<freemangordon>
oh
<freemangordon>
well, it charges @ ~1A
<uvos>
right
<freemangordon>
Calculated r = 0.080460, Ri = 0.089695 for Imax=-1215mA@4009mV, Imin=-1302@4016mV
<freemangordon>
calculated 63 reported 39
SuperMarioSF has quit [Quit: Client closed]
<uvos>
so open circut voltage estimation via Ri should hold for the most part
<uvos>
in this case
<freemangordon>
unless the math for calculating Ri when charging is different
<uvos>
not really
<uvos>
sign of I changes
<freemangordon>
right
<freemangordon>
and that's good as we have to subtract anyways
<uvos>
maybe calculating Ri is less accurate because relatvie difference in I is less
<uvos>
so if you retain the last discharging Ri
<uvos>
how goes the estimation?
<freemangordon>
can't parse
<uvos>
while charging
<uvos>
I dosent change that mutch (in a relative sense)
<uvos>
possibly increasing the error in Ri
<uvos>
so if you just use the last Ri from when you where discharging
<uvos>
dose soc estimation remain poor?
<freemangordon>
Calculated r = 0.108153, Ri = 0.105595 for Imax=-701mA@3967mV, Imin=-1302@4032mV
<freemangordon>
calculated 61 reported 43
<freemangordon>
this is big wnough difference
<freemangordon>
*enough
<uvos>
yeah
<freemangordon>
so Ri calculation should be correct
<freemangordon>
there is something else going on here
<uvos>
also thats a closer Ri to ususal discharing state no
<uvos>
?
<freemangordon>
yes
<freemangordon>
maybe reported voltage is incorrect
<uvos>
hmm at least i dont see why that would be
<freemangordon>
but looks like it is
<freemangordon>
because this is too high voltage for 40% SOC, no?
<uvos>
i mean a bit
<uvos>
its suggesting open circut voltage is 3.87
<uvos>
maybe 3.8 allowing for some error in Ri
<uvos>
also non linierty
<uvos>
of Ri
<freemangordon>
hmm, I stopped charging but it still gives bogus results
<uvos>
Ri increases with current
<freemangordon>
yep, reported voltage is deffinitely wrong
<uvos>
(at high currents reactants close to the electrode get depleted and you end up more diffusion limited)
<uvos>
freemangordon: ok
<uvos>
wierd for sure
<freemangordon>
even with current limit set to 0 I see voltages > 4.0
<freemangordon>
with charger disconnected voltage drops to 3.8
<uvos>
hmm
<uvos>
can you mesure at the terminals with a dmm?
<uvos>
or sec let me do it
<freemangordon>
not now
<uvos>
ill do it
<freemangordon>
thanks
<uvos>
ok
<uvos>
no charger 3.80V 128.3 mA)
<uvos>
dmm reports 3.82V
<uvos>
charger plugged in, echo 0 > /sys/class/power_supply/usb/input_current_limit
<uvos>
3.91V -491mA
<freemangordon>
mhm
<uvos>
huh wait
<uvos>
ok thats a bug setting input_current_limit to zero has no efect untill i replug usb
<uvos>
anyhow carring on
<uvos>
with usb replugged and input_current_limit 0
<freemangordon>
well, I hit that bug it seems
<uvos>
3.82V and 123mA
<uvos>
dmm agrees
<freemangordon>
but, what if you set input current limit to 1800?
<uvos>
what units is input_current_limit in again
<freemangordon>
uA
<freemangordon>
1800000
<uvos>
4.1V 1395mA
<uvos>
dmm agrees
<freemangordon>
ok
<freemangordon>
then something wrong with math it seems
<uvos>
or non liniarity of Ri is greater than i would expect
<freemangordon>
but I calculate it before use it
<uvos>
not sure what you mean
<uvos>
what i mean is that if you calculate Ri from 1 and 100mA you would expect a lower value than form 1001 and 1100
<uvos>
because the battery becomes increasingly diffusion limited
<uvos>
this effect isent huge mind you, at resonable currents ie <1c
<freemangordon>
I recalculate Ri every 30 seconds
<uvos>
but maybe greater than i think
<freemangordon>
based on 10 samples made just before recalculation
<uvos>
sure but if your calculating Ri at around 1A and then applying it for all of those 1A its wrong
<uvos>
you would have to calculate Ri for the first 500mA and then compensate that for ocv
<uvos>
and then calculate again for the last 500mA
<uvos>
and compensate those 500mA with the latter Ri
<uvos>
or so
<freemangordon>
I don't get that
<uvos>
(idealy you would integrate ofc)
<uvos>
ok so it works like this
<freemangordon>
wait a sec
<freemangordon>
i calculate Ri for current ~ 1200 mA
<freemangordon>
and then use that Ri to calculate open circuit voltage for current ~ 1200 mA
<freemangordon>
so I don;t see where the error is
<freemangordon>
so, please explain
<uvos>
so lets say i take 500mA from battery, this drops the voltage by 0.1 when compeard to the open circut voltage (made up values).
<freemangordon>
ok
<uvos>
then i take 1A from battery, you would expect V to drop by 0.2 but it dosent it drop by soemthing > 0.2 because the battery is more diffusion limited
<uvos>
effectively the Ri for those last 500mA is greater than for the first
<freemangordon>
ok
<uvos>
but this effect should be small
<uvos>
at small currents
<uvos>
there the battery should be effectively linear
<buZz>
uvos: on ideal batterues its small
<buZz>
on old ones less so
<freemangordon>
but, this is not what happens here, as I calculate for currents ~1200mA
<buZz>
'pre wornout' cells
<freemangordon>
Calculated r = 0.102273, Ri = 0.089607 for Imax=-1092mA@4158mV, Imin=-1180@4167mV
<freemangordon>
1092 vs 1180
<uvos>
freemangordon: right but then you apply the Ri you got at ~1200mA to all of those ~1200mA
<uvos>
to get ocv
<uvos>
thats the problem
<uvos>
during the first 100mA of those 1200mA your currently loading the battery at the voltage dident drop as mutch as in the interval you mesured Ri at
<uvos>
so the result is somewhat wrong
<freemangordon>
actually it seems that Ri decreases with the current
<freemangordon>
at least on discharge
<Wizzup>
freemangordon: I will make an issue for the rtcom-eventlogger warnings, ok?
<uvos>
might be part of the cause of Ri bouncing around
<uvos>
but should not be for the problem of charging soc being different
mardy has quit [Quit: WeeChat 3.5]
<freemangordon>
right
<freemangordon>
I don't think that capacity plays any role here as current is relatively constant
<Wizzup>
next time I should write a python script that parses debian/control and suggests a build order for the pkgs
<freemangordon>
uvos: I think we have another issue, in the charger
<freemangordon>
it seems it charges till 4.2 is hit, but this is not 4.2 OCV
<freemangordon>
it charges to something like 4.189
<freemangordon>
or even less
<uvos>
so according to the datasheet of cpcap
<uvos>
it will charge CC until 4.2 (or set point) is reached and then it will fire an irq (which we ignore afaik) and will then automaticly switch to CV charge until current dropes below 50mA
<uvos>
so yes it is expected that ocv never reaches 4.2V but 4.2V - whatever is deltaV at 50mA
<Wizzup>
freemangordon: should I rebase patches for eds?
<Wizzup>
I'm trying to build osso-abook but it's involving :D
<freemangordon>
yes, please
<uvos>
so if Ri is 150mOhm (like i mesured it here by hand)
<uvos>
then you would expect ocv voltage after charging ends to be 4.1925V
<uvos>
so close enough really
<freemangordon>
ok
<BlagovestPetrov[>
hah, xorg conf is broken and the VM restarts on boot
<uvos>
dsme?
Twig has quit [Remote host closed the connection]
Juest has joined #maemo-leste
peetah has quit [Ping timeout: 264 seconds]
peetah has joined #maemo-leste
<Wizzup>
freemangordon: why do we keep using quilt for patches instead of just git :(
<Wizzup>
ok, abook built
<Wizzup>
(locally)
<Wizzup>
uvos: we still use hildon-desktop-rotation-support - right?
<uvos>
Wizzup: nope i integrated that into h-d a long time ago
<Wizzup>
ok, I think the pkg is still installed on my device at least
<uvos>
thats just your device
<uvos>
i remember removeing it from the metapacakge
<Wizzup>
yup
<Wizzup>
ok
<Wizzup>
might be better for the meta package to conflict on it