Let's talk about safety of Pinephone
#16
(10-02-2020, 08:48 PM)SwordfishII Wrote:
(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.

I have seen this exact site posted on a number of places and came to many off the same conclusions you did. 

The site is very "fear-mongory." I am eagerly awaiting the blog entries about how planes can crash, heart attacks happen, and we can die tomorrow as well. Hardware is never infallible. People are never infallible.

If there is real concern use a slow charger, and don't charge while using convergence which doesn't work yet anyway. Temps and risk stay low.

At least for me once the pine keyboard is out, the phone will always be stand alone, unless i am using it to watch a movie or something on a tv.
? So instead of attacking his arguments, you're calling him "fear-mongory"? You do know he's the guy that did all of this:


  • Collecting information about PinePhone's dri­ver status, what's mis­sing, known issues, and how to use the PinePhone hardware from Linux on this website.
  • He's been designing and testing audio codec routing setup for voice calling and prepared a sound „card“ controls documentati­on for A64 codec driver. He also wrote voice call audio routing setup app.
  • He's implementing GC2145 (front camera) driver (basics are working now).
  • He's maintaining a Linux kernel tree with the collection of the latest patches from all around the internet that are relevant to PP + his own driver work.
  • He's providing easy to use binary builds for his Linux kernel tree
  • He's implemented support for multiple cameras to the sun6i-csi driver, so that PP kernel can support multiple cameras.
  • He's implemented optimizati­ons for u-boot for faster boot times (DDR support and DMA support for eMMC/SD drivers in u-boot), dcache support for aarch64 version of SPL, and many other smaller improvements.
  • He wrote a specialized bootloader for extremely fast boot times. Typical boot times are ~50–100ms baseline + load times for images. For eMMC it's 85–88 MiB/s, for uSD it's 24MiB/s. So for a typical 12MiB Linux Image, the total boot time from eMMC is ~230ms.
  • He's helping with getting PinePhone supported in mainline Linux. Basic support for 1.0 and 1.1. Support for LCD.
  • He wrote patches to improve battery capacity reporting and enable charging to 4.35V.



The reason this keeps appearing, is that nobody has ever talked about the pinephone's safety before and we should definitely make it a priority instead of dismissing it as an extra.
  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 TimotheeLF - 10-03-2020, 02:19 PM
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,083 02-18-2024, 11:33 PM
Last Post: aular
  2020 PinePhone Manjaro CE EU for sale, name your price astrojuanlu 7 1,523 02-14-2024, 04:51 PM
Last Post: astrojuanlu
  pinephone is not bootble for the box. ijij 1 459 01-19-2024, 01:29 PM
Last Post: fxc
  Multiple issues with the Pinephone MTXP 12 1,937 12-28-2023, 07:55 AM
Last Post: MTXP
  pinephone repair shop shengchieh 0 381 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,600 12-04-2023, 02:14 AM
Last Post: Peter Gamma
  Pinephone not booting, always vibrating alexander12 7 4,667 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)