freemangordon | uvos: I have executed you notify-send example maybe 10 times in a row, doe not hang here | 07:49 |
---|---|---|
freemangordon | *does | 07:49 |
freemangordon | combined with the fact that neither I nor Wizzup see such lockups, I am starting to think your device has some HW issue | 07:52 |
uvos__ | quite recently i swtiched devices beacue the other ones usb port broke | 08:42 |
uvos__ | so that dosent really track | 08: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 it | 08: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 it | 08:46 |
uvos__ | so simple usage hours might have somehting to do with seeing it often | 08:46 |
uvos__ | it crashing 3 times yesterday while messing wih notify send might have just been a conincidance | 08:47 |
freemangordon | yeah, makes sense | 09:23 |
freemangordon | OTOH I am doing very heavy browsing with my device | 09:23 |
freemangordon | like for an hour or so | 09:24 |
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? | 09:44 |
Wizzup | uvos: I also saw a reset laat night, nothing useful in pstore | 11:17 |
Wizzup | last* | 11:17 |
Wizzup | while in mpv | 11:17 |
Wizzup | maybe an audio thing? | 11:18 |
sicelo | at least mine doesn't involve audio (i don't use d4 to play music or similar) | 11:24 |
Wizzup | I was pausing and resuming in mpv with I think '.' and ',' | 11:27 |
Wizzup | maybe just a big cpu load | 11:27 |
uvos__ | my pet theroy is that it involves ungateing sgx | 11:30 |
uvos__ | ie it happens when starting rendering from idle | 11:30 |
uvos__ | but hard to say | 11:30 |
uvos__ | i also very mutch get the fealing it happens most offten when the deivce nears empy | 11:31 |
Wizzup | I also saw something very interesting, 1/4th of the screen horizontally got corrupted this morning | 11:32 |
Wizzup | just lock&unlock made it go away | 11:32 |
Wizzup | (I made a photo) | 11:32 |
Wizzup | nothing in dmesg though | 11:32 |
uvos__ | that sounds like the dsi link issues android also has | 11:50 |
uvos__ | ususaly the frame transfer fails | 11:50 |
uvos__ | but i could see it transfering a frame and thinking its ok on rare occasions | 11:50 |
Wizzup | it stayed there until I turned off the screen | 12:20 |
Wizzup | it looked like the ants, just on a large concentrated area | 12:40 |
freemangordon | maybe we have some cache coherency issues | 14:36 |
freemangordon | OTOH I haven't seen ants on HDMI | 14:37 |
freemangordon | not that I played much | 14:38 |
Wizzup | right | 14:40 |
uvos__ | would not make a whole lot of sense if the the ants where output dependant | 14:43 |
uvos__ | since they are clearly in the texture buffer allready | 14:43 |
uvos__ | since they move with it | 14:43 |
uvos__ | i also think i have seen them on hdmi, but i might be missremembering | 14:43 |
freemangordon | cache issues then | 14:48 |
freemangordon | uvos__: do you know a better algo we can use in upower to approximate the remaining charge? | 14:50 |
freemangordon | as current one so inacurate that I think we're better without it | 14:51 |
freemangordon | *is so | 14: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 currents | 15:04 |
uvos__ | over time | 15:04 |
uvos__ | and saveing that | 15:04 |
uvos__ | then using calculated open circut voltage and current you can estimate soc fairly accuratly | 15:05 |
uvos__ | on a lipo discarge curve | 15:05 |
uvos__ | again see charge-mode | 15: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 in | 15:06 |
uvos__ | another alternative | 15: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 there | 15:07 |
uvos__ | im nnot sure if the eeprom is writeable atm have to check | 15:07 |
uvos__ | and then forget about estimateing the soc | 15:07 |
uvos__ | at least for mapphone | 15:07 |
uvos__ | s | 15: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 curve | 15: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 some | 15: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 last | 15:14 |
freemangordon | uvos__: still, we don;t need precise measurement | 15:25 |
freemangordon | 3-5% inacurracy should not be a problem | 15:25 |
freemangordon | and we don;t need to store the resistance, runtime adjusted value (starting from some sane default) should suffice, no? | 15:26 |
freemangordon | using eeprom is not really a good idea as we have those for d4 only | 15:27 |
freemangordon | and we want to support more devices | 15:28 |
freemangordon | also, what we really need is to be more precise on the 'low' ranges, like 10-30% full | 15:31 |
uvos__ | probubly @ no saveing resistance | 15:32 |
freemangordon | hmm? | 15:32 |
freemangordon | can;t parse | 15:32 |
uvos__ | freemangordon: as you say presumably it is enough to estimate resistance on every boot | 15:44 |
uvos__ | without storing it long term | 15:44 |
freemangordon | mhm | 15:45 |
uvos__ | resummably sampling at high speed for 1minute upon eatch boot and then calculateting the resitance based on the voltage current pairs is sufficant | 15:46 |
uvos__ | repeating the sample interval if the current dosen change enough over that minute | 15:46 |
uvos__ | untill you find a minute where it dose | 15:47 |
freemangordon | how many samples do we need? | 15:47 |
uvos__ | enough to supress noise | 15:47 |
freemangordon | heh | 15:47 |
uvos__ | ie not sure, samling at 10hz or so should be plenty | 15:48 |
uvos__ | the total time interval should be as small as practical so that the voltage dosent change because soc changes | 15:48 |
uvos__ | maybe we can get away with < 1 min | 15:48 |
freemangordon | so, we assume a simple series resistor, no capacitance? | 15:49 |
uvos__ | the capcaitance is not relevant | 15:49 |
freemangordon | because the models I found over inet are more complicated | 15:49 |
freemangordon | ok | 15:49 |
uvos__ | we are also smoothing so capcaticance has even less of an influence | 15:50 |
uvos__ | since we thow away the high freqency componants this way | 15:50 |
freemangordon | mhm | 15:50 |
* freemangordon draws a diagram to see what the formula would be | 15:51 | |
freemangordon | or, do you have it already? | 15:51 |
uvos__ | no | 15:51 |
freemangordon | We don;t have open circuit voltage, is that an issu? | 15:54 |
freemangordon | I guess I have to calc it based on the samples | 15:55 |
uvos__ | yes thats the point essentally of calcing the resistance based on the samples | 15:58 |
uvos__ | to then calc open circut voltage based on that | 15:58 |
uvos__ | its an estimate only ofc | 15:59 |
uvos__ | resitance changes based on soc too | 15:59 |
uvos__ | also temperature etc | 15:59 |
freemangordon | ok, but we can do a constant measurement, no? | 16:05 |
freemangordon | if my math-fu servers me well, we can calculate Ri=(U2-U1)/(I1-I2) | 16:06 |
freemangordon | we can apply the above to a series of samples and average, to ignore the noise | 16:06 |
freemangordon | U2/I2 are in time t2, U1/I1 - t1 | 16:07 |
freemangordon | is 0,112244898 close to measured value for d4? | 16:10 |
freemangordon | another measurement gives 0,233766234 | 16:17 |
freemangordon | hmm, I guess we shall not average, but use the highest value | 16:17 |
freemangordon | uvos: ^^^ ? | 16:18 |
freemangordon | to be on the safe side | 16:18 |
uvos | freemangordon: a to high value is just as bad as to low really | 17:01 |
uvos | ~150mOhm is what i have mesured for my device by hand | 17:02 |
uvos | so to improve mesurements | 17:03 |
uvos | we shal take the mean | 17:03 |
uvos | and we shal take mesruements where delta I is as large as possible | 17:03 |
uvos | also you should mean the voltages and currents first | 17:04 |
uvos | i would do this: | 17:05 |
uvos | burst mesure 3-6 or so pairs as quickly as possible | 17:05 |
uvos | take the mean of your U and I values | 17:05 |
uvos | these are now the values for the time t1 | 17:05 |
uvos | do so again when the current is very different | 17:06 |
uvos | but soon, hopefully within a minute to avoid soc changeing | 17:06 |
uvos | burst mesure 3-6 or so samples again | 17:06 |
uvos | mean, and those are your values for the time t2 | 17:06 |
freemangordon | and then rinse and repeat every 10-20 minutes? | 17:06 |
uvos | right | 17:07 |
freemangordon | good | 17:07 |
uvos | maybe longer interval than that | 17:07 |
uvos | depending how often the mesurement fails | 17:07 |
uvos | because of the current not being sufficently different | 17:07 |
freemangordon | yeah | 17:07 |
uvos | you also probubly want to "give up" | 17:07 |
uvos | after a while | 17:07 |
uvos | since if the device is allways idle and the user never uses it | 17:08 |
uvos | the current will be pretty mutch the same | 17:08 |
freemangordon | right | 17:08 |
freemangordon | well, we can artificially create load | 17:08 |
uvos | you could do that | 17:08 |
uvos | or wait for load | 17:08 |
uvos | ie some indication that the user is around | 17:08 |
freemangordon | IMO waiting for load is worse | 17:08 |
freemangordon | well, upower has no means to detect it | 17:09 |
uvos | hmm you could do it whenever the screen turns off and use the difference in current produced by the display | 17:09 |
uvos | but yeah | 17:09 |
uvos | upower dosent know | 17:09 |
freemangordon | it is better to while(1) fro a second | 17:10 |
uvos | ok | 17:10 |
freemangordon | or even less | 17:10 |
freemangordon | we need few sample under load | 17:10 |
freemangordon | *samples | 17:10 |
uvos | feals kind wierd | 17:11 |
uvos | but maybe it is best | 17:11 |
freemangordon | ok, I may implement a standalone application, just to test it | 17:12 |
freemangordon | and compare with % provided for a calibrated battery | 17:12 |
freemangordon | uvos: what about charging? | 17:13 |
freemangordon | the same, no? | 17:13 |
uvos | charging should not affect anything | 17:13 |
freemangordon | mhm | 17:13 |
uvos | this works very well for me with charging sdl | 17:13 |
uvos | ie the current swap wen charging dosent move the charging-sdl estimate any | 17:14 |
uvos | for me at least (its my value in charging-sld after all ) | 17:14 |
freemangordon | ok, I will take the formula to estimate the soc from charge-mode and will try to implement some sane algo | 17:14 |
freemangordon | to calculate Ri | 17:14 |
uvos | great | 17:14 |
freemangordon | as a standalone app just as a POC | 17:14 |
uvos | yeah understood | 17:15 |
freemangordon | did you build the kernel for -devel? | 17:15 |
uvos | yes | 17:15 |
uvos | altho i dident check if it suceeded | 17:15 |
freemangordon | it failed :) | 17:15 |
uvos | ok | 17:16 |
freemangordon | https://phoenix.maemo.org/job/droid4-linux-source/190/ | 17:16 |
uvos | ill look in 1h | 17:16 |
freemangordon | sure, no hurry | 17:16 |
freemangordon | I won;t be able to measure off draw today | 17:17 |
buZz | gee 'simple countdown timer' is 7.7MB :O | 18:04 |
Wizzup | buZz: it probably pulls in Qt deps | 18:12 |
buZz | not sure, i installed it through app manager, but that would explain it | 18:13 |
Wizzup | it seems to be 34kB | 18:13 |
buZz | ah :) | 18:15 |
buZz | new kernel hit -devel \o/ | 21:46 |
buZz | omap kernel* | 21:50 |
buZz | yay! max_design read from battery works \o/ | 21:51 |
buZz | hehe, my droid4 turns singlecore by the new kernel :) | 21:54 |
* buZz tries coldbooting it | 21:55 | |
buZz | 2 cores again after a coldboot, not sure | 22:01 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!