Let's talk about safety of Pinephone
#3
(09-18-2020, 10:34 PM)barray Wrote: Using the information in the Wiki as a point of reference: https://wiki.pine64.org/index.php/PinePhone

It would be good if you could point to the sections of code you are specifically concerned about...

> The battery includes a protection circuit that isolates it in a number of fault conditions, including if it is discharged too far.

So without any software, the battery should try to protect itself. But this of course cannot be relied upon 100%. Checkout this for more: https://wiki.pine64.org/images/0/04/Pine...2-2750.pdf

> Pinephone's SoC is quite bare when it comes to software/firmware (that's why FOSS enthusiasts like it, no blobs, you know!). This
> has a dark side, too. All the safety critical parts are written (or rather were not written, yet) by some random people on The Internet.

You either rely on some random people on the internet whose code you can review, or some random engineers whose code you cannot review. You might think that code that is written by some company and reused many times is more robust, but actually it simply means people are less likely to re-review it and bugs can creep in.

> 1. Pinephone battery uses a 3 kOhm NTC to monitor the temperature. Power management chip in Pinephone expects 10 kOhm
> variant by default. So early on, when the times were adventurous, someone decided to patch the kernel to disable battery thermal
> monitoring completely. Quick and dirty fix for Pinephone not charging due to false under-temperature alarm.

The battery itself has thermal protection, but the power controller does too: http://files.pine64.org/doc/datasheet/pi...t_V1.0.pdf

> Now guess what… up to now, all distributions run with battery temperature sensing and regulation disabled. If you're unlucky and use
> a dud battery that will heat up more easilly during fast charging, you can burn down your house.

As you say, this should be enabled by default and manually enabled for early adopter devices.

> 2. And you know what, I also suspect that all distros fast charge all the way through the constant-current phase of charging, by
> default. Other than contributing to making the above mentioned house burning scenario more likely to happen, this also contributes to
> overheating issues on Pinephone.

Again, battery protections and the power controller:

> The  AXP803  battery  charger  solution  has  two  charging  modes  that  it  can  be  in.  It  is  specifically  designed  to charge  Li  Ion
> or  Li  Polymer  type  batteries.  The  two  modes  are  1)  Pre  Charge  Mode and 2)  Fast  Charge  Mode. The delineation between
> these two modes is based on the battery voltage level of VTRKL which is set at 3.0V.  When  battery  voltage,  VBATSENSE  is 
> between  0V to  3.0V (VTRKL),  the  charger  is  in  Pre  Charge  Mode  where charging current is limited to a value of ITRKL (10% of
> ICHRG, default value is 120mA). This mode of operation is intended to  prevent  damage  to  the  battery. Once  VBATSENSE≥
> VTRKL,  the  charger will  enter  Fast  Charge  Mode.

> 3. Another thing. PMIC has an emergency thermal shutdown feature, for a situation when the chip itself overheats. It's disabled by
> default. It's also not well documented.

This should just be a case of setting registers if this is the case. There is also the thermal shutdown of the CPU which would greatly reduce the load too in such a condition.

> 4. And, another one! Battery is rated for some sustained continuous discharge current (0.5C, 1500mA, ~6W). I guess it overheats if it
> is dicharged at a significanlty faster rate for prolonged periods of time, and potentially becomes a safety hazard again. Maybe again
> only if it's a suboptimal piece that passed QA.

Are the batteries not 3000mAH? Not 1500mAH? The peak current can exceed the maximum continuous discharge current for short bursts, so as long as this isn't maintained for too long, it would be fine.

Battery protection circuit doesn't protect against anything I wrote about. It doesn't care about heat. And it's independent of the software anyway, so it doesn't relate to my core point about safety as an issue of interaction between SW and HW.

Battery protections in PMIC you cite are for something else than to regulate fast charging. These will only help at the beginning of charging, and perhaps if battery seems to not be getting charged for way too long. Meanwhile the phone happily fast charges from 0 to whenever CV phase begins, without regards to temperature.

There's no automatic thermal shutdown of the CPU, it's done by Linux and it's configurable, and depends on how well the thermal sensor driver is implemented or whatever kernel config you're using. Some people still report that the sensor gives them nonsensically high values. I don't think this was investigated.

Yes batteries are 3000mAH, so 0.5C limit means max 1500mA continuous discharge current (5-6W). Those values I measured are not peak. 6.5W is idle minimum with dock connected to monitor, no CPU and no GPU use, no modem use and wifi not transmitting. There probably needs to be some userspace daemon that monitors thermals across the phone, and limits things when things are getting out of hand and maybe warns the user that the phone needs to be shut down soon if temperatures are still out of hand after automatic actions to reduce the thermal output of various components. (something like the one implemented in the modem's userspace)

It's great that code is open, but someone still needs to know there are issues, fix the issues and actually verify the safety features work and not just toggle some registers and call it a day. Company that does both SW and HW has motivation to make both work safely together, because they're potentially liable. Will some one or two person Linux distro project throwing together bunch of preexisting software mostly focusing on user facing features and prominent bugs work on the issues I presented and do a bit more comprehensive safety testing? I'm afraid not.

There are now distros that got significant financial contribution from pinephone sales. So someone somewhere has resources to spare on safety on the SW side. They should do so.
my website: https://xnux.eu
  Reply


Messages In This Thread
Let's talk about safety of Pinephone - by megous - 09-18-2020, 04:43 PM
RE: Let's talk about safety of Pinephone - by megous - 09-19-2020, 08:53 AM
Let's talk about safety of Pinephone - by eKeith - 09-20-2020, 08:11 AM

Possibly Related Threads…
Thread Author Replies Views Last Post
  PinePhone - boot from microSD laserpyramid 5 299 03-06-2024, 06:37 PM
Last Post: aular
  Are you using the Pinephone as your daily driver? jro 157 105,102 02-18-2024, 11:33 PM
Last Post: aular
  2020 PinePhone Manjaro CE EU for sale, name your price astrojuanlu 7 1,524 02-14-2024, 04:51 PM
Last Post: astrojuanlu
  pinephone is not bootble for the box. ijij 1 461 01-19-2024, 01:29 PM
Last Post: fxc
  Multiple issues with the Pinephone MTXP 12 1,938 12-28-2023, 07:55 AM
Last Post: MTXP
  pinephone repair shop shengchieh 0 382 12-26-2023, 02:42 PM
Last Post: shengchieh
  sudo nano file saving pinephone beta edition CharlesGnarley 4 1,479 12-22-2023, 03:44 PM
Last Post: Kevin Kofler
  Can't get Mobian on PinePhone to recognise USB-C docking bar duncan_bayne 9 6,601 12-04-2023, 02:14 AM
Last Post: Peter Gamma
  Pinephone not booting, always vibrating alexander12 7 4,668 11-22-2023, 06:46 PM
Last Post: Scary Guy
  Pinephone on Verizon chachi 3 992 10-09-2023, 11:26 AM
Last Post: alaraajavamma

Forum Jump:


Users browsing this thread: 1 Guest(s)