InfiniTimeOrg / InfiniTime

Firmware for Pinetime smartwatch written in C++ and based on FreeRTOS
GNU General Public License v3.0
2.63k stars 902 forks source link

Increased battery usage in 1.14.0 #1997

Closed lucaswerkmeister closed 1 month ago

lucaswerkmeister commented 4 months ago

Verification

Introduce the issue

My PineTime’s battery seems to be depleting significantly faster since I upgraded it to InfiniTime 1.14.0 around 12:50 on 30 January (shortly after F-Droid updated my GadgetBridge to 0.78.0, which had been blocking the firmware upgrade before): Screenshot_20240201-221350 (I’m not sure what that other brief spike on the 27th was – it felt like the watch hadn’t actually charged much. Hopefully unrelated, anyway; the main point of the screenshot is the changed slope during the longer discharge periods.)

I’ll see if this keeps up over the next few days, and then probably try a downgrade to 1.13.0 to check whether that restores the old battery lifetime. But I figured I’d let y’all know that there might be an issue already.

Preferred solution

No response

Version

1.14.0

lucaswerkmeister commented 4 months ago

This is still anecdotal speculation, but a few times since the firmware upgrade I’ve gotten a notification displayed and was unable to do anything – the watch didn’t seem to respond to touch inputs. If it somehow ended up in an infinite loop or some other kind of 100% CPU usage, that would explain both the unresponsiveness and the high battery usage to me.

On the other hand, most of the time the watch is responsive (despite the battery seeming to deplete at a fairly constant rate in that graph), and when it’s unresponsive, it’s not noticeably warm to the touch. So maybe it’s not that after all.

I’ll probably try going back to 1.13.0 tomorrow.

lucaswerkmeister commented 4 months ago

Yup, it’s definitely improved again since I went back to 1.13.0 around 16:49 on February 3rd. Screenshot_20240205-223306

I suppose I should also try to detail here how I use my PineTime, though it’s a bit tricky since I don’t know anyone else to compare it to. It’s connected to my phone via GadgetBridge (as you can see), and shows notifications. Wake mode is Raise Wrist, and in 1.14.0 I also checked Lower Wrist. Brightness usually kept at lowest. Overnight I put it in “sleep” mode (blue moon icon; you can see the flat segments on the battery graph), otherwise it’s usually in “active” mode (green vibrating bell icon), sometimes in “do not disturb” mode (red struck-through bell icon).

I might try to build the firmware locally and see if I can git bisect the issue – Git claims it would take around 5 steps, which should be doable.

Rathmox commented 4 months ago

It's more battery reading that is worse. I litterally kept my watch today for 11 hours at 00% battery, because it's just miscalculated

But yes, with this issue, I can get to 0% in 2 days, while it took 1 week on 1.13.0

FintasticMan commented 4 months ago

The calculation hasn't changed since we improved it in 1.12. When we did that, we made sure to err on the side of caution, so the percentage might be slightly lower than the actual percentage. We did that because it's not great to let the battery fully deplete, so users charging before it dies is quite good.

Regarding worse battery life: I don't think we made any changes that would make battery life worse... We even found that having lower to sleep enabled improved battery life because the screen is asleep for longer. If you could bisect to find the commit that made things worse, that would be much appreciated!

Rathmox commented 4 months ago

I don't know how to read code for that

Hegz commented 4 months ago

I noticed that I would have the soft lock as decribed in the second post, as well as increased battery drain when using the "raise wrist / lower wrist" wake options.

Since returning to "shake wake" I haven't noticed either issue.

Rathmox commented 4 months ago

I have the Raise wrist / Lower wrist

KaffeinatedKat commented 4 months ago

It's more battery reading that is worse. I litterally kept my watch today for 11 hours at 00% battery, because it's just miscalculated

But yes, with this issue, I can get to 0% in 2 days, while it took 1 week on 1.13.0

mine did this the other day. I was leaving for work and I noticed that the battery was almost 0%, but had no time to take it off and put it on the charger. It suspiciously never died during my shift. When I got home 9 hours later the watch was still on at 0%

AyoungDukie commented 4 months ago

I also seemed to reduce battery usage switching back to shake-to-wake from raise+lower options. Could out be related to how the sensors are checked, potentially?

lucaswerkmeister commented 4 months ago

I think it must indeed be related to the wake-up options. I’m now back on 1.14.0, but with only “raise wrist” enabled, and the battery is behaving great again. (The screen seems a bit harder to wake up, but on the whole I think I’d rather have a slightly harder to wake up watch with great battery life than a watch that turns the screen on much more often and has to be recharged every two days.)

By the way – I ultimately didn’t get very far with the bisect just because it takes so long to decide whether each commit is “good” or “bad”, but kudos to whoever set up the docker build process, that worked great for me.

lucaswerkmeister commented 1 month ago

Closing, it doesn’t sound like there was a real issue after all other than the wake-up options being a tad confusing.