Battery for Librem 5

Years ago, I used to read about differences un electricity consumption based on how many 1s your RAM had to hold :smiley:.
To be honest, I don’t think the amount of data in your flash storage makes any difference. If you don’t insert an SD-card at all, yes, but how full it is? I would be rather surprised.

1 Like

Edit: Future readers: please read ruff’s reply and my next post. I didn’t think this through!

That must be true if the flash controller is blind to the meaning of the bits that the operating system gives it. It would just have to treat the entire capacity of the storage as one giant file, all of it important and needing to be carefully preserved, with no concept of empty or full; it is always full!

But operating systems can often tell the controller which bits represent useful data and which are free space (i.e. TRIM). So perhaps the controller could use that information in a way that affects power consumption. I have absolutely no idea if this is done in practice. I’m just speculating from abstract principles.

I share the hunch that any noticeable difference in power consumption probably comes from applications that read the files rather than from the actual storage of the files.

1 Like

Trim is a bit different, trim is like free() call in c - it just says - return the block of memory back to the pool of available (heap). It doesn’t touch the actual memory content. Similarly trim just marks the blocks as free in the flash overlay map. Which is the reason it is always warned - it’s not a secure delete, the content remains in the disk.
What does consume memory is flipping the bits (write) and checking their status (read). Assuming it is flash technology - writing a single bit may trigger zeroing of entire block and rewriting it. But again it’s part of write.
flash memory is nonvolatile - keeping the bit status is achieved by charge trap, that does not consume board memory (unlike RAM).


Yes you’re quite right. Flash does not require energy to maintain the state of bits, being non-volatile. I have vastly over-stated the possibility that trimming could affect power consumption, forgetting that the memory does not need to be actively refreshed. Perhaps it can affect the power efficiency of some read and write operations, but the difference will be tiny.

I started out intending to make the point that, from the point of view of the hardware, there was no concept of being empty or full. Then I realised it’s more complicated than that with Flash and ended up confusing the matter! Should’ve thought more before opening my mouth! :face_with_hand_over_mouth:

1 Like

Looking at these statistics, it seems like a small wonder that I’ve never broken my screen in the 4 years or so that I’ve had a smartphone of some kind, despite never using a case. It might help that for a lot of the time I was using a ZTE Zinger with a tiny screen, and another lot of the time using a OnePlus One that already had an unusably cracked sceeen when I got it (I used a mouse for input). This phone was later stolen and destroyed, though, so for the past two years I have been using another handed-down OnePlus One, but even this one still doesn’t have a cracked screen, despite getting too close for comfort a couple of times.

My old ZTE Zinger had a fairly immersed screen, which I really liked, but my newer used OnePlus One sadly has a much less immersed screen than it.

Depending on the flash controller, TRIM will preemptively zero sectors. It can also prompt re-organization of the physical sectors in non SLC drives, both for wear leveling and because the drive will write in SLC mode for speed, but then want to re-pack the data using all available layers, which is a slow operation. As for why it zero sectors, changing a single bit requires zeroing the entire sector, then rewriting it with the bit flipped. The 1->0 transition is slower than the 0->1 transition, and even if it were the same speed, not doing it in advance would cut the speed in half.

The reason you can’t rely on it being a secure delete on any arbitrary drive is the spec doesn’t require the drive to do anything, the firmware is closed source so we can’t tell when it will do something, and even on drives which do actually pre-zero sectors, they wait until the drive is idle to zero and repack data, and there is no way to ask what the status of that process is.

On a related note, SSDs do require power to maintain their state; they are not perfectly non-volatile. The potentials internal to the cells drift over time, which will cause bit-rot if left unpowered for long enough (for most drives, multiple years). While powered up, but idle, the controller will keep track of how long it’s been since a cell was written, and periodically check its potentials, rewriting the data when they drift too far. The energy required for this is tiny, but it is why using SSDs for long term data storage is not a good idea.


Yes, sure there are various implementations but as you rightly noted - spec does not require doing anything so you cannot rely on it. Usually there’s lazy zeroing as part of background garbage collection but again it uses its own logic which considers power state, leveling score, free space, etc.
And yes, some smarter controllers are doing recharge of the blocks to improve data integrity - again as background task which preemptively tries to re-locate bad blocks. Which is again subject to wearing and power policy.
So gathering all facts - full disk may consume more power because it does not have luxury of freely choosing new blocks, space pressure will require more aggressive zeroing. But this would be implementation specifics and may change with a new controller firmware release, as vendors are trying to balance power/wearing/speed, which is endless chase for perfection.

1 Like

Aye, and the difference in energy consumption would likely be something on the order of millijoules to tens of joules per month. Not really enough to worry about optimizing even if we could tweak the device firmware.


is dogwood L5 batch to ship with the smaller or bigger battery variety ?

1 Like

Dogwood is supposed to ship with the large battery, but since no one has received one we can’t be sure yet.


That is what we are aiming for.


Hi Nicole,

Do you know if external chargers are likely to be available also? Or some means of charging the battery without putting it in the phone and charging that way?

MrChromebox mentioned on the r/Purism forum that the battery will be 3600 mAh, not 3500 mAh as previously reported. I love it when we get a little bit more. Now if we could only get a little more RAM. :slight_smile:


:slight_smile: what, did they already give you the “vaccine” ?

In this new video from Purism the new battery is 3500 mAh

The reddit comment about the 3600mAh battery was on March 3, 2020 by Sebastian Krzyszkowiak (seba_dos1), not by MrChromebox. However, I would assume that HackersGame has more up-to-date info on the battery.

It was fun to hope for a little more battery capacity, but the longer battery life reported in HackersGame’s video is even better news in my opinion. It sounds like we will have a usable phone, which gives me a lot of hope.


We currently have no plans for such a thing, but there are chargers for this purpose already on the market which should be usable - these kind of clip around the battery, have adjustable connector pins and can be hung off from a USB port, pretty convenient.



Exactly what I would need, thank you!

There are two main steps, first one is to get green LED light by having + and − contacts placed correctly (+ is on the right side of the used battery “holder” (I might reopen this holder to show how I put together connections, just ask). After first step completed, please connect purchased 4.20V power supply to the 230V mains and let your Librem 5 battery charge (only if not already at 100% :grin:), until you get steady green LED light again. I’ve used following components (to “glue” things together):

@Lvovich, concerning the another replacement battery for your Librem 5, when and if interested user from Europe (I guess), please search this Forum for the other somewhat related post of mine, as of today, referring to “Designed in Germany”.