elastic_dog has quit [Killed (silver.libera.chat (Nickname regained by services))]
pere has joined #maemo-leste
xes_ has quit [Ping timeout: 272 seconds]
Daaanct12 has joined #maemo-leste
Daaanct12 has quit [Quit: Quitting]
xes_ has joined #maemo-leste
mrkrisprolls has quit [Quit: Tchussss!]
mrkrisprolls has joined #maemo-leste
Wizzup has quit [Ping timeout: 246 seconds]
Wizzup has joined #maemo-leste
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
xmn has quit [Ping timeout: 252 seconds]
ceene has joined #maemo-leste
peetah has quit [Ping timeout: 248 seconds]
peetah has joined #maemo-leste
<freemangordon>
uvos: I have executed you notify-send example maybe 10 times in a row, doe not hang here
<freemangordon>
*does
<freemangordon>
combined with the fact that neither I nor Wizzup see such lockups, I am starting to think your device has some HW issue
uvos__ has joined #maemo-leste
<uvos__>
quite recently i swtiched devices beacue the other ones usb port broke
<uvos__>
so that dosent really track
<uvos__>
its possibe that the devices that hang have some commonality (incl at least sicelos device too)
<uvos__>
like one of the cpcap variants (there are 2)
<uvos__>
but otherwise i dont see it
<uvos__>
i and Wizzup are probubly also the only ones to use a d4 as the main phone, it never crashes when idle, only when doing something with it
<uvos__>
so simple usage hours might have somehting to do with seeing it often
<uvos__>
it crashing 3 times yesterday while messing wih notify send might have just been a conincidance
Pali has joined #maemo-leste
mardy has quit [Ping timeout: 260 seconds]
mardy has joined #maemo-leste
uvos__ has quit [Read error: Connection reset by peer]
Pali has quit [Ping timeout: 248 seconds]
uvos__ has joined #maemo-leste
<freemangordon>
yeah, makes sense
<freemangordon>
OTOH I am doing very heavy browsing with my device
<freemangordon>
like for an hour or so
uvos__ has quit [Ping timeout: 248 seconds]
uvos__ has joined #maemo-leste
<sicelo>
freemangordon: modem enablement works beautifully since your changes. i don't know if you're aware of https://github.com/maemo-leste/bugtracker/issues/387 ... maybe you have some spare cycles to work on it too?
nedko has quit [Ping timeout: 255 seconds]
ceene has quit [Read error: Connection reset by peer]
_CN_ has joined #maemo-leste
uvos__ has quit [Remote host closed the connection]
elastic_dog is now known as Guest566
elastic_dog has joined #maemo-leste
Guest566 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
mardy has quit [Read error: Connection reset by peer]
mardy has joined #maemo-leste
alex1216 has joined #maemo-leste
<Wizzup>
uvos: I also saw a reset laat night, nothing useful in pstore
<Wizzup>
last*
<Wizzup>
while in mpv
<Wizzup>
maybe an audio thing?
<sicelo>
at least mine doesn't involve audio (i don't use d4 to play music or similar)
uvos__ has joined #maemo-leste
<Wizzup>
I was pausing and resuming in mpv with I think '.' and ','
<Wizzup>
maybe just a big cpu load
<uvos__>
my pet theroy is that it involves ungateing sgx
<uvos__>
ie it happens when starting rendering from idle
<uvos__>
but hard to say
<uvos__>
i also very mutch get the fealing it happens most offten when the deivce nears empy
<Wizzup>
I also saw something very interesting, 1/4th of the screen horizontally got corrupted this morning
<Wizzup>
just lock&unlock made it go away
<Wizzup>
(I made a photo)
<Wizzup>
nothing in dmesg though
<uvos__>
that sounds like the dsi link issues android also has
<uvos__>
ususaly the frame transfer fails
<uvos__>
but i could see it transfering a frame and thinking its ok on rare occasions
<Wizzup>
it stayed there until I turned off the screen
<Wizzup>
it looked like the ants, just on a large concentrated area
<freemangordon>
maybe we have some cache coherency issues
<freemangordon>
OTOH I haven't seen ants on HDMI
<freemangordon>
not that I played much
<Wizzup>
right
<uvos__>
would not make a whole lot of sense if the the ants where output dependant
<uvos__>
since they are clearly in the texture buffer allready
<uvos__>
since they move with it
<uvos__>
i also think i have seen them on hdmi, but i might be missremembering
<freemangordon>
cache issues then
<freemangordon>
uvos__: do you know a better algo we can use in upower to approximate the remaining charge?
<freemangordon>
as current one so inacurate that I think we're better without it
<freemangordon>
*is so
alex1216 has quit [Ping timeout: 260 seconds]
<uvos__>
freemangordon: the one in charge-mode works well with mesured resistance. a real algo needs to calculate the resistance of the battery/cpcap path by sampling at different currents
<uvos__>
over time
<uvos__>
and saveing that
<uvos__>
then using calculated open circut voltage and current you can estimate soc fairly accuratly
<uvos__>
on a lipo discarge curve
<uvos__>
again see charge-mode
<uvos__>
this is also what android dose, except they use a discarge curve saved in the batt with presumably the internal resistance /typical cpcap path calculated in
<uvos__>
another alternative
<uvos__>
is if you can figure out that some bits in the battery eeprom are not used by android we could save the culomb counter value there
<uvos__>
im nnot sure if the eeprom is writeable atm have to check
<uvos__>
and then forget about estimateing the soc
<uvos__>
at least for mapphone
<uvos__>
s
<uvos__>
(it seams most android phones use estimateion so this problem will pop up again)
alex1216 has joined #maemo-leste
<uvos__>
delux method would be compleatly reing android batd and using the values for the soc estimation curve
<uvos__>
(and using a generic one on non-mapphones)
<uvos__>
(values from eeprom)
xmn has joined #maemo-leste
<uvos__>
upower would also have to smooth some
<uvos__>
part of the problem is that soc estimation bounces around alot depending on how loaded the device was in the ms that upower decided to estimate soc last
<freemangordon>
uvos__: still, we don;t need precise measurement
<freemangordon>
3-5% inacurracy should not be a problem
<freemangordon>
and we don;t need to store the resistance, runtime adjusted value (starting from some sane default) should suffice, no?
<freemangordon>
using eeprom is not really a good idea as we have those for d4 only
<freemangordon>
and we want to support more devices
<freemangordon>
also, what we really need is to be more precise on the 'low' ranges, like 10-30% full
<uvos__>
probubly @ no saveing resistance
<freemangordon>
hmm?
<freemangordon>
can;t parse
<uvos__>
freemangordon: as you say presumably it is enough to estimate resistance on every boot
<uvos__>
without storing it long term
<freemangordon>
mhm
<uvos__>
resummably sampling at high speed for 1minute upon eatch boot and then calculateting the resitance based on the voltage current pairs is sufficant
_CN_ has quit [Remote host closed the connection]
<uvos__>
repeating the sample interval if the current dosen change enough over that minute
<uvos__>
untill you find a minute where it dose
<freemangordon>
how many samples do we need?
<uvos__>
enough to supress noise
<freemangordon>
heh
<uvos__>
ie not sure, samling at 10hz or so should be plenty
<uvos__>
the total time interval should be as small as practical so that the voltage dosent change because soc changes
<uvos__>
maybe we can get away with < 1 min
<freemangordon>
so, we assume a simple series resistor, no capacitance?
<uvos__>
the capcaitance is not relevant
<freemangordon>
because the models I found over inet are more complicated
<freemangordon>
ok
<uvos__>
we are also smoothing so capcaticance has even less of an influence
<uvos__>
since we thow away the high freqency componants this way
<freemangordon>
mhm
* freemangordon
draws a diagram to see what the formula would be
<freemangordon>
or, do you have it already?
<uvos__>
no
<freemangordon>
We don;t have open circuit voltage, is that an issu?
<freemangordon>
I guess I have to calc it based on the samples
<uvos__>
yes thats the point essentally of calcing the resistance based on the samples
<uvos__>
to then calc open circut voltage based on that
<uvos__>
its an estimate only ofc
<uvos__>
resitance changes based on soc too
<uvos__>
also temperature etc
<freemangordon>
ok, but we can do a constant measurement, no?
<freemangordon>
if my math-fu servers me well, we can calculate Ri=(U2-U1)/(I1-I2)
<freemangordon>
we can apply the above to a series of samples and average, to ignore the noise
<freemangordon>
U2/I2 are in time t2, U1/I1 - t1
<freemangordon>
is 0,112244898 close to measured value for d4?
uvos__ has quit [Ping timeout: 248 seconds]
<freemangordon>
another measurement gives 0,233766234
<freemangordon>
hmm, I guess we shall not average, but use the highest value
<freemangordon>
uvos: ^^^ ?
<freemangordon>
to be on the safe side
uvos__ has joined #maemo-leste
alex1216 has quit [Quit: WeeChat 2.3]
uvos has joined #maemo-leste
<uvos>
freemangordon: a to high value is just as bad as to low really
<uvos>
~150mOhm is what i have mesured for my device by hand
<uvos>
so to improve mesurements
<uvos>
we shal take the mean
<uvos>
and we shal take mesruements where delta I is as large as possible
<uvos>
also you should mean the voltages and currents first
<uvos>
i would do this:
<uvos>
burst mesure 3-6 or so pairs as quickly as possible
<uvos>
take the mean of your U and I values
<uvos>
these are now the values for the time t1
<uvos>
do so again when the current is very different
<uvos>
but soon, hopefully within a minute to avoid soc changeing
<uvos>
burst mesure 3-6 or so samples again
<uvos>
mean, and those are your values for the time t2
<freemangordon>
and then rinse and repeat every 10-20 minutes?
<uvos>
right
<freemangordon>
good
<uvos>
maybe longer interval than that
<uvos>
depending how often the mesurement fails
<uvos>
because of the current not being sufficently different
<freemangordon>
yeah
<uvos>
you also probubly want to "give up"
<uvos>
after a while
<uvos>
since if the device is allways idle and the user never uses it
<uvos>
the current will be pretty mutch the same
<freemangordon>
right
<freemangordon>
well, we can artificially create load
<uvos>
you could do that
<uvos>
or wait for load
<uvos>
ie some indication that the user is around
<freemangordon>
IMO waiting for load is worse
<freemangordon>
well, upower has no means to detect it
<uvos>
hmm you could do it whenever the screen turns off and use the difference in current produced by the display
<uvos>
but yeah
<uvos>
upower dosent know
<freemangordon>
it is better to while(1) fro a second
<uvos>
ok
<freemangordon>
or even less
<freemangordon>
we need few sample under load
<freemangordon>
*samples
<uvos>
feals kind wierd
<uvos>
but maybe it is best
<freemangordon>
ok, I may implement a standalone application, just to test it
<freemangordon>
and compare with % provided for a calibrated battery
<freemangordon>
uvos: what about charging?
<freemangordon>
the same, no?
<uvos>
charging should not affect anything
<freemangordon>
mhm
<uvos>
this works very well for me with charging sdl
<uvos>
ie the current swap wen charging dosent move the charging-sdl estimate any
<uvos>
for me at least (its my value in charging-sld after all )
<freemangordon>
ok, I will take the formula to estimate the soc from charge-mode and will try to implement some sane algo
<freemangordon>
to calculate Ri
<uvos>
great
<freemangordon>
as a standalone app just as a POC
<uvos>
yeah understood
<freemangordon>
did you build the kernel for -devel?