Let's talk about safety of Pinephone
xnux.eu
xnux.eu
Am I misinterpreting this?
These battery management ICs will permanently shut down the battery off above a dangerous temperature threshold. Better to kill a battery than to risk a fire.
From the Pinephone wiki: "Battery: Lithium-ion, rated capacity 2800mAh (10.64Wh), typical capacity 3000mAh (11.40Wh) (nominally replaceable with any Samsung J7 form-factor battery)"
I guess they're sourcing unmarked Samsung compatible batteries which should be all protected, where should equals to 99.999%.
If that's the case, then there's no way malicious software or even firmware could damage it. The protection in those batteries is implemented hardware level; the chip contained in the cell will cut off its connection if it detects either an excessive discharge current (to avoid potential explosion), excessive voltage discharge (to avoid chemical degradation and subsequent charging attempts related dangers), excessive temperature (again to avoid explosion), excessive charging current (... explosion). They are all detected outside of system control, so no need for panic.
Also, there's no protection against excessive temperature in the battery protection circuit's specification, so not sure where you're taking your information from. It would be nice if people actually used the datasheets that are freely available, since Pinephone is mostly open HW, instead of proclaiming random generalities.
Last time I read about PinePhone, the topic was kill switches hardwired to chip enable pins that also make it impossible to sleep peripherals from main SoC. That was only “weird but okay”, but personally, with this discussions going, this phone and associated ROMs aren’t something I consider anymore.
Despite similarity in name they are very different beasts. I'm not all that afraid of a LiIon pack unless it's been sorely mistreated or is a huge EV pack or something. On the other hand I treat LiPos with the utmost respect and get them far away from anything at the first sign of bloating or accidental shorting.
Obviously, no pressure, but figured I'd express the interest
For longevity this is true, but even the while overcharging the risk of a fire isn't that high nowadays (from what I've seen close to 0 with cylindrical cells). Some pouch cells are even fine when punctured.
Of course I want these issues to be fixed to keep Pinephones working and AFAIK the batteries in the Pinephone are of an older model, so maybe they're a bit more dangerous. The author definitely has a point.
With current generation devices, once the battery is dead, it requires replacement even to use the device for an application which has constant power supply(e.g. external monitor), especially if it has become a spicy pillow and constant power supply means it can again become a spicy pillow[1].
[1]https://twitter.com/heavyinfo/status/1302310594423345152?s=2...
The protection circuitry on the battery pack is designed to protect the cell from charging and discharging situations that may damage the battery. You definitely want those protections in there.
There are after market batteries w/o battery management ICs like TI Gas Gauge, its up to device on whether it will accept a battery without such IC.
>that has nothing to do with whether the device runs without a battery. That’s just a design choice
I agree that just having a battery without IC doesn't guarantee that the device would function directly with an external voltage regulated power supply, but a device which accepts only the battery with specific IC makes it difficult or even impossible to run the device that way.
If you're marketing a phone where one of the advertised features is the ability to change the operating system, and the operating system is responsible for enforcing electrical safety, i don't really see how that's certifiable.
Radios are much more regulated.
http://files.pine64.org/doc/cert/PinePhone%20CE%20RED%20Cert...
Would be fun to see what of those articles are safety related, and what do testers test for actually.
Not really. It's not even that it's a pet peeve, just them pointing out that projects need to keep safety in mind.
The author even mentions that they have contributed to PinePhone software.
(not to mention they're just plain wrong about the battery/thermal not having hardware-level limits)
If they use the license wording to help get it across, well, I don't necessarily agree but as they state in the article:
> I'm trying to be a bit inflamatory here, to start the conversation.
> Software engineering does not put safety first
I'm 100% agreed.
If the conversation is
> The PinePhone has less quality control than Android/iOS
It's patently false
I would parse the article as the second, as it's referring to a specific phone throughout
And I concur about the second being patently false. I would guess that it has more overall tbh.
> It's patently false
PinePhone is just HW. Android/iOS is SW. Comparison doesn't make sense. Maybe compare PinePhone to Huawei Honor, or Xiaomi and their HW testing:
That's a strawman: author never compared to Android/iOS. What they did spell out,is that some of the code they found is unsafe (e.g. commented-out code to prevent false alerts, that was never being reimplemented in a safer way).
> C. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE APPLE SOFTWARE AND SERVICES ARE PROVIDED “AS IS” AND “AS AVAILABLE”, WITH ALL FAULTS AND WITHOUT WARRANTY OF ANY KIND
There are not many reasons not to use my kernel tree for Pinephone. I actually had reports from users that my multi-distro image that uses my kernel for 13 different pinephone distributions makes some distros run better.
I suspect that distro maintainers just think that pine64 community gitlab is somehow more official than any other pinephone kernel developer's tree on the internet, just from the name.
After giving Purism some money for their "Fund Your App"-thingy today I decided to hit your donation button with a small, but recurring donation, because you deserve it for all your work – even if, sadly, my favourite distribution (DanctNIX Mobile) does not use your kernel and I am too lazy to change that on my end.
Those are the safety measures protecting the PMIC, not the battery. Is that temperature cutoff even low enough to matter before the battery is on fire?
It isn't clear that the software protections ever mattered anyway. If the kernel crashes, or is just charging while turned off, I sure hope it's still designed to be completely safe, and not a sudden explosion risk.
Then PMIC operates independently from the kernel, and configuration even persists when powered off/during reboots.
HW is designed to be safe, but SW has to cooperate, including userspace. (some daemon that will help policing the whole device, based on many different inputs and by controling things that affect heat production - like preventing the user from setting backlight at max, limiting modem RF output to something that doesn't need huge amounts of power, etc. etc.)
It's a complicated area.
Why would you be running on battery while connected to the dock and an external monitor?! That seems like doing some math without thinking about the practical mechanics of being docked.
There should be nothing an end user can do without disassembling the phone that can make it catch fire. If there is, then someone will do it. And personally, I wouldn't think twice about connecting the HDMI without connecting the power, for five minutes, to get hold of some document.
I don't own a Pinephone, and from the looks of this debacle I never will. It doesn't seem that OSS is safe to run in safety-critical contexts.
Sound rather limited, almost stupid.
OSS runs in various safety critical software, FreeRTOS, also Linux and various other projects run in very critical environments, far more critical than a smartphone.
https://scholar.google.at/scholar?q=open+source+software+in+... https://scholar.google.at/scholar?q=linux+in+safety-critical...
You know that something is OSS allows letting anybody check this out in the first place, do you really think a proprietary phone is safe from this? There are many reports about iPhones and other smart phones catching fire each year.
I wouldn't trust something as overly-complex as Linux to prevent fires anyways.
In fact it's just the common protection circuit that just cares about over/under voltage and over-current conditions (mostly just a short, because the cuttoff current limit is 6-8A and battery's max recommended sustained current is 1.4A). So you can overload the battery 3-4x for however long you want, and that circuit will do nothing.
That said, as the fix seems to be rather trivial, distributions should just check and ship a new kernel if necessary.
It wouldn't charge so we turned off thermal regulation
Jesus effing Christ.
I recall once a co worker said they'd never use Android again since it froze when trying to call 911.
Gives Apple more ammo in their fight against Epic, users expect their phones to work , which Apple can't guarantee if anyone can run whatever binary they find.