+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone Pro (https://forum.pine64.org/forumdisplay.php?fid=177)
+--- Forum: General Discussion of PinePhone Pro (https://forum.pine64.org/forumdisplay.php?fid=178)
+--- Thread: suggestions for power/battery consumption data logger for community to compare? (/showthread.php?tid=19577)
suggestions for power/battery consumption data logger for community to compare? - dchang0 - 12-22-2024
Hi, everyone!
biketool got me thinking about this: is there a LINUX utility that can do the following:
a) log battery level over time (datalogger functionality for graphing)
b) log which processes or hardware modules (especially the modem) are consuming what power, in milliwatts
c) show power-related settings, especially those that might alter the power consumption
The primary objectives are:
1) to allow the PINE64 community to objectively compare their own experiences for the purpose of sharing settings, tips, tricks, and diagnoses to maximize battery life. There are too many variables to consider when comparing battery life, such as screen brightness, modem clock speed, settings, usage patterns, cell signal strength. With a datalogger we could see, for instance, that someone who complains about awful battery life might have a specific setting that's set wrong, or that someone else with awful battery life has a process that keeps waking the phone up, or that someone with fantastic battery life runs their screen brightness at the dimmest setting all the time, etc.
2) to improve LINUX distros' power optimization for the PinePhone and PinePhone Pro over time
PowerTOP can do b) and c), but I don't think it can do a) without having a serial-attached external datalogger.
It's probable that PINE64 has some kind of internal tool that profiles power/battery consumption as they design their hardware. If that exists and we can use it, that would be great.
If not, which 3rd party open-source LINUX tools are closest to fulfilling the objectives?
I'll search online, but if anyone knows already what tools to use, please share here. Thanks!
RE: suggestions for power/battery consumption data logger for community to compare? - teekay - 12-31-2024
I'm new to PPP and am very interested in understanding the power usage of the device in order to optimize it. A simple way to log power usage is to run this in the console:
Code:
cat /sys/class/power_supply/rk818-battery/*_nowThis will show the current going in/out the battery in microamps (negative for discharging, positive for charging) and the battery millivolts. You can put that into a "while" loop with a "sleep" to periodically log this to a file. However, bear in mind that during logging, the CPU is awake and working, so you won't get a true representation of whats the idle power draw is.
I'm busy porting FreeBSD to the PPP (see https://codeberg.org/Honeyguide/freebsd-pinephonepro ) and wrote the driver for the battery charger, and was trying to figure out how the Linux driver works out the state-of-charge, because the rk818 chip doesn't seem to provide it.
My preliminary testing shows that perhaps the state-of-charge calculation in the Linux driver is not accurate, and it might be leaving usable battery capacity on the table (e.g. when it says 5% remaining, there may actually be quite a lot more actual capacity left). I'll spend some time checking if the the millivolts/microamps figures match actual battery measurements on my device, and whether the state-of-charge is indeed inaccurate. If it is, this might explain part of the battery woes that seem to afflict this device.
RE: suggestions for power/battery consumption data logger for community to compare? - teekay - 12-31-2024
I did some battery testing on my phone using the logging method above. Conditions:
- Pinephone Pro with Megi's U-boot bootloader and running PostmarketOS 24.12 Phosh
- Battery fully charged
- SIM card inserted and connected, WiFi enabled
I then used the phone for a bit and ran a YouTube video in Firefox at 360p. After starting the YouTube video, battery went from about 78% to 5% in about 30 minutes! I periodically manually logged the battery state and the output is below. From this output it looks like the battery capacity is under-reading when the phone is loaded (by YouTube playback in this instance) since the actual battery voltage isn't dropping anywhere near as fast as the stated capacity:
Code:
~ $ cat /sys/class/power_supply/rk818-batte
ry/*_now && cat /sys/class/power_supply/rk8
18-battery/capacity && date
-792000
3762000
78
Tue Dec 31 12:22:04 SAST 2024
~ $ cat /sys/class/power_supply/rk818-batte
ry/*_now && cat /sys/class/power_supply/rk8
18-battery/capacity && date
-933000
3679000
71
Tue Dec 31 12:28:31 SAST 2024
~ $ cat /sys/class/power_supply/rk818-batte
ry/*_now && cat /sys/class/power_supply/rk8
18-battery/capacity && date
-810000
3717000
62
Tue Dec 31 12:32:09 SAST 2024
~ $ cat /sys/class/power_supply/rk818-batte
ry/*_now && cat /sys/class/power_supply/rk8
18-battery/capacity && date
-801000
3678000
47
Tue Dec 31 12:37:50 SAST 2024
~ $ cat /sys/class/power_supply/rk818-batte
ry/*_now && cat /sys/class/power_supply/rk8
18-battery/capacity && date
-1313000
3548000
25
Tue Dec 31 12:43:54 SAST 2024
~ $ cat /sys/class/power_supply/rk818-batte
ry/*_now && cat /sys/class/power_supply/rk8
18-battery/capacity && date
-1138000
3616000
14
Tue Dec 31 12:47:24 SAST 2024
~ $ cat /sys/class/power_supply/rk818-batte
ry/*_now && cat /sys/class/power_supply/rk8
18-battery/capacity && date
-855000
3613000
5
Tue Dec 31 12:52:09 SAST 2024
~ $ cat /sys/class/power_supply/rk818-batte
ry/*_now && cat /sys/class/power_supply/rk8
18-battery/capacity && date
-834000
3552000
5
Tue Dec 31 12:52:29 SAST 2024I shut down the phone at 5%, let the battery rest for an hour, then tested the actual voltage on the battery: 3.82V, which equates to around 50% capacity! So while the phone thinks it's at 5%, in actual fact it's at 50%, which is a huge discrepancy. I left the phone off overnight (which seems to reset the battery meter), then plugged in the battery this morning, and the phone now shows 50% battery capacity, even though I didn't charge it!
TLDR; the phone's battery capacity meter is wonky so don't trust it, and we may actually be able to get a lot better battery life if this is fixed.
RE: suggestions for power/battery consumption data logger for community to compare? - biketool - 01-01-2025
(12-22-2024, 04:48 PM)dchang0 Wrote: Hi, everyone!
biketool got me thinking about this: is there a LINUX utility that can do the following:
a) log battery level over time (datalogger functionality for graphing)
b) log which processes or hardware modules (especially the modem) are consuming what power, in milliwatts
c) show power-related settings, especially those that might alter the power consumption
The primary objectives are:
1) to allow the PINE64 community to objectively compare their own experiences for the purpose of sharing settings, tips, tricks, and diagnoses to maximize battery life. There are too many variables to consider when comparing battery life, such as screen brightness, modem clock speed, settings, usage patterns, cell signal strength. With a datalogger we could see, for instance, that someone who complains about awful battery life might have a specific setting that's set wrong, or that someone else with awful battery life has a process that keeps waking the phone up, or that someone with fantastic battery life runs their screen brightness at the dimmest setting all the time, etc.
2) to improve LINUX distros' power optimization for the PinePhone and PinePhone Pro over time
PowerTOP can do b) and c), but I don't think it can do a) without having a serial-attached external datalogger.
It's probable that PINE64 has some kind of internal tool that profiles power/battery consumption as they design their hardware. If that exists and we can use it, that would be great.
If not, which 3rd party open-source LINUX tools are closest to fulfilling the objectives?
I'll search online, but if anyone knows already what tools to use, please share here. Thanks!
I would suspect much of the problem could be solved using the hardware acceleration hardware present in the chipset. Perhaps also utilizing the low rez mode on the screen when not needed. For example clapper video app seems to heat up the PPp about as much as idling with the screen active/unlocked, it is one of the only apps with the correct hardware acceleration compiled into the app itself rather than the OS. Almost everything else including the OS itself using CPU fallback. Most of the time all but one smaller CPU should be powered down. a study into how android and apple save power would be appropriate or even reviewing power savings including freezing unfocused apps unless specifically permitted would help. The Nokia N900/Maemo had a hardware abstraction layer, think of it as an API to abstract the hardware even though there was only one target device for the distro, this is ideal fr Pine librem and other android-first targets for the various mobile distros.
It is pretty clear that fixing power consumption has come a way with help from one dev especially, Megi(now retired); but is is also still by foar the most glaring problem with using the PP and PPp for any amount of time with the USB power unplugged. Less than 2 hours from 100% to battery empty shutdown with screen locked just listening to audiobook?!?! unacceptable for a real mobile device.
RE: suggestions for power/battery consumption data logger for community to compare? - Kevin Kofler - 01-01-2025
(01-01-2025, 03:16 AM)biketool Wrote: Megi(now retired)Huh? Since when?
RE: suggestions for power/battery consumption data logger for community to compare? - biketool - 01-02-2025
(01-01-2025, 09:50 PM)Kevin Kofler Wrote:(01-01-2025, 03:16 AM)biketool Wrote: Megi(now retired)Huh? Since when?
https://xnux.eu/log/
last submission 2024-02-28 Support for WiFi on QuartzPro64
we need more devs who really understand embedded and mobile hardware in an era where our desktop hardware has so much memory, disk, processing, and total electricity to burn.
I wasn't so skilled but I remember people using straigh machine language vs the built in basic to program for stuff like the zilog z-80 cheap computers of the time in order to cram in more program into the 16 or upgraded 32 kilobytes(32000x8 binary bits) of system memory.
<edit - CORRECTION>
https://codeberg.org/megi/linux
Megi was working on kernel 6.11 last month, but still seems to have backed off from epic level pine64 related development.
RE: suggestions for power/battery consumption data logger for community to compare? - Kevin Kofler - 01-02-2025
Unfortunately, the trend now goes in the other direction: Even C is now getting out of fashion, and people are moving to Rust or even to slower languages like Python. Even the Linux kernel is getting Rust modules.
I have some assembly skills, but mostly only the Motorola 68000 used on the TI-89 calculator. That was a nice, easy to learn assembly language. (Basically, the only big mistake you can make is reading or writing 2 or 4 bytes at an odd address, which will cause the infamous "Address Error". It does not even require 4-byte alignment for 4-byte accesses, only 2-byte.) Unfortunately, that architecture is no longer relevant for modern devices, even TI has stopped producing calculators using it.
My x86 assembly knowledge is limited, and ARM even more so. Unfortunately, modern CPUs have become so complex that the instruction sets have become a mess. x86 has so many instructions that it is basically impossible to remember them all. (Also, alignment requirements are very inconsistent: legacy instructions have none at all, but can be very slow when unaligned, vector instructions have hard alignment requirements, typically requiring the address to be a multiple of the vector size, which can be quite huge, and will fail with a hardware exception when those are not met.) ARM is a funny animal because it is RISC by design, but then things like implicit shifts and like vector instructions make it not all that reduced anymore. Still, some basic stuff has to be broken down into multiple instructions.
But the inherent issue with assembly is that it is non-portable: move to a different CPU architecture and you have to learn a whole different assembly language, and all the assembly programs have to be largely rewritten. C does not have that issue, but now people want to replace even that with higher-level languages.