If you follow https://source.puri.sm you will see lots of power related activity. So rather than doing idle speculation lets wait till next year and see what will be possible. Guesstimating all these numbers is not really helpful as nobody can tell how much energy can be saved.
Anyone know whether I could underclock a Chestnut batch phone on purpose to extend time between charges… basically cripple the device on purpose to mimic an ultra power saving mode?
(I would be okay with a phone that basically gave a flip phone experience)… no auto sync, minimal Web use, and set alarms on a clock app)
Thanks.
That’s probably possible. You should be able to turn off whole cores at boot time by editing the kernel command line.
Try adding
maxcpus=1
but note that may cause issues… (Only way to find out really is to try it, not sure what it uses for a boot loader but ideally you want a backup boot entry).
You may be able to disable cores at runtime (as root) via
echo 0 > /sys/devices/system/cpu/cpu1/online
If you poke around /sys/devices/system/cpu/cpu0/cpufreq/
you may also find a way to limit the frequency of the cores. If setting the frequency is supported, you can get the minimum frequency from cpuinfo_min_freq
.
Depending on the state of the kernel drivers, it may or may not actually prompt the CPU to downclock. If the power usage drops you’ll know it worked.
Is there an easily viewable changelog of packages going into the phone-staging repository? I try to search single packages on https://software.pureos.net but that does not show the release date or changelog of a version? Perhaps I need to install the repository on a Debian box and parse the incoming packages?
Thank You. It is very encouraging and exciting to know that if I get Chestnut delivery I have the power (and support here) to dig in… root access, finally!!! I really do appreciate your insight attention and time. Great answer @lperkins2 / Logan.
Edit: (had meant to message Logan directly, so as to keep thread cleaner).
Fair point but going from the interim battery (2000 mAh) to the final battery (3500 mAh) should make a fairly predictable difference, ceteris paribus.
No doubt, agreed. But throwing numbers in the discussion now (6h should be possible, 2d should be possible) is not helpful at this point…
I can just imagine the reddit brigade taking up the: “OMG, librem fanboys are happy with and expecting 6h runtime with the-thing-that-can’t-make-calls”.
I assume there are specs from both the modem and the SoC that could tell us how much power the devices are supposed to use in idle by the manufacturer. Assuming that the developers will suceed in putting the devices in the practically best possible power saving modes, it should be easy to estimate the run time (knowing the battery specs).
Please correct me if I’m wrong, but I tried the following calculation: If I read this spec sheet correctly, the SoC should consume around 0.6 Watts in idle (section 4.1.6). Assuming that the battery has around 13Wh (3500mAh at 3.7 volts) it would mean that the Librem 5’s SoC could run about 22 hours in this mode. Seems quite low to me, so I assume there must be something wrong with my calculation.
Edit: According to section 4.1.2 of said document power usage would drop to just about 0.1 Watts in deep sleep mode. This would result in a 6x higher uptime compared to the idle mode. However, I am not sure how operational the device would be in such mode and if it could e.g. react to incoming phone calls.
There’s a lot more to look up than that e.g. WiFi/BT, display, sensors, GNSS.
Or in other words maybe - can the modem wake the SoC up from deep sleep mode if an incoming call comes in and can the device as a whole get into fully operational state quickly enough?
Yes - definitely. But most of these do not have to be turned on all the time I assume, so the SoC and the modem will be probably the most important part when it comes to power consumption in standby.
Regarding the incoming call/message scenario: This will be the most interesting part, especially when taking into account the modem separation. I have no idea whether in general USB devices can send some kind of interrupt to a “sleeping” host or not.
Maybe some improvement in the next image?
I am very uncertain about carrying mainstream computer experience over to this environment but it can work on the former e.g. USB keyboard or mouse wake computer from sleep (but it may depend on the exact sleep state and on BIOS functionality and/or settings).
A USB slave device can talk when it wants. It isn’t like the OneWire protocol where the master must specifically poll a device to keep from talking over each other. It’s also quite simple to hook the slave’s TX line to an interrupt register either directly on the CPU or on an IO multiplexer. That’s what you do if your USB controller doesn’t provide interrupts natively (arduino UNO for example). The only hard part is if the device on the other end isn’t aware it needs to send a wakeup, the start of the transmission can get lost while the USB controller wakes. How you work around that depends on the particular devices in question.
Now, there is a dedicated label on the git: https://source.puri.sm/groups/Librem5/-/issues?scope=all&utf8=✓&state=opened&label_name[]=suspend
Since I no longer use the Librem5 as my main phone due to it freezing all the time (Frequent freezes) I made another discovery: When the phone is switched off, the battery is still dead after a day. Is there any hope that this will improve? There is probably nothing that software updates could help with.
what batch ?
It is from the Birch batch.
the first 4 batches preceding evergreen are to be expected to have problems … they are museum pieces after all … but the input that they generate is highly valuable …
yea but battery drain while the phone is off sounds like hw defect, and if this defect is carried to evergreen - this won’t be ever solved by software updates.
Birch: from ~3 to ~6 hours (so far)
I guess that would be >10.5 hours with a 3500mAh battery.