Let's talk about safety of Pinephone

[SwordfishII]

<snip the ignorance>

It's amazing you want someone to have their PinePhone explode before you will believe there is an issue. Fortunately, I think other people have more sense and understand the technical issues here better than you do and appreciate the heads-up that's been provided.

It's amazing that you think phones can be made to explode and it is all prevented through software with zero hardware safety.

It's like that decades old rumour of bios and PSU attacking viruses that cause a computer to catch on fire....which doesn't exist.

Keep living in fairy tale land

[lot378]

<snip more lunacy -- as if doubling-down on the nonsense was not enough>

The technical issues with PinePhone have been written in a straight forward, open and easy way to understand.

The community (that means users, distro makers, contributors of any type) needed to be made aware of the issue that their PinePhone can overheat, that it presently lacks all the safeguards that are necessary (and in one case one a safeguard was actually removed from the kernel). Without all those safeguards that control the response to conditions in the battery, that optimise the usage of the battery by devices to limit drawdown on the battery it's like rolling the dice and hoping that nothing bad happens. Until some work is done, that is the present situation of the PinePhone.

Each user needed to be aware and acknowledge that PinePhone is pretty much experimental hardware, with flaws included.

There is no "fairy tale", no "fearmongering" but clearly there is certainly some trolling/manipulation going on but it's not by the people that care what happens to the PinePhone and it's community of users. Being complacent and/or ignorant serves only as a distraction and undermines attention where it's needed.

[evilbunny]

Each user needed to be aware and acknowledge that PinePhone is pretty much experimental hardware, with flaws included.

There is such a notice on the shop page for the pine phone.

[wibble]

Each user needed to be aware and acknowledge that PinePhone is pretty much experimental hardware, with flaws included.

There is such a notice on the shop page for the pine phone.

There is indeed. Unfortunately a subset of customers either didn't read it, or misunderstood it.

This effectively mean that while core functionality of the PinePhone – such as telephone calls, SMS messages, LTE, GPS, GPU acceleration, etc. – is operational, it is also an ongoing effort, and thus the device cannot be considered as a consumer-ready product.

I can understand someone who hasn't been keeping track of development seeing this as meaning everything works out of the box but the experience needing some polish, rather than that the underlying hardware works (but may still have bugs to be fixed in later board revisions) but that software support for some parts is not yet in place and others are currently unreliable. Make it clearer and the only customers lost will be those who would have been dissatisfied.

[z4v4l]

@megous how about the PineTab battery? is it strong enough for dealing with discharge rate in the cases, where the Pinphone's one isn't? HDMI system on, CPU loaded etc?

[as400]

This framework may be the answer to the problems described in this topic:

https://lkml.org/lkml/2020/10/6/324

[LinAdmin2]

This framework may be the answer to the problems described in this topic:

https://lkml.org/lkml/2020/10/6/324

Interesting technical details, but not a solution to this problem.

[as400]

So what would be ?

[wibble]

This framework may be the answer to the problems described in this topic:

https://lkml.org/lkml/2020/10/6/324

Interesting technical details, but not a solution to this problem.

Given that 'this problem' is actually several problems there is no single solution. This is a potential long term solution to problem part 4 that Megous identified - the limit on battery discharge rate being lower than the potential power consumption of the device. While it mostly talks about power usage in terms of its relation to temperature, it is equally applicable to how much is being drawn from the power supply.

[Alho]

Given that 'this problem' is actually several problems there is no single solution. This is a potential long term solution to problem part 4 that Megous identified - the limit on battery discharge rate being lower than the potential power consumption of the device. While it mostly talks about power usage in terms of its relation to temperature, it is equally applicable to how much is being drawn from the power supply.

There is no overheating problem here at all. According to the conventional performance tests of the battery,
the battery can be discharged with a 1C load - and should last at least 54 mins.

I doubt that we can easily put an 1C load to the battery (2.8A) in the phone.

The same performance tests also indicate that the battery can be charged with 1C
which should give it a full charge (0-100% in less than 2.5 hours.

That said, using 1C may wear the battery down faster than using the usual 0.5C
but there is no safety risk involved.