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.
Worth noting that that’s idling with screen and screen, modem, wifi, and usb off. However, that goes for the previous record too, I think, so still a very good improvement.
Hi richi,
Any news from your side? Can you confirm longer usage over the last month?
I am not sure if you already get all the fixes described above by updating but it is worth a try.
Hi howil,
thanks for asking.
Unfortunately, battery run time has been the least of my concerns lately. The mean time between freezes is way below the battery run time.
To be exact, the previous record didn’t have USB off (but there were plenty of non-USB related improvements as well :))
What do you people think how much time increase can be reached by optimizing software? We saw a huge increase until now, but something above half day isn’t even close to running a whole week in idle. And since hardware is not as optimized in power usage as other phones I’m not even sure that something similar can be reached with only software optimization.
But I’m also no expert. So what do you think is possible with a well optimized software? 1 day idle? 3 days? Is it even possible to evaluate it with the information we got until now?
My guess is that this will not ever be realistic with v1.
It is better to measure than to speculate.
Whats wrong with speculate by using technical knowledge (what I think some people here have)? Just from reading Purism it sounds like “we have almost optimized easiest and most effective things and we reached an up-time about 14h - anything more will need a lot more work with a lot less effect”. It sounds like more then 1 day isn’t possible with v1.
But I also know that I miss a lot of information about “what can be done further to optimize” and I also cannot evaluate at which point of optimization we are in real currently. I don’t care much about 100% correctness, but I care about more information since it’s 2nd most important thing I want to know (first important is data security and open source hardware).
You might have heard of the Pareto principle or 80/20 rule.
It’s very general, and in my own experience I constantly find it to be true: You get 80% of the results with 20% of the work, and vice versa.
I assume, this is about the state of Librem 5 power optimizations: All relatively simple things have already been implemented and most future optimizations will only have little effect.
It’s very unlikely to double the standby time from now on.
The bigger battery will have the biggest effect.
In theory, a lower boundary for energy consumption could be calculated - a boundary that can never be crossed: Turn off all non-essential components, assume lowest power state for essential components like CPU, RAM. I guess those two are the biggest anyway (display off), and if you calculate the lowest possible consumption for those two, you can define such a lower limit.
As I said, I’m almost certain that this lowest limit is more than half of what we currently have, so runtime cannot possibly double, except with a bigger battery.
Thanks for your reply. I know the principle even if I didn’t know its name. Something similar was the reason to ask this.
But I thought CPU and RAM usage in stand-by can maybe reduced even more with software optimization. So this counts to the things with lower effect in your opinion?
If so we can say the huge difference between Librem 5 and any Android phone is not the OS optimization. It is more a hardware problem. I mean a 28nm CPU needs more energy then 14nm or even 7nm and the all-in-one SOCs are even more efficient (while using it). Even my old Android 2.6 phone with 1700mAh battery has over a week up time. I just didn’t know that this makes so much difference.
However, I think these things will be better with future phones. But we need to start at some point, so it doesn’t change my mind to this project.