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.
Librem 5 can’t come too late, it can only come too early (which meant that if it comes to early with too many issues the idea of a free, linux-based telephone would be destroyed …)
Reminds me of the Neo Freerunner project … that definitively came out too early and I was one of the naive supporters who got a useless phone (since i am not an electronics engineer, just handy with code).
In some weird way the whole android thing – it seems to me – led the entire mobile Linux concept astray. Ages ago (in IT development sense), just before the first smartphones appeared we had a thriving community of mobile devices with Linux installed … anyone remembers handhelds dot org and iPaq-s with Linux? And then iPhones and Androids struck.
EDIT: handhelds.org is these days something completely unrelated.
Suspend-to-RAM alone isn’t important, but if you can combine suspend-to-RAM with the ability of the cellular modem to wake up the rest of the phone, then you have a usable phone, because you only have to charge it once per day.
The idea is that most of the phone goes uses suspend-to-RAM to go to sleep, except the cellular modem, which stays on to detect incoming cellular traffic. When the cellular modem receives an incoming call or SMS, it wakes up the rest of the system.
If Purism can get suspend-to-RAM working and the ability of the cellular modem to wake up the system, then I’m pretty sure that the Librem 5 will be a market success, because it then becomes an all-day phone.
I assume that the RS9116 can have a similar ability, where it stays on to receive incoming WiFi/BT traffic and can wake up the rest of the system when a WiFi call is received.
One thing that really annoys me is that we don’t have access to the documentation for the BM818, PLS8 and RS9116, so we can’t investigate how this would work. Every company that produces wireless chips seems to be paranoid about letting the public know anything about how the chips work. I assume this is due to the insane patent situation for wireless communications, plus fear that ordinary people will violate governmental regulations on wireless frequency use. All this secrecy is extremely aggravating if you want to control your own hardware, rather than letting it control you.
I doubt it’s that relevant these days. The use of smartphones today is still less and less on the GSM network and more and more via IP (data).
As I said above, for my personal case I use mostly applications like Signal and Matrix / Element (Chats and Fractal tomorrow with my L5). I almost don’t use SMS anymore but still calls via GSM.
I think that this mode can be interesting (for my use) by automatically programming the suspend to RAM after 30min delay for example because I would probably be too busy to check my messages but I can assume that in case of emergency I will be contacted via GSM call.
But I would ideally prefer a functioning closer to a classic Android smartphone.
Afterwards, it can be a good way to stop addictive smartphone use.
But it’s my own use, I understood that suspend to RAM with wake-up via modem is the ideal operating mode for some people here and that, on the other hand, it’s not satisfactory for many Android or iOS intensive users.
However this is more complicated than waking up on calls, as wifi traffic can also be a webpage which is reloading (news pages, new ads, …) which is not important to me to wake the mobile up while calls or messages (e.g. via matrix) should definitely wake the mobile up and show me those directly on the phone.
I kind of see the parallel to a phone without gapps and one with gapps where there is no push for google free android phones which leads to a lot of pulling (higher energy drain) or missed calls.
Depening on the time you need the system to get back from suspend to ram I would even say once you turn of the screen for more than some seconds it get’s into that mode.
Latest review of the librem 5 dogwood was about 4-6h screen on time. Maybe I understand the mode wrong, but I understood that suspend to ram is the most energy saving mode the phone can be. The phone has less tech specs than a flagship android phone while it has comparable battery size. In my head this would mean, we could reach android battery durations… I would not mind having the phone responding 1-2 second later then I pressed the button to wake up. But I am probably wrong.
Oh I see. Sort of like when google introduced “dozing,” I think they called it. Once the phone is locked for a while, it went into “deep sleep” and would periodically open one eye, so to speak, to check for notifications. OK, I can dig that.
That may apply in your circle. It doesn’t apply in mine. (That isn’t a reflection of what I personally might like.)
Yes, that is an additional complication.
It isn’t directly relevant to the scenario that I was describing i.e. where a packet just arrives for the phone.
When a web page reloads, that is typically solicited by the phone (by the browser). The assumption would be that either the web browser has been quiesced and it simply isn’t reloading any more or the phone would not suspend because the web browser is active.
Looking at my spiPhone, it seems as if the act of backgrounding the web browser (never mind about suspending the phone) stops reloading - but possibly that depends on how a script on a web page is coded.
in GNOME you can set the network connection to be (considered) a METERED type … it works as expected with the GNOME-software app but observing the network-graph from System-Monitor that setting doesn’t quite work with all traffic. there are still some traffic spikes from time to time that do NOT originate from actions i CONSCIOUSLY take …
i’ve been able to monitor this behavior on my Librem-Mini with PureOS Amber (up-to-date). maybe my PERCEPTION is what needs to expand
Yes, I understood. But it’s a fact. 2G network is shutdown, 3G will follow faster than previous generation and even for phone call, more and more are via VoLTE.
Even if Librem 5 is on a niche market, it must take into account the evolution of uses and not be satisfied with the practices of 15 years ago.
We are yet to see exactly what VoLTE looks like on the L5 but I suspect
a) it will look more like a traditional call than using a secure application over IP
b) all of the security problems that are associated with calls and SMSs via the traditional mobile network will be the same with VoLTE i.e. plaintext passed around the mobile network operator’s network, no E2EE
, 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.