[HN Gopher] Librem 5 Phone Dogwood Thermals and Battery Life
___________________________________________________________________
Librem 5 Phone Dogwood Thermals and Battery Life
Author : Stephen304
Score : 94 points
Date : 2020-07-28 17:25 UTC (5 hours ago)
(HTM) web link (puri.sm)
(TXT) w3m dump (puri.sm)
| mikece wrote:
| Promising, but how close is it to being ready for consumer use?
| If all it can do is make/receive phone calls, SMS, and act as a
| WiFi hotspot, and cost less than USD$300 that would satisfy _my_
| list of desires.
| jchw wrote:
| I just recently received my PinePhone Braveheart unit, which is
| by no means a similar device. However, I did try running
| Mobian, which runs a similar stack (including Librem's
| innovative Phosh.) It actually is pretty impressive, and even
| though it is not aimed at consumer use it is pretty close to
| being usable as a basic phone with Linux.
|
| 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.
| zozbot234 wrote:
| > Wayland is certainly not an issue, but a lot of heavy GTK
| software is probably not a good idea
|
| GTK by itself is quite light, even GTK3. It's certainly
| lighter than the Java UX of Android.
| jchw wrote:
| I don't know what your definition of light is, but it just
| doesn't match mine, and I also actually contest the idea
| that it is necessarily "less light" than Android UI.
| They're pretty different beasts, and there's multiple
| dimensions to "lightweightness." What I do know is that GTK
| pulls in _quite a lot_ including a CSS engine. You can
| certainly do UI libraries that use a lot less cycles and
| RAM.
| qchris wrote:
| I'm not sure I've had that issue with Mobian--I definitely am
| able to receive phone calls while it's sleeping in the other
| room, so it's not like there's an inherent inability to push
| notifications during sleep. I think that using `libnotify-
| bin` is the recommended library for doing notifications at
| the moment, although I haven't tested it to see if it pops up
| during sleep.
|
| 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.
| jchw wrote:
| Phone calls and text messages are way different than push
| notifications. The modem is a separate chip on the device
| that can almost definitely wake up the CPU, and there is,
| to my knowledge, no such chip for fetching push
| notifications over the internet. Even if there was, you can
| verify by hand that apps like tdesktop don't support any
| kind of central push notification service from the
| operating system, so it would be impossible for the device
| to do anything special; it simply has to be awake for
| traditional apps to process push notifications.
|
| 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.)
| megous wrote:
| You can possibly use the modem itself for monitoring for
| notifications, even if the main SoC sleeps. And wake the
| main SoC up from the modem. It would only work over
| mobile data though.
| zozbot234 wrote:
| > generally the CPU has to wake up periodically to poll,
| and if you have many individual push services that would
| be inefficient.
|
| Even if you had many push services, waking up
| periodically and polling them all at the same time ought
| to be rather efficient.
| jchw wrote:
| Even if this is true, you still need to coordinate all of
| them to happen at once, so it doesn't obviate the need
| for an OS-level service to coordinate this at least.
| Waterfall wrote:
| It's been promising for years and under delivering. You could
| get all that with a cheapo phone that is given out free on
| prepaid.
| airstrike wrote:
| If I recall correctly, the last thread I saw on this, the
| biggest hurdle was the sheer size of the device. It looked like
| it was discovered in a time capsule from the 1990s
| RandomBacon wrote:
| One person's "con", another person's "pro".
| wott wrote:
| It's not a matter of contesting the race to thinness. Here,
| the stuff is as thick as _two_ not-especially-thin phones;
| it is reaching the realm of PDAs, except it hasn 't got the
| clamshell and the keyboard.
| mr_spothawk wrote:
| Excellent.
| paulcole wrote:
| You weren't kidding. They do a pretty good job of hiding
| photos that show the side view. But wow that thing is dummy
| thicc.
| gentleman11 wrote:
| Not mine. I need anki, authy, a calculator, a good podcast app,
| an audiobook app, a VPN, security/privacy, and then just a
| really long battery life.
|
| 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
| ocdtrekkie wrote:
| PinePhone has most of those, but if you're insisted on a
| specific app/brand, you are limiting yourself. For instance,
| Mobian comes with a 2FA app. Authy is a bad security choice
| anyways because you shouldn't send your 2FA tokens to a
| cloud.
| vngzs wrote:
| Yeah, I'm pretty far from being able to switch to a Linux
| phone without the ability to read TOTP tokens from YubiKeys.
| For apps that don't support hardware tokens, I store the TOTP
| seeds on a YubiKey, which prevents malware on the phone from
| being able to steal my seeds.
| kop316 wrote:
| The Pinephone can do that actually:
|
| 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)
| fosco wrote:
| >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?
| kop316 wrote:
| Well its not debugging, the functionality isn't there.
|
| https://gitlab.freedesktop.org/mobile-
| broadband/ModemManager...
|
| There's a start
| nt8r wrote:
| You can use ofono and mmsd on the Pinephone to get MMS
| working for both attachments and group chats:
| https://sr.ht/~anteater/mms-stack/
| kop316 wrote:
| To my knowledge, only Ubuntu Touch uses ofono and mmsd. But
| Ubuntu Touch doesn't support MMS for the Pinephone yet
| either (per their Gitlab).
| gentleman11 wrote:
| I'm a little jealous of the engineers who get to work on this
| project. It would be so exciting to build something like this
| from the ground up, improving it constantly. The challenge,
| scope, and meaning are compelling, no?
| akiselev wrote:
| I've worked on smartphone electronics and it's not as exciting
| as you think. I'm pretty sure they chose the i.MX8 because they
| couldn't source Snapdragons so they got a little luckier with
| NXP, but the vast majority of the engineering done on a
| smartphone is in firmware and software with absolutely shitty
| support from the manufacturer. Bug fixes that only get
| distributed to customers after they've ran into the bug and
| struggled with it for weeks (instead of just putting the bug
| fix into the BSP), no version control or historical view of
| vendor drivers or modified kernels, firmware that has "hello
| world" levels of polish, documentation that is only available
| under three levels of NDAs, and few open source projects to
| learn from for what are usually almost-but-not-quite bespoke
| PCBs. Worst of all, consumer hardware products can sell at such
| scale that it's worth it to keep an engineer working on a
| single bug for months at a time only to find out that it was a
| bug in vendor silicon all along - it is soul crushing. Silicon
| manufacturers have very little respect for software and it
| really makes the entire process a lot more painful than it
| should be.
|
| 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.
| solarkraft wrote:
| > Silicon manufacturers have very little respect for software
| and it really makes the entire process a lot more painful
| than it should be.
|
| Do you know why? In my eyes that would make them a crazy
| unattractive supplier.
| akiselev wrote:
| I don't know much about that side of the industry so this
| is only what I've gleamed from mentors and account managers
| at suppliers: silicon fabrication is extremely conservative
| and naturally monopolistic because of the sums of money
| involved and these two factors interact in weird ways. The
| gross margins on chips are 90%+ but because of the large
| amounts of upfront capital, they have to strike a balance
| between derisking the R&D and maximizing profit. Since it
| is so expensive, demand for specialized chips can only
| support so many customers per design which limits
| competition and redesigns are so expensive that clients are
| locked into their suppliers. The vendors know this and they
| know that hardware designs are locked in whereas customers
| have a lot more control over their software so when it
| comes to derisk the project, investment into software
| quality is _always_ the first to get cut to the bone.
| Afterwards, due to that derisking, most of their software
| engineers spend time chasing bugs in the barebones software
| and supporting customers so they never get to invest in the
| software after release before they have to move onto the
| next product.
|
| 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.
| ignoramous wrote:
| Sounds like the silicon fabrication industry is ripe for
| disruption ala Stripe / Monzo. May be, since you know so
| much, you should build one. :)
|
| 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].
|
| [0] https://www.amarisoft.com/about-us/
|
| [1] https://osmocom.org/projects/baseband
| akiselev wrote:
| I wish! I've actually looked into it and there's lots of
| interesting work in academia and garages on small scale,
| low cost silicon fab [1] as well as the electron
| microscopy necessary to do quality control [2]. Last I
| checked the state of the art was using regular
| microscopes with Texas Instruments digital micromirror
| devices from projectors with basic photoresist and
| etchant. The DMD reflects light from your light source
| onto the wafer with the resist and you can control the
| micromirrors like pixels to only reflect light at the
| pixels you want to expose the resist. The doping is
| doable with basic vapor deposition but alignment between
| steps is brutally hard and the doping requires a lot of
| tuning and environmental stability to get right so the
| feature limit is 1 micrometer at best.
|
| 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...
| wott wrote:
| I doesn't make a difference because in the industry they
| all are the same and always have been. Except when they are
| worse. :-/
| bravo22 wrote:
| I've been on silicon side. Because chips are rushed out the
| door and always behind schedule, and they expect large
| customers to make 2-3 product lines with it during the
| chip's lifetime.
| dkdk8283 wrote:
| Sounds more like writing open kernel drivers, except you get
| paid.
|
| Still aspiring to work on something challenging is healthy
| and I respect GP's sentiment!
| google234123 wrote:
| And NXP is generally considered a very good vendor to work
| with!
| wott wrote:
| Yes, only because the reference point is the average of all
| manufacturers :-)
|
| 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...
| akiselev wrote:
| I can't believe I forgot to mention the errata! A mentor
| got so pissed off at Qualcomm one time that he delayed
| the start of his next contract by a month so he could
| farm a list of professional electrical engineers working
| for companies that use Qualcomm chips and developed a
| relationship with many of them just to create a secret
| errata sharing network of EEs that were covered under
| Qualcomm's NDAs. Even a few lawyers at one of the biggest
| companies who got wind of the idea decided it was worth
| the risk.
|
| Sadly he passed away before he had the time to really get
| it off the ground.
| ChuckNorris89 wrote:
| I've been around the block in major, Top 10 silicone
| companies.
|
| 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.
| ndesaulniers wrote:
| > Top 10 silicone companies.
|
| Silicon, lest anyone think you were working in a
| different industry.
| m-ee wrote:
| Curious what helper apps you're using, I've always set my own
| DRC rules but have been mostly on the R&D side so it wasn't
| as critical
| akiselev wrote:
| It's been a while since I moved up the stack to frontend
| development so I don't remember most of them but the
| primary one was the Saturn PCB toolkit [1]. There was one
| that we used in place of Saturn PCB toolkit that was far
| easier to automate but I can't find it now. I wrote lots of
| custom scripts to turn Excel formulas into Altium rules and
| there were quite a few crappy WinForm apps from fabs.
|
| 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.
|
| [1] https://saturnpcb.com/pcb_toolkit/
| [deleted]
| zozbot234 wrote:
| > I'm pretty sure they chose the i.MX8 because they couldn't
| source Snapdragons
|
| 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.
| akiselev wrote:
| Back when it was Freescale, I don't remember their
| documentation being that much better than Qualcomm's. The
| software support sure was better at first but given the
| RaspberryPi community size, I think it'd be a wash -
| although I don't know when LibRem started development. The
| biggest difference I experienced was that you could
| download iMX documentation along with all the reference
| designs without breaking into a Freescale employee's house
| or proving to one of their account managers that you could
| sell millions of units.
| Waterfall wrote:
| This project feels like how the Pandora project was. It was
| expensive for it's time, promised to do cool things and
| then was in suspended animation for years while the world
| changed. Snapdragons got mainlined. Phones got cheaper.
| Other Linux phones that worked completely came out. They
| should have delayed it and just put in a mainlined
| snapdragon processor.
| fest wrote:
| Easier said than done. As of few years ago, Qualcomm
| wouldn'y really talk to you unless you can guarantee at
| least 100k unit purchase- which gets quite expensive fast
| at ~30-40$/pc for a mid range SoC.
|
| 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).
| mac01021 wrote:
| The battery life when idle is shown here to be 5 or 6 hours.
|
| 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?
| LawnGnome wrote:
| That's screen on, though, if you look at the title of the
| chart. That's probably no worse than my Pixel 3 (which is by no
| means an endurance athlete, but is probably fairly
| representative of the Android mass market).
|
| 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.
| boogies wrote:
| The pinephone recently got a 40% increase in idle battery life
| to ~100 hours with the modem off and ~24 with it on
| https://www.pine64.org/2020/07/15/july-updatepmos-ce-pre-ord...
| (control-f search for "crust"). I would hazard a guess that
| this might be portable to the Librem 5 (but maybe they already
| implemented it, IDK).
|
| Edit: but my two sibling comments now seem to have more useful
| information than this one.
| biktor_gj wrote:
| Crust runs in a RISC cpu inside the Allwinner chip, and it
| only works in that. I don't know if the NXP chip has a
| 'dedicated' core to manage the actual ARM cores, but all the
| work done in Crust won't be portable to the Librem, if it can
| be done, it'll have to be done from scratch
| cesarb wrote:
| The key is probably this sentence: "In the future, we are also
| planning to support suspend to RAM." That is, the CPU is never
| being fully powered off, only clocked down.
|
| 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.
| wott wrote:
| > The key is probably this sentence: "In the future, we are
| also planning to support suspend to RAM."
|
| 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.
| snvzz wrote:
| Madness. It should be priority #1 now that the phone calls
| are working.
| eptcyka wrote:
| It needs a full-stack integration to work properly, it's
| an immense amount of work. The Linux kernel is great at
| lots of things, but being good at scaling back power
| usage is not one of them. You'd want to be able to have
| timers that will wake the machine up form suspension that
| application developers can use and throttling of radios.
| The device has to be suspended, but you should still be
| able to receive calls. MacOS does this impressively well
| (try pinging your Macbook as it's slowly nodding off, and
| see the response time increase). Better still, you can
| ping a macbook over WiFi that's completely suspended -
| SSH and other services won't work, but the kernel will
| still be there and do some I/O - this requires some kind
| of a power-level aware system in the kernel that can
| coordinate with device drivers and have userspace
| interfaces for registering applications that might want
| to receive data when the machine should be suspended. The
| designwork required to achieve this with Linux and it's
| ecosystem is far more than the capable but small team at
| Librem can reasonably achieve, not because the team is
| small, but because this would require a lot of
| coordination between different upstreams.
| akiselev wrote:
| _> Should I expect the Librem 5 developers to be able to
| achieve the same thing before they ship Evergreen?_
|
| 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.
| [deleted]
| Waterfall wrote:
| This phone is an embarrassment. Petty mismanagement
| https://www.phoronix.com/scan.php?page=news_item&px=Zlatan-T... ,
| subpar products, and breakdowns like this are nice, but you know
| what's better? Getting a working phone then getting the behind
| the scenes look rather than 2 unfinished products. It has none of
| the charm of the n900, at least pinephone is much cheaper,
| although I don't see a point to a Linux phone when they're
| mainlining a bunch of snapdragons like the one in the s9, with
| full network support. Once postmarketOS succeeds there's little
| reason to get these Linux phone as devices, and the main reason
| was good support before postmarketOS ported Linux but the
| hardware is pretty bad. Poor hardware and poor software for a
| hefty price, a phone that when sold wasn't even functional and is
| still rough around the edges.
| LockAndLol wrote:
| These are the kind of breakdowns I'd like on every phone out
| there. If they were to publicly release a standardized battery
| testing procedure with a list of all hardware used for testing,
| the would make it much easier to compare battery life across
| phones on the market.
|
| Good job.
___________________________________________________________________
(page generated 2020-07-28 23:00 UTC)