… “means”, in addition, that the Librem 5 Linux phone have his own built in charger:
@pit, thanks for your post (even if this sounds somehow strange from my side)! I certainly understood, appreciate, and actually liked your main message (although skipped it), your very main point here:
The original question was around the life time of the battery (97% to 20%) only about 6 hour in my configuration, and how to increase it and still have a functional phone (with cellular or WIFI).
and how to increase it and still have a functional phone
For starters, check whether you’re connected to 2.4GHz or 5GHz WiFi network. The WiFi module currently used on the Librem 5 is known to be power hungry on 5GHz networks. If possible, switching to 2.4GHz may make a noticeable difference.
Another thing - it’s not enabled by default because it causes incompatibilities on some WiFi networks, but there’s a power saving mode that you can try enabling and see how that goes:
sudo iw dev wlan0 set power_save on
If that works well enough for you, then you can make it the default in NetworkManager the same way you can do it on PCs (it can also be set per-network IIRC).
Other than that, powertop is a great tool to check which processes are waking the phone up when it’s supposedly idle, so you can use it to catch whether some process goes rogue on the battery in the background.
This night I turned off the librem5 and it lost battery from 100% to 95% in 9h, although completely turned off.
Why does the librem5 loose battery turned off? Is this a general hardware battery error? Or a general hardware error on the board? Or is my device broken?
In this situation, I noticed that if all 3 killswitches are switched off, the battery consumption is much lower.
Maybe it’s enough to turn off the radio killswitch, I haven’t done further tests.
Made those edits to create a wifi power safe on service. Cycle wifi power on L5, so far to no ill effect. Am using 2.4GHz connection only. Speed is still very good.
The phone cuts the battery out almost completely (leaving only RTC and battery gauge powered) on power off, but there’s one quirk - it doesn’t happen when there’s USB power plugged in when it shuts down. It also needs to be a clean shutdown, shutting down by long pressing the power button won’t put it into this mode, so the SoC will continue to draw some small amount of power.
And part
“If that works well enough for you, then you can make it the default in NetworkManager the same way you can do it on PCs (it can also be set per-network IIRC).” from
I made some tests and the librem5 seems to loose 1% of charge in 10h, when powered off, this equals a power-off-current of 4,5mA. This is quite decent. But remember that modern smartphones use this current when powered-on in standby.
If the librem5 is plugged in and powered off (and not charging), it uses about 150mA. Why is this current so high and will it eventually be fixed?
I try, but the save is not much, it’s better (40 to 60 minutes) but still far of what I need.
Thank you for your help, it’s very interesting and useful.
As far as I know that’s only a thing when plugged in and powered off, and IIRC that was related to some hardware “hack” employed to make SPI flash available to the USB-C controller at boot without it being blocked by the SoC - at least that was the explanation I received when I asked about it internally long time ago, but my hardware-fu is not good enough to understand the details In any case, it’s not representative of the current that’s being drawn from the battery when unplugged.
4.5mA when powered off while unplugged seems unusually high - unless the shipping mode wasn’t enabled, then it sounds kinda correct. Are you sure the USB cable was not plugged in when the phone was shutting down?
Also, a much simpler check could be a good start already: some people experience issues with GNOME’s Tracker (indexing engine) stumbling upon some problematic file and eating significant amounts of CPU. Simply running htop and looking at top processes (I recommend to do it over ssh) may already uncover such cases. In my case with the screen turned off, htop itself is the top process with ~10% CPU usage, and the rest stay below 1% (aside of some short periodic picks).
@dos@pit tried the wifi-powersave-on.conf method wifi-powersave=3 network manager setting and it completely blew up network manager:
first i created the conf file with root permissions only so my fault, network manager then couldnt be restarted, enabled or started.
after fixing that i was able to start network manager but VPN didnt work anymore, it kept trying to connect, flushed ip tables tried again no luck.
so removed the conf file went through all the nmcl wifi on wifi off routine and restarted network manager successfully, and after reentering the vpn password it reconnected, not sure why that password got flushed too.