Similar to your computer there are things which can wake the system from suspend. They can be network activity, WOL packages, timers, or clicking on a mouse or keyboard.
Suspend to RAM is low hanging fruit that would allow the L5 to go a full day or longer. My needs for what could wake the L5 from suspend are very limited. Only incoming calls or text messages. Everything else (emails, chat, etc.) can all wait until I wake the phone again. This is probably the difficult part. Getting the phone to resume fast enough to handle the incoming call, etc.
However with this working the development team doesn’t need to nickle and dime every bit of power savings into the phone. It gives the development team time to focus on other things, like the camera, for example.
With suspend to RAM we have the ultimate high breed of the mobile world. It is basically a tablet laptop with cellular functionality and smartphone format.
Ok, I understand better your need.
I hope that power management progress will be enough to have a use more closed to traditional smartphone.
Today I use more chat app like Matrix than SMS, and suspend to RAM will not be useful in this use-case.
@Kyle_Rankin
given the doubts that exist, could Kyle be more specific and descriptive? that is, are all buyers of the Librem5 in the crowfunding campaign covered by the November shipment?
regards
I agree - I also moved from calling and texting to calls and chat via matrix. But as @2disbetter mentioned wakeonlan packages… maybe it would be possible to let the matrix home server also send packages and let the librem 5 wake up upon them to show an incoming call?
Having the librem 5 not wake up on such events would in my opinion contradict the “IP-Native Communication First” selling point.
While we intend to scale up our shipping/fulfillment team to meet the surge of pre-ordered phones, I can’t commit to how fast that team will be able to process orders at this point. I also imagine if it’s like past experiences with, for instance, the devkit, things will start out a bit slower and then accelerate as tasks become second nature and we continue to find better efficiencies in our process.
For instance, I helped with the devkit shipment. At first it took me quite some time to connect those incredibly tiny and delicate WiFi antennas. About 50 antennas in I got really good at it and by the end I was incredibly fast at it.
With respect to power management, we have been prioritizing runtime power management over suspend right now because we want you to be able to use the phone for a long time. Having a phone last in your pocket all day is nice, but is less valuable if you can only actually use the phone for a couple hours. A lot of phones out there have nice idle times but don’t last all that long if you are actually using them. My laptop can be suspended for days, but I’d be upset if it only lasted for 4 hours when I was using it.
We know that suspend will come and when it does it will help with in-the-pocket idle time, but there are still a lot of “low hanging fruit” with respect to active power consumption we are focusing on first because in the end it will be more valuable for all use cases.
Absolutely. If there is plenty of low hanging fruit to pick, go for it all. I don’t mean to say that suspend to RAM is more important than usage time.
Heck if I can get full day usage without any kind of traditional suspend scenario, that would be even better! Still being able to suspend or hibernate my phone will just be cool.
Yes, in our internal tests with the screen off and things idle, but not suspended, we’ve gotten between 8.5-12 hours of active runtime. David Hamner’s post on Dogwood power management and thermals illustrates it well:
I’d say around 12 hours of mixed-use (some active use + idle in pocket without suspend) would work well for your average person. It matches a model of someone charging at night, going out for the day, and plugging back in when they get home. Obviously longer than that (say 16 hours so it lasts through all of your waking hours, charging while you are asleep) would be even better.
Hey, @Kyle_Rankin, you know what I’m going to ask!
Are the designs for the CAD model used to make the mold now going to be released, now that it’s “set in metal”? It would really help the cover design crowd!
Thanks for the answer @Kyle_Rankin I think, therefore, that all the phones will leave by December (hypothesis: a person assembles a phone in 30 minutes. The working week is 36 hours for 5 working days. In a month there are about 22 working days. so one person assembles about 308 phones in one month.)
regards
So that when I stash it in a cubby-hole outside of the SCIF , the phone will not have lost a significant amount of battery time when I come out hours later. There is no phone charging in the cubby-hole.
In that scenario wouldn’t you want to shut it completely off and on boot do a Librem key style tamper evident boot validation check not leave anything suspended to ram?
I don’t know that (for me, anyway) suspending to RAM when hitting the lock button is the right way to go (though I admit that suspending to RAM when hitting the lock button is an assumption I’m making). If that is the intent, I’ll often play music on my current phone and then hit the lock button to shut the screen off and set my phone down. I wonder if it wouldn’t be enough to just soft power-off unneeded hardware? It seems all you would want running when the screen is locked are the radios (WiFi and cell), vibration motors, and speakers. The antennae you can cut power to with the killswitches if you want, and the other two aren’t doing anything unless either a notification appears or you actively play audio. If you suspend to RAM then the phone is entirely inactive.
Another way of looking at it is … lock button (explicit or implicit) is a necessary but not sufficient condition for suspending to RAM, and you only actually suspend if nothing else is preventing it - and streaming audio to the speaker would prevent it.
WiFi is capable of going into a power save mode, wherein it wakes up (enough) every X ms to listen for a beacon frame and the TIM therein that will tell it whether there is any traffic for it. (On my WAP, X is 100 but it could be configured for more sleepy WiFi clients that would use even less power but be slightly less responsive to incoming traffic.)
If the WiFi does then receive the packet, it must then have some way of bringing the system out of suspend-to-RAM (standby).
Adding: although I note that my spiPhone does not behave like that. When the lock button is pressed, it is simply unresponsive to network traffic.
, the phone will not have lost a significant amount of battery time when I come out hours later. There is no phone charging in the cubby-hole.