Open rinigus opened 7 years ago
Chargemon shows positive 'Time until full'
Can you elaborate with more details, where you fetch those proplematic values?
Sure. The battery data in SFOS is available at /run/state/namespaces/Battery/
if you use stateFS interface. The code that is used to monitor battery on collectd side is at
https://github.com/rinigus/collectd/blob/sailfish/src/battery_statefs.c
and stateFS provider at
If I plug the charger in, onyx SFOS starts reporting negative values at /run/state/namespaces/Battery/TimeUntilFull
. On Nexus 4 its positive, as, I presume, is expected. On the both devices, its zero when charger is not plugged. You could check the current value by cat
How Chargemon determines its time, I don't know. Maybe I should take a look... But, on SFOS side, I would expect to get positive time from that file. Should we ask around about values different ports get?
cheers,
rinigus
/ cool! I didn't realize that you are the author of chargemon / :)
OK, it looks that you are basically reading hardware-provided data directly, not via stateFS. As far as I understand, stateFS should make this for you ...
but then TimeUntilFull is read via D-Bus? If true then somehow the sign gets mixed up in stateFS.
no, not dbus. ContextProperty (afaik is statefs)
PKGCONFIG += contextkit-statefs
QScopedPointer<ContextProperty> propertyTimeUntilFull;
propertyTimeUntilFull.reset(new ContextProperty("Battery.TimeUntilFull", this));
Since collectd is mainly in C, we would prefer to read data from files, as its done now. Getting dependency on Qt or some other lib is not too simple and would probably majorly increase RAM footprint (RSS is below 5MB at present).
Any idea how could stateFS values went wrong? But its very interesting that ContextProperty reports positive values.
one could check, e.g. by adding qDebug() to chargemon, to print out the raw value from contextproperty. If Qt::Time or something there used for formatting just turns it positive? "hh:mm:ss" maybe omits the sign?
But this needs some tracking, where from the value actually comes from etcetc
I could check tonight with qDebug. I presume compilation is straightforward in SDK...
@kimmoli: an inspired call - the time to full as reported by conextproperty is negative during charging at
https://github.com/kimmoli/chargemon/blob/master/src/cmon.cpp#L338
So, as you suggested, the conversion to time makes it positive. So, the problem is still in underlying stateFS.
Then, need to dig deeper ...
digged down to here https://git.merproject.org/mer-core/statefs-providers/blob/master/src/power_udev/provider_power_udev.cpp tried to calculate manually where it gets negative, but lost what i was calculating... duh.
Not charging
POWER_SUPPLY_NAME=battery
POWER_SUPPLY_CHARGING_ENABLED=1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_CHARGE_TYPE=N/A
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4320000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=4400000
POWER_SUPPLY_VOLTAGE_NOW=3940146
POWER_SUPPLY_CAPACITY=69
POWER_SUPPLY_CURRENT_NOW=88089
POWER_SUPPLY_INPUT_CURRENT_MAX=100000
POWER_SUPPLY_INPUT_CURRENT_TRIM=25
POWER_SUPPLY_INPUT_CURRENT_SETTLED=0
POWER_SUPPLY_BYPASS_VCHG_LOOP_DEBOUNCER=0
POWER_SUPPLY_VOLTAGE_MIN=4400000
POWER_SUPPLY_INPUT_VOLTAGE_REGULATION=1
POWER_SUPPLY_CHARGE_FULL_DESIGN=2450000
POWER_SUPPLY_CHARGE_FULL=2514000
POWER_SUPPLY_TEMP=264
POWER_SUPPLY_TEMP_COOL=120
POWER_SUPPLY_TEMP_WARM=430
POWER_SUPPLY_TEMP_COLD=-30
POWER_SUPPLY_TEMP_OVERHEAT=530
POWER_SUPPLY_TEMP_LITTLE_COOL=220
POWER_SUPPLY_TEMP_LITTLE_COLD=0
POWER_SUPPLY_TEMP_STATUS=0
POWER_SUPPLY_SYSTEM_TEMP_LEVEL=0
POWER_SUPPLY_CYCLE_COUNT=7
POWER_SUPPLY_VOLTAGE_OCV=-22
POWER_SUPPLY_CHARGE_NOW=271960
POWER_SUPPLY_AUTHENTIC=0
POWER_SUPPLY_CHARGE_TIMEOUT=0
POWER_SUPPLY_CHARGE_DONE=0
POWER_SUPPLY_CHARGE_OVP=0
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=1500000
Charging
POWER_SUPPLY_NAME=battery
POWER_SUPPLY_CHARGING_ENABLED=1
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_CHARGE_TYPE=Fast
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4320000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=4400000
POWER_SUPPLY_VOLTAGE_NOW=4162867
POWER_SUPPLY_CAPACITY=68
POWER_SUPPLY_CURRENT_NOW=-1324880
POWER_SUPPLY_INPUT_CURRENT_MAX=1800000
POWER_SUPPLY_INPUT_CURRENT_TRIM=25
POWER_SUPPLY_INPUT_CURRENT_SETTLED=0
POWER_SUPPLY_BYPASS_VCHG_LOOP_DEBOUNCER=0
POWER_SUPPLY_VOLTAGE_MIN=4400000
POWER_SUPPLY_INPUT_VOLTAGE_REGULATION=0
POWER_SUPPLY_CHARGE_FULL_DESIGN=2450000
POWER_SUPPLY_CHARGE_FULL=2514000
POWER_SUPPLY_TEMP=259
POWER_SUPPLY_TEMP_COOL=120
POWER_SUPPLY_TEMP_WARM=430
POWER_SUPPLY_TEMP_COLD=-30
POWER_SUPPLY_TEMP_OVERHEAT=530
POWER_SUPPLY_TEMP_LITTLE_COOL=220
POWER_SUPPLY_TEMP_LITTLE_COLD=0
POWER_SUPPLY_TEMP_STATUS=0
POWER_SUPPLY_SYSTEM_TEMP_LEVEL=0
POWER_SUPPLY_CYCLE_COUNT=7
POWER_SUPPLY_VOLTAGE_OCV=-22
POWER_SUPPLY_CHARGE_NOW=4689720
POWER_SUPPLY_AUTHENTIC=0
POWER_SUPPLY_CHARGE_TIMEOUT=0
POWER_SUPPLY_CHARGE_DONE=0
POWER_SUPPLY_CHARGE_OVP=0
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=1500000
when charging POWER_SUPPLY_CHARGE_NOW=4689720 > POWER_SUPPLY_CHARGE_FULL=2514000
It looks to me that something is wrong with the battery stats interface provided by stateFS.
For some reason, time left till the battery is full is reported as a negative value. This is in contrast to Nexus 4 and the meaning of the stats: duration should be positive. While discharging, its zero, as it should. So, there is somewhere a sign error. As a result, the stats collecting programs would be in trouble. On a graphs below, when charging, the duration is negative and not displayed, for example.
When charged but still on USB charger, the battery energy jumps to 20Wh.
Other stats seem to be fine. See attached the graphs for problematic and an example graph (current) that is OK.