| Wizzup | uvos: what config stuff? | 00:43 |
|---|---|---|
| Wizzup | Ah, I see | 00:44 |
| Wizzup | heh I saw this through my backup script first: | 00:44 |
| Wizzup | From https://github.com/maemo-leste/libhildonmime * [new ref] refs/pull/3/head -> refs/pull/3/head * [new ref] refs/pull/3/merge -> refs/pull/3/merge | 00:44 |
| Wizzup | freemangordon: heads up, BlagovestPetrov[ found https://bugreports.qt.io/browse/QTBUG-93954?jql=component%20%3D%20%22Core%3A%20Plugins%22%20AND%20project%20%3D%20QTBUG | 00:48 |
| BlagovestPetrov[ | :| | 00:49 |
| Wizzup | uvos: heh ok my d4 still had the pa echo cancel loaded, hence the power draw | 01:46 |
| Wizzup | somehow the gst stuff also pulls elogind it seems | 01:50 |
| Wizzup | I guess we'll just have to switch... | 01:50 |
| Wizzup | ah no, it's gvfs | 01:50 |
| 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. | 07:48 |
| freemangordon | Wizzup: don't want what to say | 08:30 |
| freemangordon | 5.15 is LTS, but I don;t know when we will hit it | 08:32 |
| freemangordon | uvos; re SOC estimation - it seems for lower values this estimation is even worse | 08:35 |
| freemangordon | calculated 49 reported 31 | 08:35 |
| freemangordon | for Ri ~= 0.1 that seems to be about right | 08:35 |
| uvos | freemangordon: huh, it follows the coding style as far as i can tell | 08:37 |
| uvos | i reindented hildon_mime_open_file_with_mime_type since it is indented with spaces while everything else in that file uses tabs | 08:37 |
| freemangordon | yes, but you mixed declarations with code | 08:37 |
| freemangordon | also, original coding style has space between function name and bracket | 08:38 |
| uvos | ah is ok | 08:38 |
| uvos | *i see | 08:38 |
| freemangordon | also, it has empty lines before and after if() blocks :p | 08:38 |
| uvos | sec ill fix that | 08:38 |
| freemangordon | wait | 08:38 |
| freemangordon | already fixed | 08:38 |
| uvos | ok | 08:38 |
| freemangordon | along with return values | 08:38 |
| freemangordon | uvos: https://github.com/maemo-leste/libhildonmime/commit/a6c978c66a2448282205d3e8d0c310891b9d915c | 08:39 |
| freemangordon | please have a look if I have missed something | 08:39 |
| uvos | freemangordon: any idea whats up with *file in hildon_mime_open_file_with_mime_type? | 08:40 |
| freemangordon | no | 08:40 |
| uvos | idk if the comment or the code is wrong | 08:40 |
| freemangordon | I guess the code | 08:40 |
| freemangordon | like, they designed the API to be like that | 08:40 |
| freemangordon | but, didn;t implement it :) | 08:40 |
| uvos | success ? 1 : 0; seems pointless on a boolean, why re-add it? dose geboolean have some special proparty different from _Bool? | 08:42 |
| freemangordon | I have no idea and we are not guaranteed that current gboolean implementation will remain the same | 08:44 |
| freemangordon | TBH even curent code is buggy | 08:44 |
| freemangordon | it should be something like success == TRUE ? 1 : 0 | 08:44 |
| uvos | well (int)bool == 1 or 0 seams like a safe assumption to me | 08:44 |
| uvos | but ok | 08:45 |
| freemangordon | it is not bool | 08:45 |
| freemangordon | ah, yes | 08:45 |
| freemangordon | but, we don;t know what !!gbollean_var is (in theory) | 08:45 |
| freemangordon | gboolean is int now, but that's implementation detail we shall not rely on | 08:46 |
| freemangordon | anyway | 08:46 |
| uvos | if anything it will switch to typedef _Bool at some point | 08:46 |
| uvos | but ok | 08:46 |
| freemangordon | I am not sure glib uses _Bool | 08:47 |
| uvos | no it dosent | 08:47 |
| freemangordon | typedef gint gboolean; | 08:47 |
| uvos | im saying i doubt gbloolean will ever change in a non compatabil way | 08:47 |
| uvos | ie it may swich to _Bool beyond that i doubt it will change ever | 08:47 |
| freemangordon | right, but that does not mean we shall count on that. not important though | 08:48 |
| freemangordon | but, IIUC, the real book fix for 'success ? 1 : 0' is 'success == TRUE ? 1 : 0' | 08:49 |
| freemangordon | not doing implicit cast from gboolean to gint | 08:49 |
| freemangordon | anyway | 08:49 |
| freemangordon | my 'please have a look' was rather 'do you see anything obviously wrong with what I did?' | 08:50 |
| freemangordon | becasue I did compile-test only | 08:51 |
| freemangordon | have to attend work mtg, ttyl | 08:51 |
| uvos | freemangordon: i see no problem | 09:34 |
| uvos | yeah success == TRUE ? 1 : 0 makes some sense | 09:34 |
| uvos | success ? 1 : 0 dosent make much more sense than just return success really | 09:35 |
| freemangordon | Calculated r = 0.156463, Ri = 0.142464 for Imax=339mA@3672mV, Imin=192@3695mV | 10:13 |
| freemangordon | calculated 45 reported 21 | 10:13 |
| freemangordon | uvos: ^^^ | 10:13 |
| freemangordon | this is useless | 10:13 |
| freemangordon | Ri seems to be about right | 10:14 |
| freemangordon | but not the prediction | 10:14 |
| uvos | wierd it works really quite well for chargeing_sld in my expieraments | 10:40 |
| uvos | freemangordon: i gues next step would be to do what i said to tmlind yesterday | 10:40 |
| uvos | at least once | 10:40 |
| uvos | record ri,mA,mV and soc while callibrated | 10:41 |
| uvos | and derive a new algo from that | 10:41 |
| uvos | freemangordon: do you have any awnser wrt the question in the pr btw? | 10:41 |
| uvos | gconf/gsettings/something else when implementing new config values | 10:41 |
| uvos | i gues xdg-mime works by external utilities changeing config files | 10:42 |
| uvos | so thats an option for libhildonmime too | 10:42 |
| freemangordon | uvos: I don;t see how would it work in charging_sdl | 10:54 |
| freemangordon | it seems either your or mine experiments are flawed | 10:55 |
| uvos | well i did it with a eb41 and i gues for charging_sdl the absolute value is not so important as long as 0% is really 0% and 100% is really 100 | 10:55 |
| uvos | but i remember spot checking it at a couple of values and being satisfied | 10:56 |
| uvos | anyhow i gues we shal create a offset table, want me to do this or will do you want to? | 10:56 |
| freemangordon | I don;t think that's be accepted upstream | 10:57 |
| uvos | ok | 10:57 |
| freemangordon | *that'd | 10:57 |
| uvos | well afaik we only use soc in the status applet | 10:58 |
| uvos | so we could just estimate there | 10:58 |
| freemangordon | I am not sure they will want to accept any estimation algo | 10:58 |
| uvos | yeah | 10:58 |
| freemangordon | but, without having something that satisfies us at least, there is no point in opening issue at all | 11:03 |
| uvos | sure and i see 2 options here. 1 genrate tabels and use those. 2 generate tables and fit a math function to it and then use that. | 11:04 |
| uvos | and then either implmement the result in upower or the battery applet | 11:04 |
| uvos | dose also feal a bit like we are reimplementing the wheel, but as far as i can tell existing wheels apear square. | 11:06 |
| Wizzup | freemangordon: what was this about: 08:30 < freemangordon> Wizzup: don't want what to say | 11:27 |
| freemangordon | qt | 11:42 |
| Wizzup | ok | 11:43 |
| freemangordon | uvos: right | 11:43 |
| freemangordon | I guess I can fire matlab and find a n-th order polynomial that fits my battery | 11:43 |
| freemangordon | but how useful that would be in general? | 11:44 |
| Wizzup | https://packages.debian.org/bullseye/qt5-style-plugins | 11:44 |
| Wizzup | I mean debian has it, so I'm sure we can rebase on their patches | 11:44 |
| freemangordon | yes, and decide what to do when and if we hit 5.15 | 11:44 |
| Wizzup | https://salsa.debian.org/qt-kde-team/qt/qtstyleplugins/-/blob/debian/5.0.0+git23.g335dbec-4/debian/patches/fix-build-qt5.15.patch | 11:44 |
| Wizzup | BlagovestPetrov[: ^ | 11:44 |
| freemangordon | oh | 11:44 |
| Wizzup | seems easy enough | 11:45 |
| Wizzup | :) | 11:45 |
| uvos | freemangordon: good question, i really dont know. i gues motorola thought they needed a table for eatch battery. | 11:45 |
| Wizzup | maybe support to load a table in power? | 11:45 |
| freemangordon | uvos: what makes you think that? | 11:45 |
| freemangordon | you know what? | 11:45 |
| uvos | freemangordon: eatch battery type | 11:45 |
| freemangordon | I think we can implement in battery applet | 11:45 |
| uvos | freemangordon: well they put the table into the eeprom | 11:45 |
| freemangordon | no | 11:46 |
| uvos | that suggests they think so no? | 11:46 |
| BlagovestPetrov[ | :) | 11:46 |
| uvos | no? whats the other data in the eeprom then? | 11:46 |
| freemangordon | uvos: ah, you mean 'each battery type'? | 11:46 |
| uvos | yes | 11:46 |
| freemangordon | ok, yeah | 11:46 |
| uvos | your polynomal needs to work on eatch battery there can be | 11:46 |
| freemangordon | yes | 11:46 |
| uvos | eb41 nexus4 hw4x bw8x etc | 11:46 |
| freemangordon | but, lets scratch upower | 11:47 |
| freemangordon | and implement in battery applet | 11:47 |
| uvos | check | 11:47 |
| freemangordon | Wizzup: ^^^? | 11:47 |
| freemangordon | they will never accept as self-learning estimation algo, I believe | 11:47 |
| uvos | yeah | 11:48 |
| 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 | 11:49 |
| uvos | but thats details | 11:49 |
| uvos | *directly in the status applet | 11:49 |
| Wizzup | freemangordon: how will this help mce decide when to shut down? | 11:51 |
| Wizzup | or do we not need it? | 11:51 |
| uvos | mce will continue to use the kernel low signal or voltage to shut down | 11:51 |
| uvos | it dosent use soc | 11:51 |
| Wizzup | freemangordon: how will you sync upower selecting the right battery with battery applet selecting the right one? | 11:51 |
| uvos | soc estimator will use upower for the information | 11:52 |
| uvos | so no issue | 11:52 |
| Wizzup | can other applicaties read this percentage? | 11:52 |
| Wizzup | we have many other applications that rely on upower to read/send battery | 11:52 |
| Wizzup | for example for bluetooth it exposes the battery status to the car | 11:53 |
| uvos | ok | 11:53 |
| uvos | so i suggested makeing the estimator a lib | 11:53 |
| Wizzup | and we have apps that read it (navigation apps) | 11:53 |
| Wizzup | it's not a problem if we don't have it only during calibration btw | 11:53 |
| Wizzup | just stating the potential non obvious | 11:53 |
| uvos | navigation apps reading soc is a good point | 11:54 |
| freemangordon | doe upower support plugins? | 11:56 |
| freemangordon | *does | 11:56 |
| 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 | 11:56 |
| freemangordon | voltage->soc? | 11:57 |
| freemangordon | what kind of table is that? | 11:57 |
| uvos | dts is the wrong place anyhow | 11:57 |
| uvos | how yould that work with xt875 that can have hw4x or bw8x | 11:58 |
| freemangordon | we can overlay | 11:58 |
| uvos | i dont see how thats usefull with devices that can change battery type at any time | 11:58 |
| tmlind | battery specific data can be in dts if always the same, nothing stopping initializing it in the driver based on the battery type | 11:58 |
| freemangordon | anyway, blood sugar levels are dropping... | 11:58 |
| freemangordon | ttyl | 11:58 |
| uvos | tmlind: ok yeah | 11:59 |
| uvos | but i dont find haveing a table in dts for every possible battery type that apealing really | 11:59 |
| tmlind | ok | 12:00 |
| tmlind | fyi $ git grep ocv drivers/power/supply/ | 12:00 |
| freemangordon | uvos: we can load dts overlay | 12:01 |
| freemangordon | that is battery specific | 12:02 |
| uvos | theres a voltag->soc table in samsung-sdi-battery.c | 12:03 |
| uvos | multiple drivers it seams | 12:03 |
| uvos | so mutch for "no synthesized values" :P | 12:03 |
| freemangordon | :) | 12:03 |
| uvos | kernel battery.yaml | 12:05 |
| uvos | ocv-capacity-table | 12:05 |
| uvos | An array providing the open circuit voltage (OCV) | 12:05 |
| uvos | of the battery and corresponding battery capacity percent, which is used | 12:05 |
| uvos | to look up battery capacity according to current OCV value. And the open | 12:05 |
| uvos | circuit voltage unit is microvolt. | 12:05 |
| uvos | so yeah | 12:05 |
| freemangordon | is that handled by the framework? | 12:06 |
| freemangordon | or each driver have to support that? | 12:06 |
| tmlind | oh cool samsung-sdi-battery.c also has the samsung_maint_charge_table with a timer :) | 12:06 |
| freemangordon | ttyl, lunch | 12:07 |
| uvos | freemangordon: framwork can do it | 12:10 |
| uvos | the implementaion in samsung-sdi-battery.c is "old" or "wrong" | 12:10 |
| uvos | see power_supply_ocv2cap_simple | 12:11 |
| uvos | struct power_supply_battery_info.ocv_table | 12:11 |
| uvos | havent found where ocv is supposed to be calculated | 12:12 |
| uvos | from voltage+current+rI+temperature | 12:12 |
| uvos | ah resistance-temp-table yes power_supply_vbat2ri, struct power_supply_vbat_ri_table *vbat2ri_discharging | 12:16 |
| uvos | its all there | 12:16 |
| uvos | git blame: e9e7d165b4b04 Linus Walleij 2022-02-26 | 12:17 |
| uvos | all of this is quite recent | 12:17 |
| uvos | thank you Mr Walleij :P | 12:18 |
| uvos | i honstly find upower geting off thair asses and implementing soc estiamtion would have been better than shoveing in into the kernel | 12:19 |
| uvos | but this solves the immidiate problem | 12:20 |
| uvos | freemangordon: it would seam sc27xx_fuel_gauge is the only current user of these framework features | 12:21 |
| 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) | 12:28 |
| tmlind | well at least batteries with no rom need tables generated | 12:49 |
| freemangordon | uvos: I think that we can generate and load dts overlay in run-time | 12:50 |
| freemangordon | tmlind: do you know how userspace loads dts overlay? | 12:51 |
| freemangordon | ok, through configfs | 12:52 |
| freemangordon | it seems everything is here | 12:52 |
| freemangordon | https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/guides/dt-overlays.md.html#2-enable-overlay-support-in-kernel | 12:53 |
| freemangordon | but, we lack generic battery driver that uses this information | 12:56 |
| freemangordon | so, even if we somehow put that info in the kernel, there are no users :( | 12:58 |
| uvos | for mapphones its just replaceing the ENODATA with the framework estmation functions | 12:58 |
| uvos | in cpcap-battery | 12:58 |
| freemangordon | I guess this shall happen in the framework | 12:58 |
| uvos | it dosent atm | 12:59 |
| freemangordon | not in each and every driver | 12:59 |
| uvos | but yeah | 12:59 |
| uvos | but otherwise the driver dosent have to do anything | 12:59 |
| uvos | since framework loads the table | 12:59 |
| uvos | and has the estmiation functions | 12:59 |
| freemangordon | mhm | 13:01 |
| freemangordon | actually, it seems there is one driver using that | 13:01 |
| uvos | sc27xx_fuel_gauge? | 13:01 |
| uvos | dident find any other users | 13:01 |
| uvos | and its not generic | 13:01 |
| freemangordon | https://elixir.bootlin.com/linux/latest/source/drivers/power/supply/ab8500_fg.c#L862 | 13:02 |
| freemangordon | so it seems it accounts for the temperature as well | 13:02 |
| uvos | yes | 13:02 |
| uvos | both ri and ocv2cap can have multiple tables | 13:03 |
| uvos | per temperature | 13:03 |
| freemangordon | but I don;t see how to put that in the framework | 13:04 |
| uvos | why not? it could have a dts value as phandle to an iio device | 13:04 |
| freemangordon | no, I mean - how to plug it without drivers knowing about it | 13:05 |
| uvos | ? | 13:05 |
| uvos | fw has a wrapper around get_property that replaces -ENODATA with estiamtion | 13:06 |
| uvos | if all values are present | 13:06 |
| uvos | dont see why not | 13:06 |
| freemangordon | does it have it? | 13:06 |
| freemangordon | where? | 13:06 |
| uvos | no - it dosent, i could | 13:06 |
| uvos | but lets not rock the boat here and try change the framwork | 13:07 |
| uvos | *it could | 13:07 |
| freemangordon | I think this is what shall be implementd | 13:07 |
| freemangordon | if there are tables but the driver either does not support or returns -ENODATA a fallback patch shall be taken | 13:07 |
| freemangordon | *path | 13:08 |
| uvos | i think this would be better | 13:08 |
| uvos | but i fear us trying to merge any framework changes | 13:08 |
| freemangordon | we can try at least | 13:08 |
| 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 | 13:09 |
| freemangordon | but, beiong afraid to send patches to lkml... | 13:10 |
| freemangordon | it should not be like that | 13:10 |
| freemangordon | me personally, I will wait till next week and will start making noise | 13:11 |
| buZz | are we going to make the battery data defined by DTS? | 13:12 |
| freemangordon | buZz: something like that | 13:12 |
| buZz | ooo thats a nice idea | 13:12 |
| 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 | 13:13 |
| sicelo | this will be a voltage to SOC mapping? | 13:13 |
| freemangordon | yes | 13:13 |
| freemangordon | and we can teach power supply framework to fallback to those if driver does not provide capacity level data | 13:14 |
| freemangordon | how we will generate such tables is another story | 13:14 |
| uvos | notably all the code for voltage->soc mapping is allready in the kernel, its just usually not used. | 13:14 |
| 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 | 13:15 |
| sicelo | this way, any random fg, no matter how limited it may be, will not shutdown device at wrong time | 13:15 |
| uvos | im not sure how accurate soc is not important | 13:15 |
| freemangordon | sicelo: SOC, in terms of energy, is maybe the most important parameter | 13:16 |
| freemangordon | s/parameter/value | 13:16 |
| buZz | what does SOC stand for? | 13:16 |
| uvos | state of charge | 13:16 |
| buZz | ahhhh | 13:16 |
| buZz | yes | 13:16 |
| freemangordon | % capacity, IOW | 13:16 |
| buZz | just by voltage :O | 13:17 |
| freemangordon | % remaining capacity | 13:17 |
| freemangordon | yes, it can be done | 13:17 |
| uvos | buZz: kernel can do same thing android dose | 13:17 |
| buZz | hmhm | 13:17 |
| sicelo | i am not sure it's that important ... hence some FG don't natively provide it. what am i missing? :-) | 13:17 |
| uvos | buZz: by using the voltage internal resitance and current in a table | 13:17 |
| uvos | to provide soc | 13:17 |
| freemangordon | sicelo: they have couloumb conters, no? | 13:17 |
| freemangordon | how do those 'gauges' actually measure anything? | 13:18 |
| freemangordon | a chip providing voltage is not really a gauge if you ask me | 13:18 |
| uvos | yeah imo a guage has a counter and a palce to store the value | 13:19 |
| uvos | thus cpcap is almost a guage | 13:19 |
| buZz | are the current_avg etc all based on voltage as-is? | 13:19 |
| uvos | current is based on current | 13:19 |
| uvos | cpcap has a shunt | 13:19 |
| sicelo | now we're going towards terminology... I'm k | 13:19 |
| freemangordon | uvos: btw, why calibration is being reset after restart? | 13:19 |
| uvos | freemangordon: we have no where to store it | 13:20 |
| uvos | and the counter is rest to 0 on cpcap rest | 13:20 |
| freemangordon | sicelo: no, it is about functionality | 13:20 |
| buZz | we could store it somewhere? | 13:20 |
| uvos | no | 13:20 |
| uvos | since we dont know if the battery was removed or if android used it etc | 13:20 |
| buZz | right | 13:20 |
| freemangordon | sicelo: what functionality provides a so-called gauge that provides neither SOC nor couloumb counting? | 13:21 |
| 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 | 13:23 |
| freemangordon | you don;t actually know how much fuel you have left in the tank | 13:23 |
| freemangordon | the same is with battery voltage and remaining capacity IMO | 13:23 |
| buZz | especially if you only look at voltage 'now' | 13:25 |
| buZz | as currentdraw might be high atm | 13:25 |
| freemangordon | that one as well | 13:25 |
| buZz | its not a easy problem to know capacity of a battery usually | 13:25 |
| uvos | hence us discussing this very problem for like 3 days now :P | 13:26 |
| buZz | ohh btw, adding the 2250 instead of 1740 , increases weight of d4 by ~4 grams :) | 13:26 |
| freemangordon | ummm, what? | 13:26 |
| buZz | uvos: honestly feels like forever ;) | 13:26 |
| uvos | the nexus 4 battery is hevier than eb41 | 13:26 |
| buZz | freemangordon: the battery is slightly heavier | 13:26 |
| uvos | noticably so | 13:26 |
| freemangordon | ah | 13:26 |
| buZz | about 3% heavier, you can notice it if you have two devices | 13:27 |
| freemangordon | yeah | 13:27 |
| uvos | i gues einsteins law stipuates that the battery is lighter when empty | 13:27 |
| uvos | since there is less engery in the molecular bonding forces in this state | 13:28 |
| uvos | but its not 4g xD | 13:28 |
| freemangordon | do we have the same number of electrons? | 13:28 |
| uvos | sure, but energy levels are higher in the bonds | 13:28 |
| freemangordon | I guess yes, but in lower energy state | 13:28 |
| uvos | yup | 13:29 |
| freemangordon | actually, initially I understood buZz' comment to be something in that regard | 13:29 |
| uvos | me too, at first | 13:30 |
| uvos | thus the comment | 13:30 |
| freemangordon | like, if the battery is charged to 2250 instead of 1750 it becomes heavier :D | 13:30 |
| buZz | freemangordon: i'm quite sure there's just more layers of lithium stacked into the cell | 13:30 |
| freemangordon | which most-probably is true, but not something we can measure | 13:31 |
| buZz | why not? we have a scale :D | 13:31 |
| buZz | i pretty much doubt it'll be measurable | 13:31 |
| uvos | i dont think you realize the degree of small this change would be | 13:32 |
| buZz | it'll be <0.1gr i guess | 13:32 |
| freemangordon | no | 13:32 |
| freemangordon | something like 1*10^-100 | 13:32 |
| sicelo | the table will be v & soc only, or include other parameters too? | 13:32 |
| buZz | thats <0.1 then :P | 13:32 |
| freemangordon | no, thats << 0.1 ;) | 13:33 |
| freemangordon | sicelo: I think there is some temperature tables as well | 13:33 |
| * sicelo whispers *serial* to Wizzup... managed last night? | 13:33 | |
| freemangordon | but even with one table that's dynamically updated, it should be pretty much correct for the purpose we use it | 13:33 |
| freemangordon | +/- 2-3 % should not matter | 13:34 |
| buZz | btw its kinda funny to see 'current_avg' on disconnected vs gprs connected vs wifi connected | 13:36 |
| uvos | looks like for a 1750mA battery that thus contains about 400J of energy | 13:36 |
| buZz | its ~170000 on disconnected, ~130000 on gprs connected, ~180000 on wifi connected | 13:36 |
| uvos | the change would be about 1*10^-12 g | 13:37 |
| buZz | so weird to see whole device use less on gprs connected vs nothing active | 13:37 |
| uvos | thats more than i expeced | 13:37 |
| buZz | i guess thats the same as the 'no sim card makes modem use more power' ? | 13:37 |
| buZz | uvos: with screen active, btw | 13:37 |
| uvos | yeah no idea whats up with modem power consumption | 13:39 |
| uvos | its really wierd | 13:39 |
| 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 | 13:50 |
| freemangordon | uvos: the difference would be ~1.8*10^-14 | 13:51 |
| freemangordon | ((2.25-1.75)*3600)/(10^-17) | 13:52 |
| Wizzup | sicelo: I thought I made photos before, but I can make them again | 13:53 |
| uvos | freemangordon: hmm for the exact value i get 2.59*10^-13 | 14:00 |
| uvos | battery has 6.475Wh of engery, 6.475Wh*3600 = 23310 Joules | 14:01 |
| freemangordon | thats not the difference between 2250 and 1750 charge | 14:02 |
| uvos | m = E/c^2 = (23310) Jouls / (300*10^6 m/s) = 2.59*10^-13 kg | 14:02 |
| uvos | freemangordon: right i was going empty -> full | 14:02 |
| uvos | gocha | 14:02 |
| uvos | still first value was wrong because i converted wh - > joule wrong | 14:03 |
| uvos | ok yes our values agree :P | 14:03 |
| freemangordon | :) | 14:03 |
| Wizzup | freemangordon: if you have a moment, can you look at mafw-shared build fail? I can't quite figure it out | 14:07 |
| Wizzup | it's not urgent | 14:07 |
| uvos | probubly more urgent can caluclateing the change in mass of a battery based on special relativity | 14:08 |
| uvos | *than | 14:08 |
| uvos | freemangordon: Wizzup: https://github.com/maemo-leste/hildon-desktop/pull/22 | 14:45 |
| uvos | https://github.com/maemo-leste/hildon-desktop/pull/21 | 14:45 |
| Wizzup | how will it know the initial state? | 14:47 |
| uvos | hmm it reads it from dbus when h-d starts | 14:48 |
| uvos | the value comes from the same place (mce) just the interface is different | 14:48 |
| uvos | mce btw dose not know the initall state either | 14:49 |
| Wizzup | oh, so you can poll/ask? | 14:49 |
| uvos | yeah, this patch is really i old | 14:49 |
| uvos | i have to read it if i forgot to poll | 14:49 |
| uvos | sec | 14:49 |
| uvos | Wizzup: yeah it polls on startup | 14:50 |
| uvos | see hd_app_mgr_init | 14:50 |
| uvos | not that mce knows the slide state on startup either | 14:50 |
| Wizzup | btw, something unrelated... | 14:50 |
| uvos | but thats a different issue | 14:50 |
| Wizzup | it looks like we'll have to use elogind somehow, we can run X as user instead of root | 14:51 |
| uvos | mce will just send closed even when it just dosent know just after boot | 14:51 |
| Wizzup | but I am not sure if we can integrate it from an init script in whatever session logic elogind forces down us | 14:51 |
| Wizzup | s/down/upon/ | 14:51 |
| Wizzup | even on my own laptop I must type startx from a video tty | 14:52 |
| Wizzup | otherwise it doesn't work | 14:52 |
| Wizzup | sadness | 14:52 |
| uvos | Wizzup: we should just use a session manager | 14:53 |
| Wizzup | if it's invisible that would be great | 14:53 |
| Wizzup | i.e. not there :P | 14:53 |
| uvos | theres nodm but its nolonger maintained, theres also a small thing pmos uses | 14:54 |
| uvos | that essentaly dose this | 14:54 |
| uvos | sec leemy try and find it | 14:54 |
| uvos | https://gitlab.com/postmarketOS/tinydm | 14:55 |
| Wizzup | I guess we probably want this then instead of our /etc/init.d/xorg | 14:56 |
| uvos | yes | 14:56 |
| uvos | also finally xD | 14:56 |
| uvos | (this also allows you to run some other session isntead, like hint hint lxqt when using a lapdock) | 14:57 |
| uvos | :P | 14:57 |
| Wizzup | I don't think so, if it runs as an init script and just runs our own thing, no? | 14:57 |
| uvos | no it runs the default xdg session | 14:58 |
| uvos | you need to make a xdg session file for hildon | 14:58 |
| Wizzup | don't we have /etc/X11/Xession | 14:58 |
| Wizzup | Xsession* | 14:58 |
| uvos | well xsession is old crap, no offense, what we want is a dir with the scripts currently in xsession | 14:58 |
| uvos | and a xdg session that runs those scripts | 14:59 |
| uvos | i have even done this before | 15:00 |
| uvos | in a vm | 15:00 |
| uvos | let me look for it | 15:00 |
| Wizzup | we use xsession.d | 15:01 |
| uvos | yeah i know | 15:01 |
| uvos | but thats not how xdg session works | 15:01 |
| Wizzup | well we have a dir with scripts is what I mean | 15:01 |
| uvos | i know | 15:02 |
| uvos | so a xdg session is just a .desktop file that has a key that tells the dm if its x11 or wayland, and a Exec= parameter | 15:02 |
| uvos | the dm then starts x11 if needed and executes exec | 15:02 |
| uvos | exec then shal be a utility (in our case) that runs the scripts in some .d | 15:02 |
| uvos | sutch a utility (to run a .d of scripts) exists | 15:03 |
| uvos | im just forgeting what its called | 15:03 |
| Wizzup | run-scripts ? | 15:03 |
| Wizzup | I guess that is probably cron related | 15:03 |
| Wizzup | this is going to be a nightmare | 15:03 |
| SuperMarioSF | oh i'm back | 15:03 |
| uvos | not sure why you think so | 15:03 |
| SuperMarioSF | btw the second phone should arrive tomorrow | 15:04 |
| uvos | Wizzup: found the vm that works like this | 15:07 |
| Wizzup | uvos: which vm is this, a maemo one you made? | 15:08 |
| Wizzup | SuperMarioSF: great | 15:08 |
| uvos | Wizzup: yeah | 15:08 |
| Wizzup | ok | 15:08 |
| Wizzup | well, maybe I can hand this off to you then :D | 15:08 |
| Wizzup | uvos: I'll just continue building some stuff, right now our xorg-server doesn't build with (e)logind support | 15:15 |
| Wizzup | but nothing blocks it (elogind) other than hildon-base | 15:15 |
| uvos | Wizzup: ok | 15:16 |
| uvos | ill get you the scripts from the vm | 15:16 |
| Wizzup | is this with tinydm? | 15:16 |
| uvos | yes | 15:16 |
| uvos | its the setup as described before | 15:16 |
| uvos | besides installing tinydm and creating a hildon xdg session file and a hildon-session script | 15:17 |
| uvos | it just moved the scripts from xsession.d somewhere else, this is ofc quite some work to do properly | 15:17 |
| uvos | as we will have to move them in eatch packager | 15:17 |
| Wizzup | or make a symlink from the dir | 15:17 |
| uvos | not really a solution as other desktops will run the scripts in xsession.d expecting them to contain just desktop independant stuff | 15:18 |
| uvos | we must remove our agresseively hildon centric scripts from there if we intened to be a well behaved xdg-session | 15:19 |
| uvos | also af-services breaks everyhting | 15:19 |
| uvos | but thats a different story | 15:19 |
| Wizzup | well, we don't run other desktops though | 15:19 |
| uvos | weill if we want or stuff to ever be acceptable packaged in another distro we need to be well behaved | 15:20 |
| uvos | also the lapdocks are a good reason for a different session | 15:20 |
| uvos | imo | 15:20 |
| Wizzup | I find it hard to wrap my head around this, but I suppose eventually it could be a good thing | 15:21 |
| Wizzup | I'd be a little annoyed if we'd have to do all of that just for us to 'finish' the chimaera port | 15:21 |
| uvos | seams like a good time to at least introduce the veneer of a xdg-session | 15:22 |
| uvos | there are ofc still lots of issues to this | 15:22 |
| Wizzup | I mean, it sounds like we're forced ot :P | 15:22 |
| buZz | i do still want to try xnest on droid4 | 15:22 |
| Wizzup | to* | 15:22 |
| uvos | af-services being one, the force of the user user being another | 15:22 |
| buZz | so maybe i could run a wm with two xnest inside, one with hildon for lcd, one with hildon for hdmi | 15:22 |
| buZz | it seems easier then getting hildon to understand >1 display ;P | 15:22 |
| Wizzup | that does not make any sense, you can just run another X on the other display | 15:23 |
| Wizzup | or restrict the vm to one display | 15:23 |
| uvos | buZz: sure this would enable you to use multiseat | 15:23 |
| uvos | to do wat you want | 15:23 |
| buZz | Wizzup: but you couldnt move mouse back&forth then | 15:23 |
| Wizzup | buZz: yes you can afaik | 15:23 |
| uvos | buZz: zaphodhead is a thing | 15:23 |
| buZz | over two xservers? not without something like barrier or x2x | 15:23 |
| uvos | buZz: zaphod head is 2 DISPLAY | 15:23 |
| uvos | on one xserver | 15:23 |
| buZz | ah, havent heard of | 15:24 |
| uvos | this is exactly what you want | 15:24 |
| Wizzup | in any case | 15:24 |
| Wizzup | let's not derail for a moment please | 15:24 |
| buZz | ok :) | 15:24 |
| Wizzup | uvos: so the way I see it, I will just build all the pkgs now | 15:24 |
| Wizzup | and then we can get them all installed, and then figure out how to move the scripts over and rebuild packages as necessary | 15:25 |
| uvos | Wizzup: ok sounds good | 15:25 |
| uvos | ill write something detailing setup in vm later | 15:25 |
| Wizzup | ok, cool | 15:25 |
| Wizzup | I'm considering trying to move to pipewire still for chimaera move though | 15:25 |
| buZz | that would be cool | 15:26 |
| uvos | sphone works with pw on my arch desktop | 15:26 |
| buZz | pipewire can emulate pulse and alsa etc, should be near transparant | 15:27 |
| uvos | but i would be weary about changes in how it translates ucm to its streams affecting pw on devices | 15:27 |
| uvos | but its something to just try | 15:27 |
| uvos | everything besides sphone should not care at all really | 15:27 |
| Wizzup | well I just want to get rid of pa asap really | 15:29 |
| Wizzup | since I started using pipewire everything got better on my desktop | 15:29 |
| uvos | is poettering chaseing you in your nightmares? | 15:30 |
| uvos | :P | 15:30 |
| uvos | but i agree on the surface pw seams better | 15:30 |
| Wizzup | the noise and echo cancelling is also much better | 15:30 |
| uvos | pa was allways a bit of a mess... | 15:31 |
| Wizzup | easyeffects is also nice | 15:31 |
| tmlind | uvos: yeah ok so minimal xt910 dts boots, no backlight yet though | 15:41 |
| tmlind | looking at if the usb qmi is also available | 15:41 |
| Wizzup | tmlind: sweet :) | 15:42 |
| BlagovestPetrov[ | wow, a lot of progress :) | 15:43 |
| tmlind | well most of the hard work was done already by a bunch of people years ago :) | 15:46 |
| uvos | tmlind: right yes, | 15:47 |
| uvos | to be fair a not insignifcant chunck of the work years ago was also tmlind ;) | 15:48 |
| Wizzup | tmlind: ftr I copied some of your updates here https://github.com/maemo-leste/bugtracker/issues/648 | 15:50 |
| tmlind | ok | 15:50 |
| tmlind | yeah so no usb qmi interface with lsusb, just the usb uart interfaces | 15:50 |
| Wizzup | right, this was the device with modem on spi? | 15:51 |
| tmlind | yup.. i doubt that we can change the modem configuration if it's using signed firmware | 15:53 |
| tmlind | /dev/gnss0 produces some data though, so seems it's the same otherwise | 15:53 |
| uvos | it might, just might be using the same keys as xt912 | 15:54 |
| uvos | mz609 and 607 use the same keys after all | 15:54 |
| tmlind | hmm yeah | 15:54 |
| tmlind | i'll give that a try at some point | 15:55 |
| tmlind | i'll do a minimal git branch with dts files for mz609, mz617 and xt910 first | 15:59 |
| freemangordon | uvos: I don't know what pave did, but this https://github.com/pavelmachek/libbattery/blob/master/libbattery.c#L95 is not the same as this https://www.candlepowerforums.com/threads/li-ion-state-of-charge-and-voltage-measurements.115871/#post-2440571 | 16:03 |
| freemangordon | hmm, actually it is | 16:08 |
| uvos | besides the linear aproximation | 16:09 |
| freemangordon | yeah, linear approximation is totally off | 16:10 |
| freemangordon | it says 50%, but algo is from 30 % | 16:10 |
| uvos | linear approximation form 50% also dosent jive with a lipo discarge curve at all | 16:10 |
| uvos | since its the least linear its ever going to get around 30% | 16:11 |
| uvos | or maybe closer to 20 | 16:11 |
| 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 :) | 16:11 |
| buZz | havent checked if this happens with a 4.349v-charging-to-4.2v too | 16:12 |
| freemangordon | it is upower, not status menu applet | 16:18 |
| freemangordon | uvos: ugh, actually formula gives 21 % for 3757 | 16:21 |
| freemangordon | so linear shall start @ 20, not @ 50 | 16:21 |
| uvos | freemangordon: ok yeah i see | 16:22 |
| uvos | freemangordon: but im not sure why you care about the formula at all at this point | 16:22 |
| uvos | freemangordon: would using kernel fw tables not be better anyhow | 16:22 |
| uvos | freemangordon: since it works with upstream upower | 16:22 |
| uvos | or is this to generate a fallback table if the battery is unkown? | 16:23 |
| freemangordon | as a stopgap patch in upower | 16:23 |
| freemangordon | yes, for fallback table too | 16:23 |
| freemangordon | uvos: also, isn't 3.3 too low for 0%? | 16:26 |
| freemangordon | ok, that's better: | 16:27 |
| freemangordon | calculated 13 reported 10 | 16:27 |
| uvos | freemangordon: no 3.3 is fine | 16:31 |
| uvos | this is open circut voltage | 16:31 |
| freemangordon | ah, right | 16:31 |
| freemangordon | hmm, calculations show 15 %, driver reports 7 %, lets see who is right :) | 16:34 |
| uvos | well mce also shutsdown early on purpose so im not sure how your going to get "ground truth" really | 16:35 |
| uvos | in the single diget % range | 16:36 |
| freemangordon | I will stop mce :) | 16:36 |
| uvos | still the signal that the kernel acts upon is also quite nosy | 16:36 |
| uvos | so not sure thats any better | 16:36 |
| uvos | but it is hopefully close enough | 16:36 |
| uvos | the real test here is to use Wizzup's fancy imaxb6 to charge to specific soc | 16:37 |
| uvos | and then then test that against algo :P | 16:37 |
| freemangordon | yeah | 16:37 |
| freemangordon | ok, this is the first time I hear " recharge battery" sound :) | 16:39 |
| freemangordon | uvos: ok, but if we shut down @ 3350, shouldn't that be our 0% point? | 16:40 |
| freemangordon | btw, I think calculated value is more correct | 16:41 |
| freemangordon | as now calibrated shows 3% @ 3566mV | 16:41 |
| uvos | freemangordon: sure but thats a mapphone quirk | 16:42 |
| freemangordon | right | 16:42 |
| Wizzup | uvos: damn sounds like I should have send one to you | 16:53 |
| uvos | Wizzup: i have one ;) | 16:54 |
| Wizzup | sounds like you do the test then? | 16:54 |
| Wizzup | you can* | 16:55 |
| uvos | i can, but seriously tedious mesurements are best left to someone else xD | 16:55 |
| uvos | anyhow, i can do it :) | 16:55 |
| Wizzup | I haven't been able to use the device yet, won't be for a while, so better if you do | 16:59 |
| Wizzup | btw, with mpd and mpris-proxy I can control mpd from my headphone by swiping on the right ear (feature), kinda cool | 17:00 |
| uvos | Wizzup: ok | 17:00 |
| uvos | Wizzup: that is cool | 17:00 |
| uvos | Wizzup: bluetooth integration would be neat | 17:00 |
| Wizzup | yup, later though | 17:08 |
| Wizzup | I think it's best to do chimaera first | 17:12 |
| Wizzup | it's just too annoying to maintain both chimaera and beowulf | 17:13 |
| uvos | yeah wasent a now thing, just museing | 17:27 |
| 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 | 17:27 |
| sicelo | unless there are specific issues that force/require such change to happen asap | 17:28 |
| Wizzup | tmlind: I will send two xt912 since I am not sure if they both work | 17:35 |
| Wizzup | i mean they start :) | 17:36 |
| tmlind | ok cool | 17:50 |
| freemangordon | uvos: calculated 10 reported 0 | 18:35 |
| freemangordon | that was maybe half an hour ago | 18:36 |
| freemangordon | now it is 'calculated 4 reported 0' | 18:36 |
| freemangordon | so calculated seems to be more correct :) | 18:36 |
| uvos | uh whats calculated here | 18:36 |
| uvos | estimation? | 18:37 |
| freemangordon | yes | 18:37 |
| uvos | ok | 18:37 |
| SuperMarioSF | maybe reported value is attempting to preserve more power for something else? | 18:37 |
| uvos | great | 18:37 |
| uvos | no | 18:37 |
| freemangordon | wrong calibration | 18:37 |
| uvos | its just that the low irq is noisy | 18:37 |
| uvos | so it callibrates somewhat wrong | 18:37 |
| SuperMarioSF | btw my new battery was calibrated but seems wrong, had almost 100mAh less capacity. | 18:38 |
| uvos | freemangordon: maybe pr charge-mode :P | 18:38 |
| freemangordon | yeah | 18:38 |
| freemangordon | will do | 18:38 |
| SuperMarioSF | but more durable than before. | 18:38 |
| SuperMarioSF | strange | 18:38 |
| freemangordon | uvos: so, shut down happened @ 4% estimated | 18:40 |
| freemangordon | this is 3350mV | 18:41 |
| uvos | i mean that sounds about right | 18:41 |
| freemangordon | so, about right | 18:41 |
| freemangordon | mhm | 18:41 |
| uvos | @4% reserved by mce | 18:41 |
| freemangordon | yeah | 18:41 |
| SuperMarioSF | seems right | 18:41 |
| SuperMarioSF | my phone also shut down at 4% (reported from android side) | 18:42 |
| freemangordon | uvos: I don't think charge-mode bug is fixed | 18:43 |
| uvos | i mean a bug is def fixed | 18:44 |
| freemangordon | did you push to repo? | 18:44 |
| uvos | let me check | 18:45 |
| freemangordon | I mean - did you rebuild? | 18:45 |
| freemangordon | bbiab | 18:45 |
| uvos | sure 1.2.6 | 18:46 |
| uvos | its in the repo | 18:47 |
| freemangordon | oh, what level it waits for? | 18:58 |
| freemangordon | 10%? | 18:58 |
| freemangordon | uvos: I think it shall animate something | 18:59 |
| freemangordon | to show that it is charging | 18:59 |
| uvos | we could blink the lighting bolt if you like | 18:59 |
| freemangordon | yes, please | 19:00 |
| uvos | if((ev.key.keysym.sym == SDLK_POWER || ev.key.keysym.sym == 1073741824) && bat_info.percent > 10) | 19:00 |
| uvos | yes 10% | 19:00 |
| uvos | i gues idealy it would blink a ! over the battery | 19:00 |
| uvos | if the user clicks power | 19:00 |
| uvos | but it thinks battery is to low | 19:01 |
| uvos | also 10% is maybe a bit harsh | 19:01 |
| freemangordon | yes, that's too high | 19:02 |
| freemangordon | but, don;t change it now, I think once charger detetion is in place we shall rethink the whole concept | 19:03 |
| Wizzup | btw I got the same problem on 6.1 with the constant oopses | 19:04 |
| Wizzup | /var/log/messages became 2G in a matter of minutes | 19:04 |
| uvos | what oopses | 19:04 |
| uvos | i have nothing to see in there | 19:05 |
| Wizzup | https://dpaste.com/GGF3DLNSN.txt | 19:05 |
| Wizzup | when modem drops off | 19:05 |
| uvos | ah ok | 19:05 |
| uvos | yeah that never happens here | 19:05 |
| Wizzup | I think it might happen shortly after I unload bluetooth | 19:05 |
| Wizzup | do you unload the bluetooth module with rmmod ever? | 19:05 |
| uvos | i do that all the time | 19:05 |
| Wizzup | https://wizzup.org/modem-oops.txt | 19:07 |
| Wizzup | looks like it happened before module unload even | 19:08 |
| Wizzup | just while I was walking | 19:08 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/645 | 19:09 |
| Wizzup | (and this repeats forever) | 19:10 |
| Wizzup | surprisingly the system is still usable | 19:10 |
| Wizzup | just... slow and runs warm | 19:10 |
| uvos | mce now knows the slide state on boot :) | 19:30 |
| uvos | i know im fixing serious issues :P | 19:30 |
| freemangordon | heh | 19:31 |
| uvos | turns out theres a ioctl you can use to get the swich state of a evdev device | 19:32 |
| tmlind | Wizzup: that's weird, it's like the modem shuts down and phy-cpcap-usb driver does not see anything with the gpio pins? | 19:32 |
| uvos | EVIOCGSW | 19:32 |
| Wizzup | tmlind: right, I think this is what you commented on before as well here: https://github.com/maemo-leste/bugtracker/issues/645 | 19:34 |
| Wizzup | freemangordon: I am going to add this to rtcom-eventlogger tests/Makefile.am: | 19:34 |
| Wizzup | -rtcom_eventlogger_testsuite_CFLAGS = $(CHECK_FLAGS) | 19:34 |
| Wizzup | +rtcom_eventlogger_testsuite_CFLAGS = $(CHECK_FLAGS) -Wno-error=format-extra-args -Wno-error=format | 19:34 |
| Wizzup | it's been driving me nuts for 30 minutes | 19:34 |
| uvos | ugh those are usualy pretty usefull to be errors | 19:35 |
| uvos | and i dont even like -werror | 19:35 |
| freemangordon | Wizzup: what is the issue? | 19:36 |
| Wizzup | freemangordon: all the falls to check.h fail macros fail with too many arguments | 19:37 |
| Wizzup | for format | 19:37 |
| Wizzup | where that doesn't seem to be the case | 19:37 |
| Wizzup | even stuff like fail("error") doesn't work anymore | 19:37 |
| Wizzup | https://phoenix.maemo.org/job/rtcom-eventlogger-binaries/architecture=amd64,label=amd64/8/consoleText | 19:37 |
| Wizzup | check_el.c: In function 'test_add_event_fn': | 19:38 |
| Wizzup | check_el.c:196:14: error: too many arguments for format [-Werror=format-extra-args] | 19:38 |
| Wizzup | 196 | fail("Failed to create event."); | 19:38 |
| Wizzup | | ^~~~~~~~~~~~~~~~~~~~~~~~~ | 19:38 |
| freemangordon | weird | 19:38 |
| freemangordon | cannot look at it RN | 19:39 |
| Wizzup | I can also stop for today with chimaera stuff, but I threw away half an hour already | 19:39 |
| Wizzup | there's about 80 errors like this | 19:39 |
| uvos | new infra is seriously fast at building mce | 19:40 |
| uvos | i gues it was a rpi before so no suprise . still | 19:40 |
| Wizzup | most of the time in almost all the builds is the whole cow stuff | 19:40 |
| uvos | yeah | 19:40 |
| Wizzup | it's also faster than amd64 but only because amd64 is not on ssd atm | 19:41 |
| uvos | ok | 19:41 |
| uvos | anyhow its just about as fast as a local build on d4 | 19:41 |
| uvos | thats pretty good | 19:41 |
| Wizzup | should be much faster really | 19:41 |
| uvos | well it has to do mutch more | 19:41 |
| Wizzup | keep in mind it does a lot of pkg fetching and dpkg action | 19:41 |
| Wizzup | yeah | 19:41 |
| freemangordon | uvos: is it normal that soc prediction is very inaccurate on charging? | 19:42 |
| uvos | no | 19:42 |
| uvos | should be the same really if ri is correct | 19:43 |
| uvos | except at very high charge rates > 1c | 19:43 |
| uvos | there is increasing non liniarity | 19:43 |
| freemangordon | 1c is? 1200 mA? | 19:43 |
| uvos | for you 1c is 2.2A | 19:43 |
| freemangordon | oh | 19:44 |
| freemangordon | well, it charges @ ~1A | 19:44 |
| uvos | right | 19:44 |
| freemangordon | Calculated r = 0.080460, Ri = 0.089695 for Imax=-1215mA@4009mV, Imin=-1302@4016mV | 19:44 |
| freemangordon | calculated 63 reported 39 | 19:44 |
| uvos | so open circut voltage estimation via Ri should hold for the most part | 19:44 |
| uvos | in this case | 19:44 |
| freemangordon | unless the math for calculating Ri when charging is different | 19:45 |
| uvos | not really | 19:45 |
| uvos | sign of I changes | 19:45 |
| freemangordon | right | 19:45 |
| freemangordon | and that's good as we have to subtract anyways | 19:46 |
| uvos | maybe calculating Ri is less accurate because relatvie difference in I is less | 19:46 |
| uvos | so if you retain the last discharging Ri | 19:46 |
| uvos | how goes the estimation? | 19:46 |
| freemangordon | can't parse | 19:47 |
| uvos | while charging | 19:47 |
| uvos | I dosent change that mutch (in a relative sense) | 19:47 |
| uvos | possibly increasing the error in Ri | 19:47 |
| uvos | so if you just use the last Ri from when you where discharging | 19:47 |
| uvos | dose soc estimation remain poor? | 19:47 |
| freemangordon | Calculated r = 0.108153, Ri = 0.105595 for Imax=-701mA@3967mV, Imin=-1302@4032mV | 19:47 |
| freemangordon | calculated 61 reported 43 | 19:47 |
| freemangordon | this is big wnough difference | 19:48 |
| freemangordon | *enough | 19:48 |
| uvos | yeah | 19:48 |
| freemangordon | so Ri calculation should be correct | 19:48 |
| freemangordon | there is something else going on here | 19:48 |
| uvos | also thats a closer Ri to ususal discharing state no | 19:48 |
| uvos | ? | 19:48 |
| freemangordon | yes | 19:48 |
| freemangordon | maybe reported voltage is incorrect | 19:49 |
| uvos | hmm at least i dont see why that would be | 19:50 |
| freemangordon | but looks like it is | 19:50 |
| freemangordon | because this is too high voltage for 40% SOC, no? | 19:51 |
| uvos | i mean a bit | 19:52 |
| uvos | its suggesting open circut voltage is 3.87 | 19:52 |
| uvos | maybe 3.8 allowing for some error in Ri | 19:53 |
| uvos | also non linierty | 19:53 |
| uvos | of Ri | 19:53 |
| freemangordon | hmm, I stopped charging but it still gives bogus results | 19:53 |
| uvos | Ri increases with current | 19:53 |
| freemangordon | yep, reported voltage is deffinitely wrong | 19:55 |
| uvos | (at high currents reactants close to the electrode get depleted and you end up more diffusion limited) | 19:55 |
| uvos | freemangordon: ok | 19:55 |
| uvos | wierd for sure | 19:56 |
| freemangordon | even with current limit set to 0 I see voltages > 4.0 | 19:56 |
| freemangordon | with charger disconnected voltage drops to 3.8 | 19:56 |
| uvos | hmm | 19:56 |
| uvos | can you mesure at the terminals with a dmm? | 19:56 |
| uvos | or sec let me do it | 19:56 |
| freemangordon | not now | 19:57 |
| uvos | ill do it | 19:57 |
| freemangordon | thanks | 19:57 |
| uvos | ok | 19:58 |
| uvos | no charger 3.80V 128.3 mA) | 19:59 |
| uvos | dmm reports 3.82V | 19:59 |
| uvos | charger plugged in, echo 0 > /sys/class/power_supply/usb/input_current_limit | 20:00 |
| uvos | 3.91V -491mA | 20:00 |
| freemangordon | mhm | 20:01 |
| uvos | huh wait | 20:01 |
| uvos | ok thats a bug setting input_current_limit to zero has no efect untill i replug usb | 20:01 |
| uvos | anyhow carring on | 20:01 |
| uvos | with usb replugged and input_current_limit 0 | 20:02 |
| freemangordon | well, I hit that bug it seems | 20:02 |
| uvos | 3.82V and 123mA | 20:02 |
| uvos | dmm agrees | 20:02 |
| freemangordon | but, what if you set input current limit to 1800? | 20:03 |
| uvos | what units is input_current_limit in again | 20:03 |
| freemangordon | uA | 20:03 |
| freemangordon | 1800000 | 20:03 |
| uvos | 4.1V 1395mA | 20:03 |
| uvos | dmm agrees | 20:04 |
| freemangordon | ok | 20:04 |
| freemangordon | then something wrong with math it seems | 20:04 |
| uvos | or non liniarity of Ri is greater than i would expect | 20:04 |
| freemangordon | but I calculate it before use it | 20:05 |
| uvos | not sure what you mean | 20:05 |
| 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 | 20:05 |
| uvos | because the battery becomes increasingly diffusion limited | 20:06 |
| uvos | this effect isent huge mind you, at resonable currents ie <1c | 20:06 |
| freemangordon | I recalculate Ri every 30 seconds | 20:06 |
| uvos | but maybe greater than i think | 20:06 |
| freemangordon | based on 10 samples made just before recalculation | 20:07 |
| uvos | sure but if your calculating Ri at around 1A and then applying it for all of those 1A its wrong | 20:07 |
| uvos | you would have to calculate Ri for the first 500mA and then compensate that for ocv | 20:07 |
| uvos | and then calculate again for the last 500mA | 20:07 |
| uvos | and compensate those 500mA with the latter Ri | 20:08 |
| uvos | or so | 20:08 |
| freemangordon | I don't get that | 20:08 |
| uvos | (idealy you would integrate ofc) | 20:08 |
| uvos | ok so it works like this | 20:08 |
| freemangordon | wait a sec | 20:08 |
| freemangordon | i calculate Ri for current ~ 1200 mA | 20:08 |
| freemangordon | and then use that Ri to calculate open circuit voltage for current ~ 1200 mA | 20:09 |
| freemangordon | so I don;t see where the error is | 20:09 |
| freemangordon | so, please explain | 20:10 |
| 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). | 20:10 |
| freemangordon | ok | 20:10 |
| 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 | 20:10 |
| uvos | effectively the Ri for those last 500mA is greater than for the first | 20:11 |
| freemangordon | ok | 20:11 |
| uvos | but this effect should be small | 20:11 |
| uvos | at small currents | 20:11 |
| uvos | there the battery should be effectively linear | 20:11 |
| buZz | uvos: on ideal batterues its small | 20:11 |
| buZz | on old ones less so | 20:11 |
| freemangordon | but, this is not what happens here, as I calculate for currents ~1200mA | 20:12 |
| buZz | 'pre wornout' cells | 20:12 |
| freemangordon | Calculated r = 0.102273, Ri = 0.089607 for Imax=-1092mA@4158mV, Imin=-1180@4167mV | 20:12 |
| freemangordon | 1092 vs 1180 | 20:12 |
| uvos | freemangordon: right but then you apply the Ri you got at ~1200mA to all of those ~1200mA | 20:12 |
| uvos | to get ocv | 20:12 |
| uvos | thats the problem | 20:12 |
| 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 | 20:13 |
| uvos | so the result is somewhat wrong | 20:13 |
| freemangordon | actually it seems that Ri decreases with the current | 20:15 |
| freemangordon | at least on discharge | 20:15 |
| Wizzup | freemangordon: I will make an issue for the rtcom-eventlogger warnings, ok? | 20:16 |
| freemangordon | ok | 20:16 |
| freemangordon | will look at it tomorrow | 20:16 |
| Wizzup | meanwhile I will build it | 20:17 |
| freemangordon | ok | 20:17 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/674 | 20:19 |
| uvos | freemangordon: ok im looking at some papers here | 20:41 |
| uvos | freemangordon: yes i know rabbit hole | 20:41 |
| uvos | freemangordon: and it looks like indeed Ri dose decreese slightly from zero to small currents and then increase at very large currents | 20:43 |
| uvos | increase greatly (compeard to the small decreese) | 20:43 |
| uvos | anyhow dont think we are seeing this tbh | 20:43 |
| uvos | also perhaps unsuprisingly Ri is lower when current rises rapidly | 20:45 |
| uvos | (ie there is some timeconstant in Ri too) | 20:45 |
| uvos | https://uvos.xyz/maserati/equivalentCircut.png | 20:47 |
| uvos | might be part of the cause of Ri bouncing around | 20:48 |
| uvos | but should not be for the problem of charging soc being different | 20:48 |
| freemangordon | right | 20:53 |
| freemangordon | I don't think that capacity plays any role here as current is relatively constant | 20:54 |
| Wizzup | next time I should write a python script that parses debian/control and suggests a build order for the pkgs | 21:05 |
| freemangordon | uvos: I think we have another issue, in the charger | 21:05 |
| freemangordon | it seems it charges till 4.2 is hit, but this is not 4.2 OCV | 21:06 |
| freemangordon | it charges to something like 4.189 | 21:06 |
| freemangordon | or even less | 21:07 |
| uvos | so according to the datasheet of cpcap | 21:25 |
| 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 | 21:27 |
| uvos | so yes it is expected that ocv never reaches 4.2V but 4.2V - whatever is deltaV at 50mA | 21:28 |
| Wizzup | freemangordon: should I rebase patches for eds? | 21:28 |
| Wizzup | I'm trying to build osso-abook but it's involving :D | 21:28 |
| freemangordon | yes, please | 21:28 |
| uvos | so if Ri is 150mOhm (like i mesured it here by hand) | 21:29 |
| uvos | then you would expect ocv voltage after charging ends to be 4.1925V | 21:29 |
| uvos | so close enough really | 21:30 |
| freemangordon | ok | 21:32 |
| BlagovestPetrov[ | hah, xorg conf is broken and the VM restarts on boot | 21:58 |
| uvos | dsme? | 21:59 |
| Wizzup | freemangordon: why do we keep using quilt for patches instead of just git :( | 23:06 |
| Wizzup | ok, abook built | 23:17 |
| Wizzup | (locally) | 23:17 |
| Wizzup | uvos: we still use hildon-desktop-rotation-support - right? | 23:26 |
| uvos | Wizzup: nope i integrated that into h-d a long time ago | 23:42 |
| Wizzup | ok, I think the pkg is still installed on my device at least | 23:43 |
| uvos | thats just your device | 23:43 |
| uvos | i remember removeing it from the metapacakge | 23:43 |
| Wizzup | yup | 23:44 |
| Wizzup | ok | 23:44 |
| Wizzup | might be better for the meta package to conflict on it | 23:44 |
| uvos | its obsoleted by https://github.com/maemo-leste/hildon-desktop/commit/5d66fef2ca603015f6cfeb7dd6008d15d4b3e8f6 | 23:44 |
| Wizzup | yeah that is what I remembered | 23:44 |
| uvos | heh looks like i fixed our oldest bug | 23:45 |
| Wizzup | oh yeah? :D | 23:46 |
| uvos | yes https://github.com/maemo-leste/bugtracker/issues/23 | 23:46 |
| uvos | Oct 24, 2017 lol | 23:46 |
| Wizzup | in about a year we'll have been at it for 5 years :) | 23:46 |
| uvos | if the date on that bug is an indication it has been 5 years allread | 23:47 |
| uvos | y | 23:47 |
| Wizzup | oh | 23:49 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/1 18 oct | 23:49 |
| Wizzup | hum | 23:49 |
| uvos | no idea how that happend | 23:50 |
| Wizzup | hm? | 23:50 |
| uvos | date mixup nvm | 23:50 |
| Wizzup | :D | 23:50 |
| uvos | anyhow zzzz | 23:51 |
| Wizzup | gn | 23:52 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
