libera/#maemo-leste/ Tuesday, 2022-11-08

freemangordonuvos: I have executed you notify-send example maybe 10 times in a row, doe not hang here07:49
freemangordon*does07:49
freemangordoncombined with the fact that neither I nor Wizzup see such lockups, I am starting to think your device has some HW issue07:52
uvos__quite recently i swtiched devices beacue the other ones usb port broke08:42
uvos__so that dosent really track08:42
uvos__its possibe that the devices that hang have some commonality (incl at least sicelos device too)08:44
uvos__like one of the cpcap variants (there are 2)08:44
uvos__but otherwise i dont see it08:45
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 it08:46
uvos__so simple usage hours might have somehting to do with seeing it often08:46
uvos__it crashing 3 times yesterday while messing wih notify send might have just been a conincidance08:47
freemangordonyeah, makes sense09:23
freemangordonOTOH I am doing very heavy browsing with my device09:23
freemangordonlike for an hour or so09:24
sicelofreemangordon: 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?09:44
Wizzupuvos: I also saw a reset laat night, nothing useful in pstore11:17
Wizzuplast*11:17
Wizzupwhile in mpv11:17
Wizzupmaybe an audio thing?11:18
siceloat least mine doesn't involve audio (i don't use d4 to play music or similar)11:24
WizzupI was pausing and resuming in mpv with I think '.' and ','11:27
Wizzupmaybe just a big cpu load11:27
uvos__my pet theroy is that it involves ungateing sgx11:30
uvos__ie it happens when starting rendering from idle11:30
uvos__but hard to say11:30
uvos__i also very mutch get the fealing it happens most offten when the deivce nears empy11:31
WizzupI also saw something very interesting, 1/4th of the screen horizontally got corrupted this morning11:32
Wizzupjust lock&unlock made it go away11:32
Wizzup(I made a photo)11:32
Wizzupnothing in dmesg though11:32
uvos__that sounds like the dsi link issues android also has11:50
uvos__ususaly the frame transfer fails11:50
uvos__but i could see it transfering a frame and thinking its ok on rare occasions11:50
Wizzupit stayed there until I turned off the screen12:20
Wizzupit looked like the ants, just on a large concentrated area12:40
freemangordonmaybe we have some cache coherency issues14:36
freemangordonOTOH I haven't seen ants on HDMI14:37
freemangordonnot that I played much14:38
Wizzupright14:40
uvos__would not make a whole lot of sense if the the ants where output dependant14:43
uvos__since they are clearly in the texture buffer allready14:43
uvos__since they move with it14:43
uvos__i also think i have seen them on hdmi, but i  might be missremembering14:43
freemangordoncache issues then14:48
freemangordonuvos__: do you know a better algo we can use in upower to approximate the remaining charge?14:50
freemangordonas current one so inacurate that I think we're better without it14:51
freemangordon*is so14:51
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 currents15:04
uvos__over time15:04
uvos__and saveing that15:04
uvos__then using calculated open circut voltage and current you can estimate soc fairly accuratly15:05
uvos__on a lipo discarge curve15:05
uvos__again see charge-mode15:05
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 in15:06
uvos__another alternative15:06
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 there15:07
uvos__im nnot sure if the eeprom is writeable atm have to check15:07
uvos__and then forget about estimateing the soc15:07
uvos__at least for mapphone15:07
uvos__s15:08
uvos__(it seams most android phones use estimateion so this problem will pop up again)15:08
uvos__delux method would be compleatly reing android batd and using the values for the soc estimation curve15:11
uvos__(and using a generic one on non-mapphones)15:11
uvos__(values from eeprom)15:12
uvos__upower would also have to smooth some15:13
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 last15:14
freemangordonuvos__: still, we don;t need precise measurement15:25
freemangordon3-5% inacurracy should not be a problem15:25
freemangordonand we don;t need to store the resistance, runtime adjusted value (starting from some sane default) should suffice, no?15:26
freemangordonusing eeprom is not really a good idea as we have those for d4 only15:27
freemangordonand we want to support more devices15:28
freemangordonalso, what we really need is to be more precise on the 'low' ranges, like 10-30% full15:31
uvos__probubly @ no saveing resistance15:32
freemangordonhmm?15:32
freemangordoncan;t parse15:32
uvos__freemangordon: as you say presumably it is enough to estimate resistance on every boot15:44
uvos__without storing it long term15:44
freemangordonmhm15:45
uvos__resummably sampling at high speed for 1minute upon eatch boot and then calculateting the resitance based on the voltage current pairs is sufficant15:46
uvos__repeating the sample interval if the current dosen change enough over that minute15:46
uvos__untill you find a minute where it dose15:47
freemangordonhow many samples do we need?15:47
uvos__enough to supress noise15:47
freemangordonheh15:47
uvos__ie not sure, samling at 10hz or so should be plenty15:48
uvos__the total time interval should be as small as practical so that the voltage dosent change because soc changes15:48
uvos__maybe we can get away with < 1 min15:48
freemangordonso, we assume a simple series resistor, no capacitance?15:49
uvos__the capcaitance is not relevant15:49
freemangordonbecause the models I found over inet are more complicated15:49
freemangordonok15:49
uvos__we are also smoothing so capcaticance has even less of an influence15:50
uvos__since we thow away the high freqency componants this way15:50
freemangordonmhm15:50
* freemangordon draws a diagram to see what the formula would be15:51
freemangordonor, do you have it already?15:51
uvos__no15:51
freemangordonWe don;t have open circuit voltage, is that an issu?15:54
freemangordonI guess I have to calc it based on the samples15:55
uvos__yes thats the point essentally of calcing the resistance based on the samples15:58
uvos__to then calc open circut voltage based on that15:58
uvos__its an estimate only ofc15:59
uvos__resitance changes based on soc too15:59
uvos__also temperature etc15:59
freemangordonok, but we can do a constant measurement, no?16:05
freemangordonif my math-fu servers me well, we can calculate Ri=(U2-U1)/(I1-I2)16:06
freemangordonwe can apply the above to a series of samples and average, to ignore the noise16:06
freemangordonU2/I2 are in time t2, U1/I1 - t116:07
freemangordonis 0,112244898 close to measured value for d4?16:10
freemangordonanother measurement gives 0,23376623416:17
freemangordonhmm, I guess we shall not average, but use the highest value16:17
freemangordonuvos: ^^^ ?16:18
freemangordonto be on the safe side16:18
uvosfreemangordon: a to high value is just as bad as to low really17:01
uvos~150mOhm is what i have mesured for my device by hand17:02
uvosso to improve mesurements17:03
uvoswe shal take the mean17:03
uvosand we shal take mesruements where delta I is as large as possible17:03
uvosalso you should mean the voltages and currents first17:04
uvosi would do this:17:05
uvosburst mesure 3-6 or so pairs as quickly as possible17:05
uvostake the mean of your U and I values17:05
uvosthese are now the values for the time t117:05
uvosdo so again when the current is very different17:06
uvosbut soon, hopefully within a minute to avoid soc changeing17:06
uvosburst mesure 3-6 or so samples again17:06
uvosmean, and those are your values for the time t217:06
freemangordonand then rinse and repeat every 10-20 minutes?17:06
uvosright17:07
freemangordongood17:07
uvosmaybe longer interval than that17:07
uvosdepending how often the mesurement fails17:07
uvosbecause of the current not being sufficently different17:07
freemangordonyeah17:07
uvosyou also probubly want to "give up"17:07
uvosafter a while17:07
uvossince if the device is allways idle and the user never uses it17:08
uvosthe current will be pretty mutch the same17:08
freemangordonright17:08
freemangordonwell, we can artificially create load17:08
uvosyou could do that17:08
uvosor wait for load17:08
uvosie some indication that the user is around17:08
freemangordonIMO waiting for load is worse17:08
freemangordonwell, upower has no means to detect it17:09
uvoshmm you could do it whenever the screen turns off and use the difference in current produced by the display17:09
uvosbut  yeah17:09
uvosupower dosent know17:09
freemangordonit is better to while(1) fro a second17:10
uvosok17:10
freemangordonor even less17:10
freemangordonwe need few sample under load17:10
freemangordon*samples17:10
uvosfeals kind wierd17:11
uvosbut maybe it is best17:11
freemangordonok, I may implement a standalone application, just to test it17:12
freemangordonand compare with % provided for a calibrated battery17:12
freemangordonuvos: what about charging?17:13
freemangordonthe same, no?17:13
uvoscharging should not affect anything17:13
freemangordonmhm17:13
uvosthis works very well for me with charging sdl17:13
uvosie the current swap wen charging dosent move the charging-sdl estimate any17:14
uvosfor me at least (its my value in charging-sld after all )17:14
freemangordonok, I will take the formula to estimate the soc from charge-mode and will try to implement some sane algo17:14
freemangordonto calculate Ri17:14
uvosgreat17:14
freemangordonas a standalone app just as a POC17:14
uvosyeah understood17:15
freemangordondid you build the kernel for -devel?17:15
uvosyes17:15
uvosaltho i dident check if it suceeded17:15
freemangordonit failed :)17:15
uvosok17:16
freemangordonhttps://phoenix.maemo.org/job/droid4-linux-source/190/17:16
uvosill look in 1h17:16
freemangordonsure, no hurry17:16
freemangordonI won;t be able to measure off draw today17:17
buZzgee 'simple countdown timer' is 7.7MB :O18:04
WizzupbuZz: it probably pulls in Qt deps18:12
buZznot sure, i installed it through app manager, but that would explain it18:13
Wizzupit seems to be 34kB18:13
buZzah :)18:15
buZznew kernel hit -devel \o/21:46
buZzomap kernel*21:50
buZzyay! max_design read from battery works \o/21:51
buZzhehe, my droid4 turns singlecore by the new kernel :)21:54
* buZz tries coldbooting it21:55
buZz2 cores again after a coldboot, not sure22:01

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!