
Librem 5 Phone Dogwood Thermals and Battery Life - Stephen304
https://puri.sm/posts/dogwood-thermals-and-battery-life/
======
gentleman11
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
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
> 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
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
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/](https://www.amarisoft.com/about-us/)

[1]
[https://osmocom.org/projects/baseband](https://osmocom.org/projects/baseband)

~~~
akiselev
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/](http://sam.zeloof.xyz/category/semiconductor/)

[2] [http://sam.zeloof.xyz/garage-electron-microscopy-first-
image...](http://sam.zeloof.xyz/garage-electron-microscopy-first-images/)

~~~
CamperBob2
Some very interesting work there, reminds me of Ben Krasnow's lair. You guys
should hang out!

I thought the voiceover video for the SEM lithography experiment worked really
well ( [https://youtu.be/SB94rQtKlKI](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...?

------
mac01021
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?

~~~
boogies
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...](https://www.pine64.org/2020/07/15/july-updatepmos-
ce-pre-orders-and-new-pinephone-version/) (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.

~~~
seba_dos1
Crust is, simplifying a bit, just something that enables suspend to RAM on
Allwinner platforms. From what I know you don't need anything like that on
i.MX8MQ, since the SoC and PMIC will already take care of what's needed there
by themselves.

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.

------
LockAndLol
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.

------
mikece
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.

~~~
kop316
The Pinephone can do that actually:

[https://wiki.mobian-project.org/doku.php?id=pinephone](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](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
>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?

~~~
nt8r
What have you tried? Things should "just work" if you install ofono and MMSd.
There are more details (urls, which forks are involved) at
[https://sr.ht/~anteater/mms-stack/](https://sr.ht/~anteater/mms-stack/)

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.

~~~
fosco
I have not even purchased yet, I think I will purchase in a couple months I've
just been holding out.

I am very excited to purchase, use and tinker with the Pinephone

------
retpirato
Does the phone work on this yet? That's the most important thing, otherwise
it's just a tiny tablet. How will connecting it with a carrier work?

------
gibsonhouse
Is it easier at this point to try and make Android secure?

~~~
ta17711771
Yes. GrapheneOS is pursuing/accomplishing this.

AOSP is one of the most secure consumer OS around right now, surprisingly.

------
Waterfall
This phone is an embarrassment. Petty mismanagement
[https://www.phoronix.com/scan.php?page=news_item&px=Zlatan-T...](https://www.phoronix.com/scan.php?page=news_item&px=Zlatan-
Todoric-Interview) , 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.

~~~
Townley
You’re not wrong that the project has had issues and unforced errors. I’ve
felt similar disappointment at the slow progress, misleading statements, and
product limitations.

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.

~~~
Waterfall
I would like to think that pine and purism had some effect on the mainlining,
but project treble for Google had been thought of separately. I won't buy
their hardware at this rate, but I hope they'll have a good mark on the Linux
phone.

