<freemangordon>
maybe I didn;t push to master, lemme check
<freemangordon>
it is there as well
<uvos>
its there
<freemangordon>
hmm, with the new battry thing are looking way batter
<freemangordon>
*things
<freemangordon>
I disconnected from the charger yesterday evening
<freemangordon>
it still reports 50% full, but I think it has more juice actually
<uvos>
just in: man is suprised new 2200mah battery works better than 10 year old 1750mah cell :P
Danct12 has quit [Remote host closed the connection]
Daaanct12 has joined #maemo-leste
Danct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 252 seconds]
uvos has quit [Remote host closed the connection]
akossh has quit [Ping timeout: 252 seconds]
noidea_ has quit [Remote host closed the connection]
noidea_ has joined #maemo-leste
akossh has joined #maemo-leste
<freemangordon>
:D
pere has quit [Ping timeout: 248 seconds]
<freemangordon>
tmlind: BTW, I have a patch for a panel (simple-panel), I know the model but not the manufacturer, what compatible I shall make for it? All panels are like $manufacturer,$model.
<freemangordon>
I think it is better to calculate that based on POWER_SUPPLY_VOLTAGE_MIN_DESIGN
<freemangordon>
like POWER_SUPPLY_VOLTAGE_MIN_DESIGN+50 or something
<freemangordon>
also, I guess you have some hard values in charge-mode
<sicelo>
that "Battery low at 3393mV" came from kernel. isn't it kernel that initiated the shutdown in this case?
<freemangordon>
no
<freemangordon>
also, it seems there are 2 types of 'low' one @ 3.3 and other @ 3.1, no idea what are those used for
<freemangordon>
tmlind: ^^^ do you remember?
<freemangordon>
ah, it seems 'high' low is for low reporting, 'low' low is for shutdown
<freemangordon>
cpcap_battery_low() has some hardcoded values too
<freemangordon>
but that is not so critical as mce deciding to do power off too early and charge-mode assuming normal li-ion battery no matter what kernel says
<sicelo>
iirc it was set to 3350 in mce because d4 can't boot easily once battery is completely depleted
<freemangordon>
*what* battery?
<sicelo>
d4 battery :-)
<freemangordon>
10yo one?
<freemangordon>
because here I have new polarcell 2250 mAh
<sicelo>
10yo battery and cheap replacements
<freemangordon>
and yes, it can boot the device even @ 3150
<freemangordon>
the point is that genuine moto batteries are 3.1-4.35
<freemangordon>
not 3.2-4.2
<freemangordon>
and that is the difference between 1600 and 2200
<freemangordon>
30%
<freemangordon>
or something
<freemangordon>
but anyway, lets wait for uvos, to see if we will be able to come-up with some idea that will make both (old battery/new battery) parties happy
<freemangordon>
in any case, mce shutdown voltage must be less that 3.3, otherwise you don't have any chance to get a charger
xmn has quit [Ping timeout: 252 seconds]
pere has quit [Ping timeout: 252 seconds]
alex1216 has quit [Quit: WeeChat 2.3]
xmn has joined #maemo-leste
<freemangordon>
hmm, what about:
<freemangordon>
1. mce stores current voltage @ first 'low' signal received
<freemangordon>
2. on every following 'low' received, it subtracts the current voltage from the stored one and if it is more than a threshold or if the current voltage is less that DESIGN_LOW + 100 (for example), then it shuts down
<freemangordon>
3. stored 'first low' is reset on charger connected
<freemangordon>
that way bad batteries will be guaranteed to have enough charge to boot and good batteries will be used properly and users will have a chance to find a charger
<freemangordon>
hmm?
pere has joined #maemo-leste
<freemangordon>
my old (bad) battery was giving low @ 3636mV, so I think threshold should be calculated based on lowVoltage - 3300, somehow
<freemangordon>
hmm, actually threshold = $device_specific_value + (4200-DESIGN_LOW) should be better
<freemangordon>
oh, I mean 3200-DESIGN_LOW
uvos has joined #maemo-leste
<freemangordon>
hmm, increasing POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE doesn't actually work
<Wizzup>
sicelo: I wil be near it on sunday and onwards
<uvos>
mce deicdes to turn off the device early because of the mapphone bootloader booting problem when totaly empty
<uvos>
we discussed this plenty of times before
<uvos>
yes its early (slightly the amount of engery in a lipo at 3.35 volts is fairly tiny over 3.0V the curve gets really steep down there)
<uvos>
note that teh differencein capcaity between a discarge to 3.1 and 3.2 is less than to even worry about
<uvos>
3.35 is slightly early, but note that we do that because the device will die before it reaches a bootstate where it can charge if you do that
<uvos>
becasue of kexecboot etc
<uvos>
but even that is in the rage of a couple pecent
<uvos>
2% maybe 5% if the device is heavly loaded at shutdown
norayr has left #maemo-leste [Error from remote client]
<uvos>
so i did the expieraments wrt when to shutdown with my best stock eb41 btw
<uvos>
that hat about 1250mAh as callibrated by cpcap
<uvos>
also taking into account that we use quite a large amount of power even when off, if the mainline kernel is the one to turn the device off
<uvos>
so we also needed some extra
<freemangordon>
uvos: I understand and agree that we should have some extra power on shutdown
<freemangordon>
that's not the issue, the issue is that I was not give any chance to connect a charger
<freemangordon>
*given
<freemangordon>
no warning, nothing, as soon as 'low' was signaled, bang, a shutdown
<freemangordon>
that's why I think a more complicated logic, like the one ^^^ shall be implemented
<freemangordon>
also, it is not about d4 only
<uvos>
well we have a conflict here
<freemangordon>
I know
<uvos>
we dont want to change the values in kernel
<uvos>
because they should be correct
<freemangordon>
we should not
<uvos>
so we want a workaround in userspace only
<freemangordon>
see the algo I came up with ^^^
<freemangordon>
this is all in mce
<uvos>
i dont see why its not about d4 only
<uvos>
any other device should not have this issue
<uvos>
the kernel should just signal at the appropriate times
<freemangordon>
we may have similar issues on other devices, in theory
<freemangordon>
but lets not discuss that now
<freemangordon>
please comment on the alog
<freemangordon>
*algo
<uvos>
i dont grok it
<uvos>
what is your first low?
<freemangordon>
'current_voltage' at the tim e'low' is generated for the first time
<uvos>
thats essentaly a random number generator
<uvos>
since it depends on load
<sicelo>
those 'lows' don't exist in bq27200 iirc
<freemangordon>
not really, because the worse battery is, the higher the voltage
<uvos>
but you cant realy on that
<uvos>
since it wont be so when the device is not loaded
<uvos>
i also dont see what is nessecary
<uvos>
besides rasing the low threshold (for the banner) in userspace
<freemangordon>
to have at least few minutes of "battery low" ranings before a shutdoen
<uvos>
sure
<freemangordon>
*warnings
<uvos>
so just raise the tresh in upower
<freemangordon>
this somes from the kernel
<uvos>
to 3.5 or so
<freemangordon>
*comes
<uvos>
and ignore the kernel
<uvos>
just need to make this selective like in mce
<freemangordon>
see, *defaults* should work
<uvos>
the defaults are what is in kernel
<freemangordon>
no, mce ignores the kernel and makes its own shut-down decision
<uvos>
yes
<uvos>
the fact that the kernel is "lieing" is a quirk on mapphones only
<freemangordon>
this is wrong the way it is implemented for d4
<freemangordon>
that quirk makes it so that those with good batteries have absolutely no chance to plug a charger when the battery is low
<freemangordon>
and this has to be fixed
<uvos>
sure and i told you how i would do that
<uvos>
just ignore the low signal from the kernel in upower
<freemangordon>
why upower?
<uvos>
and add something based on configureable voltage instead
<uvos>
where else would you do it?
<uvos>
upower is the common thing here
<freemangordon>
that agin depends on the load, no?
<uvos>
sure, but its the best we have
akossh has joined #maemo-leste
<freemangordon>
did you grok what I am proposing?
<uvos>
yes and it cant be reliable
<freemangordon>
I don;t see why?
<uvos>
since it depends on instanainous load
<uvos>
while upower dose smoothing
<freemangordon>
no, there are 2 shutdoen conditions
norayr has joined #maemo-leste
<freemangordon>
either threshold or low voltage
<freemangordon>
whichever comes first
<uvos>
sure. but should be critical not low
<uvos>
for the latter
<uvos>
low is the banner
<freemangordon>
sure
<freemangordon>
I have no issue with too mane 'low' banners
<freemangordon>
given that I had none before shutdown :)
<uvos>
right so the problem is not the shutdown threshold in mce
<freemangordon>
back then I had my n900 beeping 'low' all day long
Twig has joined #maemo-leste
<freemangordon>
it is
<uvos>
or the cirtical signal
<uvos>
it is that the low signal dosent follow the thresh in mce
<freemangordon>
no, it is the shutdown threshold in mce
<uvos>
ie it isent above the tresh in mce
<freemangordon>
lemme explain:
<freemangordon>
I got kernel low @3393mV
<freemangordon>
mce threshold is 3350
<sicelo>
freemangordon: was the N900 battery calibrated? (that beeped low all day)
<uvos>
yes so it shutdown
<uvos>
and you never saw the low banner
<freemangordon>
exactly
<uvos>
the issue here isent the mce threshold
<uvos>
its that the banner is to late
<freemangordon>
it is
<freemangordon>
because it shuts down
<uvos>
mce _has_ to shutdown
<freemangordon>
no, banner is not late
<uvos>
it has no choice
<freemangordon>
yes, but that should depend on the quality of the battery
<freemangordon>
sicelo: this is d4
<uvos>
it cant
<freemangordon>
sicelo: oh
<freemangordon>
no, that was bme
<uvos>
there is no reliable way for mce to know how mutch capacity is below 3.35V
<uvos>
what you propose is not a relaible way to mesure it
<freemangordon>
but is better than current behaviour
<uvos>
no
<uvos>
and as i also explained
<uvos>
if mce thresh is 3.35
<freemangordon>
no, current behaviour is unacceprable
<uvos>
and your special thresh is 3.15V
<uvos>
the lost extra capacity is <5% in exream cases
<uvos>
probubly less than 2
<freemangordon>
because it leeves me without a phone, withoug giving me a warning
<freemangordon>
*leaves
<uvos>
but thats not a problem with the treshold at all
<uvos>
the indication of low just needs to come earlier
<freemangordon>
it cannot
<freemangordon>
because the battery is good
<uvos>
ofc it can
<uvos>
we need 2-3% extra capcaity to boot again
<freemangordon>
exactly
<uvos>
so we need to move the low signal up 2-3%
<uvos>
aswell
<freemangordon>
no, we should not shutdown @ 3350
<uvos>
yes we must
<uvos>
there is no alternative
<freemangordon>
or at least that should account for the DESIGN_LOW
<uvos>
no
<freemangordon>
aaaaa
<freemangordon>
I give up
<uvos>
DESIGN_LOW should be the real value
<uvos>
not the value we moved up 2-3%
<uvos>
becasue of the bootloader issue
<uvos>
so we should absolutly not include it
<uvos>
and we dont have to either
<uvos>
becuase the differences in design low are immaterial
<uvos>
3.1 vs 3.2 vs 3.0 v are <<1% capcaity
<uvos>
we cant mesure that accuratly anyhow
<uvos>
so there is no point
norayr has left #maemo-leste [Error from remote client]
<freemangordon>
ok, lemme try again:
<freemangordon>
uvos: what is the lowest battery capacity we shall support?
<uvos>
android works fine even with really degraded batteies
<freemangordon>
ok, so 1000mAh?
<uvos>
sure
<freemangordon>
now, to boot, we need about 50mAh remaning, no?
<uvos>
not sure about the exact value
<uvos>
but yes some amount
<freemangordon>
and high enough voltage, like maybe 3.3 if we assume internal resistance to be 1 ohm
<freemangordon>
this is for bad batteries
<uvos>
high enougth voltage at what stage
<freemangordon>
boot
<uvos>
we need to stay above mbms shutdown threshold
<uvos>
the android kernels threshold
<uvos>
during boot
<freemangordon>
so 3.1
<uvos>
yes, mbm is a bit higher
<freemangordon>
threshold I mean
<uvos>
but it comes first so no matter
<freemangordon>
ok
<uvos>
we also need to say above the mainline kernels emergency shutdown thresh
<uvos>
at least for the second it takes to enable charging
<freemangordon>
yes
<freemangordon>
so, lets assume 3.3 is ok
<uvos>
sure at boot time
<uvos>
so we need to issue shutdown slightly before that ofc
<freemangordon>
but, this is 3.3 with no load
<uvos>
sure
<uvos>
but you need to accound for usage during shutdown
norayr has joined #maemo-leste
<freemangordon>
sure, but this is about 30 seconds
<uvos>
and the bug that cuases the device to use 1-2mA during off
<uvos>
we need the device to survive a day or so while off after low battery shutdown
<uvos>
30 quite processing intense seconds
<freemangordon>
also, we can use the measured capacity to make an estimation of the quality of the battery
<uvos>
do remember the discarge curve, 3.3v and 3.1 are very close
<uvos>
well the problem here is
<uvos>
that we dont know where the charge counter is ususal
<sicelo>
uvos: shouldn't that be figured out? "the bug that cuases the device to use 1-2mA during off"
<uvos>
sicelo: yes
<uvos>
sicelo: but thats very hard
<uvos>
sicelo: how do you get hw state when the device is off
<uvos>
sicelo: clearly we are not doing something, but what?
<freemangordon>
anyway, we shall either raise the 'low' threshold above 3.3 or lower the mce shutdown threshold
<freemangordon>
we can;t do former, so we shall make mce smarter
<uvos>
well we cant lower the mce shutdown threshold as that will softbrick peoples devices
<uvos>
and we must make the low threshold be above whatever mce decides at all times
<freemangordon>
byt either lowering the threshold or do not do shutdown before warning at least couple of times
<uvos>
so it needs to account for the mce tresh being 3.35v
<uvos>
we cant just not shutdown before warning a couple of times
<freemangordon>
so, what about ignoring firts couple of "low" signals then?
<uvos>
a bad idea
<uvos>
since if the device is very quiet they wont come
<freemangordon>
why?
<uvos>
it will only come once
<uvos>
there is only one solution:
<uvos>
remove the code from mce, and add it to upower
<uvos>
the real issue here is
<uvos>
that the ui and mce take the values from upower
<uvos>
and chaingn something in mce (like how low is determined) dosent affect the ui
<freemangordon>
again, it is not about the low but about shutdown
<freemangordon>
and this is decided in mce
<uvos>
yes but thats not the root issue
<uvos>
so really mce should just shutdown when upower sais battery is ciritcal
<uvos>
and the ui should notify when upower sais low
<freemangordon>
agree
<uvos>
so we messed with mce to change when critical is
<uvos>
but thats bad
<freemangordon>
that's what I am trying to say all the time
<uvos>
because it dosent move low and it dosent move critical for other upower clients
<uvos>
the solution is not to make mce "smarter"
<uvos>
but to add config options to upower
<uvos>
to define low and critical other than what the kernel sais
<freemangordon>
which we have to support, no?
<freemangordon>
upower patches I mean
<uvos>
not sure what you mean by support
ceene has quit [Remote host closed the connection]
<uvos>
we have to write upower patches
<uvos>
yes
<uvos>
we have plenty of those allready.....
<freemangordon>
well, whatever the solution is, the current behaviour is not ok
<freemangordon>
I'll think about that a bit more
<uvos>
well the only way to solve it is to change A: kernel, but we dont want to do that or B: upower
<uvos>
and changing upower would involve adding a udev var that it checks for a low voltage threshold for critical
<uvos>
and antoher for low
<freemangordon>
or simply lowering the current mce threshold a bit
<uvos>
no
<freemangordon>
I think current value is too conservative
<uvos>
that dosent solve the issue at all
<uvos>
even if the value is too converative ( i strongly dissagree )
<freemangordon>
ok
<uvos>
the issue is that the distance between low and cirictcal is not constant
<freemangordon>
who is going to implement the code in upower?
<uvos>
ugh, im not to bothered by current behavior xD
<freemangordon>
but your users are
yanu has quit [Ping timeout: 248 seconds]
norayr has left #maemo-leste [Error from remote client]
yanu has joined #maemo-leste
<uvos>
heh
<uvos>
well idk - not right now make an issue is what i say to that
pere has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
uvos has quit [Ping timeout: 252 seconds]
norayr has joined #maemo-leste
nedko has quit [Ping timeout: 255 seconds]
nedko has joined #maemo-leste
mardy has quit [Quit: WeeChat 3.5]
_whitelogger has joined #maemo-leste
Twig has quit [Remote host closed the connection]
<norayr>
floks, i agree with uvos. even now d4 is problematic. i recently found myself preparing special wires and connecting my phone to my friends' phone in other town because there was no way to charge it. i revived it, luckily, gave it enough charge from my battery so that it would start and charge itself.
<norayr>
it sdould preserve even more charge when shutting down.
<norayr>
not less.
<norayr>
many people won't be able to care about the phone rike it is tamagocci.
<norayr>
the phone should care about itself y shutting itself down earlier and preserving enough charge to boot a le of times.
<norayr>
a couple of times.
Langoor has quit [Read error: Software caused connection abort]