Librem 5 Phone Dogwood Thermals and Battery Life
puri.sm
puri.sm
Iterations in electronics are really expensive (my last project cost $30k for 10 assembled prototypes not including of our labor) so most people just copy as much of the manufacturers' reference design as they need. They pour over PCB layout notes and look at how the manufacturer or other customers did and mostly just copy them. Most of my engineering decisions are based on about a dozen black box helper apps that take in my fab's capabilities and signal specs and spit out DRC rules. It gets a little trickier with antenna design but that's often outsourced because you need very specialized facilities for FCC certification anyway.
All in all, it's just like working on a complex distributed system. There are so many things to juggle like R&D budget, per unit COGS and space budget, suppliers and part availability, and supply chain orchestration that it ends up being lots of boring work just to coordinate between all the different experts involved with small bursts of productivity when everyone is properly aligned.
Still aspiring to work on something challenging is healthy and I respect GP’s sentiment!
Last time I checked, they hadn't corrected the documentation of their previous line of SoCs (almost 10 years old), despite acknowledging the errors I reported many ears ago. You can either consider that personal support was good, or that, by not correcting stuff they know is false, they don't give a damn about wasting every other user's time (and wasting the support staff time again and again each time a user will ask the same question).
I also remember using a simple piece of software from them (a GUI for pins assignment, which basically consisted of a list of checkboxes, or some kind of simple spreadsheet if you want): that super basic thing leaked several gigabytes of memory per hour, just idling. Well, I couldn't let it on 1 hour, I had to take the habit to stop and restart it after 15-20 minutes...
Sadly he passed away before he had the time to really get it off the ground.
The app you talk about was probably developed by some summer intern on a tight schedule and never documented, then someone else took over.
They literally don't give a flying fuck about software. One manager I had once was so clueless, he couldn't understand that the GUI of the C# app I made had no code behind it, and kept asking why clicking the buttons isn't doing anything no matter how many times I tried to explain that a GUI can exist without functionality and it's a separate effort to implement that.
Certain apps we were using internally were based on same Java version from 12 years ago since the person who developed it is now a senior line manager and also the sole maintainer.
Then they brought in some Agile/Scrum consultant to increase efficiency and he implemented 45 minute daily stand-ups with 10 people and half of them remote via phone from another country and then he spent most of the day chasing us around the building asking how soon story X will be done. Then they outsourced the whole thing to Poland.
Working in that industry as a SW developer has been a colossal pain and a huge setback for my career I try to slowly erase from my resume.
Silicon, lest anyone think you were working in a different industry.
Edit: Nowadays I only do electronics for personal projects and since I stick to three fabs (a local one one I've got a relationship with and two Chinese specials), I've just got a few manually created DRC templates per fab, # of layers, and max signal speed with a few templates just for RF that I got from a mentor.
Do you know why? In my eyes that would make them a crazy unattractive supplier.
This isn't the kind of environment you'd find many passionate software engineers because most of them leave for greener pastures unless they really care about the product they're working on, but they're rarely qualified to run developer experience departments.
You spoke of the Basebands...that reminded me that Fabrice Bellard works on the other side of the equation [0]. May be, if we are lucky, he turns his attention to fixing mobile phones [1].
I even found a TI 1080p UV DMD and bought a roll of lithographic film to try to get that feature size limit down. My plan was to expose the litho film instead of the wafer directly and build very precise jigs for the film off of a precision machine base I could get for a few grand, with custom built linear motors to move between steps but I got stuck on the physics and math. It looked like I had a solution using neural networks and a DIY laser interferometer as the feedback loop as a shortcut to learning control theory but then got distracted by more urgent matters... c'est la vie
[1] http://sam.zeloof.xyz/category/semiconductor/
[2] http://sam.zeloof.xyz/garage-electron-microscopy-first-image...
I thought the voiceover video for the SEM lithography experiment worked really well ( https://youtu.be/SB94rQtKlKI ). How does the spot size from the SEM compare to the ~1-um resolution you get from the DMD? I assume you're not actually getting 5 nm out of it...?
I'm pretty sure that it was expressly chosen because it's reasonably documented unlike most SoC chips. Not that this solves the expense and effort with iterating hardware, of course.
At the point where we got access to documentation and very basic support, around $1M USD was paid (part of which was covering the initial shipments of chips though).
I should check on the pyra and see how that is.
I thought I'd check on the project while writing this (every now and then I come across something that reminds me of it), and I see that the Preorder FAQ for the Pyra looks exactly like the one that was up for the Pandora for (what seemed like) years!
I lost the open pandora, and that was a sad day.
Any other consumer-grade phone gets something like 24-36 hours by sleeping a lot (or something).
Should I expect the Librem 5 developers to be able to achieve the same thing before they ship Evergreen?
The lack of screen off times in the article is definitely worrying, though. That's just as important a metric.
Edited to add: actually, the first graph is screen off, I think. Looks like it's a tick under 10 hours. Which is poor, so I hope there's more scope for software improvement, but I also think is a fairly significant improvement over where they were 6-12 months ago.
Edit: but my two sibling comments now seem to have more useful information than this one.
Keep in mind that that "idle time" is actually "suspended time" - to handle things like incoming notifications over the Internet you still have to periodically wake up. Without suspend, PinePhone currently has a pretty similar idle power usage to Librem 5's. Once Librem 5 starts utilizing suspend to RAM, it should see a very similar improvement like the one you're linking to.
AFAIK, Android uses suspend-to-RAM heavily (this is what a "wakelock" is all about: it prevents Android from suspending when held), and that has a large impact on battery life.
A distant future. A Purism employee (who will probably show up here since he takes part in each HN thread related to Purism) said nobody is working on it. So don't hold your breath in the near future.
Last time I worked on this kind of thing there was great kernelside suspend support that works, but in terms of userland there was no generic linux arrangements for this kind of finegrained management of it.
I also understand the point that for users, atm they just see no ability to defer when they will use the phone while it's still needed to receive calls, which is fatal. It seems properly solving this needs a new, separate userland project somewhere.
It's not exactly that "nobody is working on it". There was some initial work on suspend done already, you can flash a different ATF branch and get it to suspend and resume just fine - it's not used by default as currently you have to choose between suspend or DRAM frequency scaling. It's just not the top priority right now, because we're focusing on runtime power management and other promised features like DisplayPort first and there are still some things to do before it actually makes more sense to go back to suspend.
If we worked on suspend instead of runtime PM for the past half a year, we would probably now have 100h+ suspend time that would go down to 2-3h as soon as you kept ssh connection open or did anything else that would prevent it from suspending. Or even actually used the phone.
Also, just being able to suspend is one thing; but there's a ton of work still needed to properly utilize suspend from userspace, so you can still keep things like IM or e-mail notifications working transparently. The less power the phone uses when not suspended, the better - at this moment, suspend would be just a band-aid.
Have you considered how much good press the suspend time got the Pinephone? And how it is one of the key features people talk about - as in, how long the phone will last? And how in these threads people keep asking you about it? And how you could have that good press?
From your comments I worry you are only looking to release such a feature when you've fully implemented every system involving it. I realise this is very easy for me to say from a backseat position, but maybe bump it up the release schedule, and then those that do have librem 5s could at least have a 103 hour tablets that sat in their pockets, not a 5 hour paperweight that sat on their shelves until they wanted to charge it and play with it again. If nothing else, it will completely change the y scale on your bar charts.
I've been very much enjoying the updates around the librem 5 and hope everything goes well for your product.
Focusing on suspend time first may be worth it marketing-wise, but in my personal opinion that would be kinda deceptive.
It's unlikely it'll get as good as Samsung or Apple by that time but it should definitely improve. Unless they made some critical mistake in the hardware, they can make continuous improvements in the software.
It's no surprise that this is one of the last things they're focusing on. Idle power management on modern operating systems is hard and is very kernel and hardware specific because kernel interrupt and process scheduling comes into play. Hence why Apple is so good at battery life - they have such unilateral control over the hardware and software stack that they can make optimizations that Linux/Windows/Android really struggle with.
Good job.
An aside: if apple would stop making the new iOS updates so draining on older phones it would help - the last iOS update took my battery from 2.5 days without a charge to 1.7 days “overnight” - imagine what this did to people who didn’t buy the silly oversized model with the lower screeen resolution? It’s basically a malware attack on their users to force them to update
Curious what your solution is for non-cloud backed up 2FA tokens. Phones break, get lost, and get stolen, so backups have to be done somehow.
The cloud is a dumb place to store secrets, as anyone on the planet can attack your secret storage. Almost any offline medium (including a Post-It stuck to your monitor on your desk!) is inherently safer.
https://wiki.mobian-project.org/doku.php?id=pinephone
How to set up a wifi HotSpot is here: https://wiki.mobian-project.org/doku.php?id=tweaks
Although note, as of now, neither the Pinephone nor the Librem 5 can do MMS (they both share ModemManager and it doesn't have MMS functionality)
are there any recent discussions about debugging MMS on Pinephone I could peruse?
https://gitlab.freedesktop.org/mobile-broadband/ModemManager...
There's a start
The basic debugging workflow is to run ofono, run MMSd, and try the scripts under the `test` directory in MMSd's source tree. Error messages logged from the script, MMSd, or ofono might be relevant.
MMSd (mms parsing, mostly) and ofono (dual-stack IPv4/IPv6 networking) need patching to make MMS work on T-Mobile; other providers might also need debugging or custom patches.
I am very excited to purchase, use and tinker with the Pinephone
I remember the original iPhone not supporting MMS either but that was 13 years ago and I haven't received or sent an MMS since.
There’s really two problems.
1. Speed. The CPUs are just underwhelming. It is not unusable by any means, but it definitely feels like many steps backwards. I think at least the PinePhone needs to be running lighter software; Wayland is certainly not an issue, but a lot of heavy GTK software is probably not a good idea. Web browsing is tricky and makes me wish there existed lightweight browser engines that implemented less of the web standard, but it is actually passable believe it or not.
2. Linux desktop software is just not designed for phones. I think Phosh is clever, and feels very nice to use... until you remember its a phone, and then realize the inherent differences. Normal phones have some kind of central push notification management, but not here. I assume when the device sleeps, you simply stop getting any notifications. I haven’t actually seen a notification pop up on the lockscreen yet, so I’m not sure. There’s an SMS and messaging app, and Telegram/tdesktop works really well, so there is that.
I think that both problems could be solved somehow, but it’s feeling like it could be a tough one. One of the things that both iOS and Android did right off the bat was dramatically change the model of execution that apps had, to orient them around the concept of constantly being swapped in and out. There’s really no obvious way you can support standard Linux desktop apps without some compromise here. I would actually be pretty happy if these devices were capable of just staying awake on a low frequency most of the time, because I think that would dramatically simplify things, but you would have to worry a lot about power draw from apps running and etc in ways that you don’t have to in most modern phones.
Some may view the lack of a good push notification story as a benefit, but for me there are definitely things where I want it to be reliable and timely... so I am left feeling a bit lost.
I did my first "Hello, world" app for it on Mobian on Pinephone, linked below, with that library and that seems to work pretty well.
[1] https://github.com/quietlychris/mobian_hello
Edit: After some prelim testing, it does look like the notification from the example I linked doesn't get pushed to the phone while it's sleeping. Unless there's been a fix pushed in the week or so since I've updated it, looks like that's still a to-do.
Libnotify is for sending notifications to the OS for display. However “push notifications” usually refers to the system that handles the push portion. For example, APNS (Apple Push Notification Service) and FCM (Firebase Cloud Messaging.) Lacking a centralized service both on the OS side and in the cloud, it’s difficult to see how a battery-optimized push notification system could be devised. From my understanding, on today’s phones generally the CPU has to wake up periodically to poll, and if you have many individual push services that would be inefficient. (Maybe iPhone has a more clever system than just waking up the main CPU to poll, I do not know.)
Even the userspace running on the modem can hardly be called completely proprietary. It's some busybox system + bunch of other tools that are also under GPL or other OSS licenses. I didn't measure it exactly, but it wouldn't surprise me if the amount of proprietary code in userspace of the modem is < 20%.
You can't modify the modem firmware and then still legally operate it in public networks under most legal jurisdictions around the world.
Anyway, the original issue was about notifications, and ability to implement them without consuming too much power. And one of ways to do it is to extend the modem this way.
Even if you had many push services, waking up periodically and polling them all at the same time ought to be rather efficient.
GTK by itself is quite light, even GTK3. It's certainly lighter than the Java UX of Android.
The Vivante GPU is also pretty capable: https://social.librem.one/@dos/104218666011152589
Notifications on the lockscreen are planned, just give it some time :)
> I assume when the device sleeps, you simply stop getting any notifications.
That's true, and that's one of the reasons why Librem 5 doesn't utilize suspend yet - the idle times as seen in the article are just that: idle, not sleeping. We could have made integrating suspend in ATF our top priority, but there's still a lot of groundwork needed before it will actually make enough sense. There's plenty of other power management work to focus on first.
AOSP is one of the most secure consumer OS around right now, surprisingly.
But they’re one of precious few companies with a fighting chance of bringing open software to mobile. For that reason alone, they’re still on the side of the angels in my opinion.
So root for the Pinephone and PostmarketOS, and continue to hold Purism accountable. But if Purism and the Librem have an outside shot at positively contributing to the mobile landscape if given the chance, then entirely-valid criticisms of the company and product should be tempered with that chance in mind.
Also their desktop OS is pretty sweet. If they converge the two (texts, clipboard, calls), it will be worth the bumps in the road.
I will pick one up when 14nm is introduced. It's a damned server in your pocket.
If you want a Linux phone you can check the port status of postmarketOS or just get something like this. https://en.m.wikipedia.org/wiki/Meizu_PRO_5_Ubuntu_Edition
None of the behind the scenes crap, no constant delays and no drama, with way better hardware for a cheaper price. If you want a server in your pocket the pine works for that but so does a cheap Android phone too.