Battery life too short (noob)

[dos]

@carlosgonz

This is permanent? or we need to execute this every reboot?

For permanent configuration, see: https://gist.github.com/jcberthon/ea8cfe278998968ba7c5a95344bc8b55

[pit]

@dos

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.

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?

[C_Chell]

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.

[dos]

@pit

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?

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.

@pit

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.

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?

[dos]

@dos

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.

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).

[C_Chell]

Thank you for the tip, I will see it later (low time to try to use the phone currently)

[JR-Fi]

To extend use time, you might be interested in new post about a new feature available: New Post: Librem 5 Suspend Preview

[Captain_Morgan]

@dos @pit tried the wifi-powersave-on.conf method wifi-powersave=3 network manager setting and it completely blew up network manager:

1. first i created the conf file with root permissions only so my fault, network manager then couldnt be restarted, enabled or started.

2. 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.

3. 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.