So that would be I need to make some cycles to have a better information and the information I have are biased by “discovery” the battery status ?
This isn’t truth. What I can confirm is below rate at +/− 5.0V/1.5A as only reliable truth. At least charging with this speed under 50-60% for sure (and without any overheating issues):
It doesn’t matter if Librem 5 on or completely turned off it stays charging its battery with a 1.5A current. And although I never actually measured time needed, my guess would be still something around four hours from 2% to 100% (or even less).
As confirmed long time ago:
Confired here again:
Only thing that I might add (out of the blue sky and IMHO) would be that BPP-L503 battery likes (looks like to me) to be constantly (and steady) charged with 1.5A (or having at least 7.5W from connected power supply just for itself, if this serves or might be taken as an additional explanation) rate. Actually all numbers within this post are exclusively related to Librem 5 battery only.
The battery is charged with constant current (1.5A in our case) only for around the first half (percentage-wise) of the charging process. Then it’s switched to constant voltage and current drops asymptotically until it reaches termination current (IIRC something around 160mA in our case). That’s the typical process of charging Li-ion cells.
As @librem5 replied recently:
Just found additional expert interpretation of this relatively “simple” term that you wrote here: https://lygte-info.dk/info/batteryChargeTerminationTest%20UK.html or in shorter variant here: “In my charger reviews I often comment on a high termination current, and says that the battery will not be fully charged, but I do not specify more precise what that means.”
… “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.
Thank you, I will try your suggestion.
(And for the WIFI, I use an old hotspot, so it’s a B or G at best, so not a 5GHz problem)
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.
Thank you, I test the battery time this weekend to see how better it is.
This is permanent? or we need to execute this every reboot?
It working good here like not issues with WLANs.
For the permanent activation, see
“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
For permanent configuration, see: https://gist.github.com/jcberthon/ea8cfe278998968ba7c5a95344bc8b55
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.
I will wait to updates comes so.
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).