Obviously an exciting step forward. Of course I had to try it out. I think I saw one of the posts above answer this, but then someone asked the question again, so I’ll help re-answer. In my experience the only issue was that my morning alarm did not wake up the phone. It just told me later when I got up on my own that I had missed it.
So then I told my phone NO, YOU missed it. And then phone said, “Oh yeah?” And I said, “Yeah.”
But I had woken up anyway, so I still had to go to work.
I don’t know why the suspend needs to be so long. In terms of clock cycles of the CPU, this sounds like an eternity. What matters to save power isn’t the continuous off-duration, but the duty cycle of the on/off periods.
A series of events that need to happen upon wake should be established. Let’s say that a polling of fifty events needs to be checked upon every wake. If each event takes 1mS (1 mili-second) each, then checking 50 events takes 50 mS. That’s one twentyth of one second or 5% of one second of awake time. If the phone stays asleep for ten seconds each time before waking, then the phone is awake for only 0.5% (one half of one percent) of the time in such a duty cycle. So you could wake the phone every 10 seconds and increase the battery by several times over, in the process. You might even be able to do the same if waking up once every one or two seconds to save a lot of power.
Although my example may or may not be accurate, the concept should still apply. At GHz processing speeds, you can wake up, do a lot in a fraction of one second, and then go back to sleep for a majority of one second before waking up again. So why wait several minutes to wake the phone up?
I’m sure initialization of components like the modem isn’t instantaneous.
this work it’s very important.
Best regards
For me, the tweak described in https://wiki.mobian.org/doku.php?id=tweaks&s[]=ssh#prevent-sleep-in-an-ssh-session is good enough.
That’s not a golden bullet either, as this would only work with GSM data enabled and wouldn’t be able to use WiFi, VPN etc.
I think i would like to add not sure thats the right topic here but for long battery life you need three things.
Scenario suspend each app, only keep active the app a user is viewing (basically only keep that desktop alive in which the app is running - on fullscreen in phosh). That isnt happening now or at least not aggressively enough.
OS suspend scenario would be to stop notifications when do not disturb is selected or reduce frequency of querying for notifications when in power save mode, stop all background running app processes etc.
Then scenario discussed here where devices on the phone are selectively powered down or up, or put into powersave mode. e.g. drop frame rate and screen refresh when reading a book and only bump up frame rate when user starts touching the screen etc
Because it an experimental stage, then the suspend config on setting it is for laptop, not for mobile. Of course Purism will perform suspend mode in the best and smart way to L5.
Purism team is constantly adding battery-save in all 3 modes, Active, Inactive and Suspend.
It there a hope to keep the gsm-data enabled for apps notifications on suspend-mode by WOWWAN?
I did longer testing. In 8h (+1min), with all the kill switches in use (phone as idle as possible), using the suspend preview, battery went from 98% to 70%. This gives much more accurate picture of the potential of the suspend feature - huge possibilities compared to current usetime (even if ~2,25%/hour isn’t very efficient - still no optimization yet)! Several times more than the previous estimate based on two hours (although the setup was different too).
Like in previous test, L5 clock alarm did not wake me up, but that’s why we have backup systems. Interestingly, it started to ring immediately when I pushed power button to wake the phone, as the wake-up ring event was still in progress [made me wonder: who woke up who…? 
].
sudo systemctl suspend
It may be my imagination, but when testing the experimental suspend, after I wake the phone, and see it’s time to recharge, plugging it in doesn’t activate the LED, and charging doesn’t start. Unplugging, then turning off suspend returns plug-in and charging to normal behavior. I’ll have to check this a few more times to confirm.
P.S. Lots of time-out options now:
How to find out how the Settings --> Power tab’s “Battery” calculates time remaining? I think it would be helpful if that showed at least four different counters:
Even if they would be kinda sorta almost estimates (that could improve in accuracy over time), they would provide better understanding to user about power.
And after a few hours of use, the suspend seems to work much better now than when initally introduced… so far. I have on a five minute timer and it’s not noticeable when going to sleep or waking (apart from having the status led also shutting down and screen going black). More testing and testers needed, of course.
Can the suspend function allow background services to run? Something like Apache installed from terminal? Not the app version.
No. Suspend shuts the CPU down.
Install phosh-mobile-settings and under Librem 5, click the red button with “suspend now” label.
Probably not related to using suspend. Charging failure occurred today even with suspend off. I corrected using the Evergreen troubleshooting method described here.
That it is for Heat, not for Supend.
Try L5 cooled the charging issues, it just not happen.
The phone was not hot when I first plugged it in and when charging failed to activate.
