Blog Post: Librem 5 Evergreen Update: Mold and Milestones

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.


Indeed, and even just turning the screen off with good idle power management will allow it to last a decent amount longer.

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.


Please don’t forget to extend the screen protector. :wink:

Hey, @Kyle_Rankin, you know what I’m going to ask! :wink:
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!

I’m not sure what the timeline is for releasing complete CAD design files.

It sounds like a hack to me, not like a function that can be used by a normal user on all his daily applications.

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.) :grinning: :nerd_face:

1 Like

So that when I stash it in a cubby-hole outside of the SCIF :male_detective:, 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.

1 Like

Precisely. Not really getting reception in the cubby hole anyway!

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.

1 Like

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: is these days something completely unrelated.

EDIT2: But there is this: and it looks cool :wink: .

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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.