[BH edition] Will the battery always drain because of a HW issue?

[ashleymills]

According to the braveheart v1.1 errata in the section entitled "Excess power usage while driving VBUS" it says:

" the PMIC continues to draw power from the USB port, and this doubles the drain on the battery (since the whole phone is being powered by the USB OTG boost regulator). This could be fixed by populating R1300."

My naive reading of this is that without populating R1300, the battery is always going to get double the drain.

I'd like an honest answer therefore to the following question:

1. Can we expect normal battery performance from the v1.1 BH edition phones at any point, i.e is there a software fix, or is this unfixable?

Much appreciate being part of the BH cohort and don't regret my decision, but would like to know if the phone will ever have a practical battery life

Cheers

Ashley

[wibble]

I think the 'double' is referring to the power lost due to conversion efficiency as power from the battery is going through 2 dc-dc converters rather than 1, so being 80% efficient instead of 90% (example values in the right ballpark). While not ideal, this is nowhere near as bad as doubling the total power consumption. I could be wrong here though...

The good news is that battery life isn't going to get any worse, and there's scope to improve it with software updates. I don't think it'll ever be as good as later hardware versions though - they should get fixes for things that can't be worked around in software. 

Until recently none of the distros have been suspending the processor, so the phone is effectively always on - obviously not great for the battery. s2idle is starting to appear (in the recent debian-phosh release for example) and seems to increase idle battery life to ~12hrs. I was worried that the AP_READY and RI errors would make being a phone incompatible with suspending the cpu, but the devs seem confident they can work around AP_READY with s2idle (currently mostly working, but sometimes breaks when answering a call) and that CRUST will eventually allow the modem to trigger wake from full suspend. There are other power savings that can probably be made too, some easier than others. How far this will get us, and how soon, is probably an open question. I hope there's scope for reducing the power draw of the Quectel modem.

[ashleymills]

I think the 'double' is referring to the power lost due to conversion efficiency as power from the battery is going through 2 dc-dc converters rather than 1, so being 80% efficient instead of 90% (example values in the right ballpark). While not ideal, this is nowhere near as bad as doubling the total power consumption. I could be wrong here though...

The good news is that battery life isn't going to get any worse, and there's scope to improve it with software updates. I don't think it'll ever be as good as later hardware versions though - they should get fixes for things that can't be worked around in software. 

Until recently none of the distros have been suspending the processor, so the phone is effectively always on - obviously not great for the battery. s2idle is starting to appear (in the recent debian-phosh release for example) and seems to increase idle battery life to ~12hrs. I was worried that the AP_READY and RI errors would make being a phone incompatible with suspending the cpu, but the devs seem confident they can work around AP_READY with s2idle (currently mostly working, but sometimes breaks when answering a call) and that CRUST will eventually allow the modem to trigger wake from full suspend. There are other power savings that can probably be made too, some easier than others. How far this will get us, and how soon,  is probably an open question. I hope there's scope for reducing the power draw of the Quectel modem.

Thanks for the response, if people are starting to see real world battery times of 12hr that sounds reasonable. I'll have to give it a try.