Me too. I’ve already had one where I came back to find the phone shut down (don’t know whether it involuntarily died or voluntarily shut down due to low power).
1 Like
That is I question I carry around in my head for some days.
- Does the L5 ccurrently shutdown intentionally when energy gets low?
- Do we have to expect hard power offs because the L5 currently doesn’t know itself how much energy is left?
- How is the targeted behavior?
For comparison. My Laptop does beep sounds when energy gets low. After a couple of beeps I think it goes into some power saving state IIRC, instead of shutting down. My android shows a dialog when 10% energy is left. By 5% percent or so it shows another dialog, telling Mr its going to shut down. It does not shutdown immediately but after another while. After charging and power all apps are in the same status they where before. Probably all process data was saved in storage meanwhile.
You can estimate the level of charge using the voltage. A Li-Ion battery is empty at 3.6V and fully charged at 4.2V. From the quoted values you can see that the battery is in fact almost empty and not at 59% charge level.
1 Like
No, it dies 'cause it run out of gas.
But the problem will be solved in few days, based on this:
To clarify - it does turn off automatically on low battery; the issue is that without the kernel fixes it may not realize that the battery is low before it’s too late to act.
3 Likes
So running a simple script like the following you’d get the true battery level …
#!/bin/bash
volt1=$(upower -d | grep -m 1 voltage)
volt2="${volt1//voltage:}"
volt3="${volt2//V}"
awk “BEGIN {print ($volt3-3.6)/0.6*100}”
Nope, this just workarounds one issue (upowerd not taking changed charge_full value into account), but there are several more. You really need a fixed kernel to get proper value (at which point you’ll likely not even notice the charge_full bug anymore).
Ah wait, it uses voltages! 
Then yeah, it’s kinda real, but not really accurate under load.
The fixed kernel should migrate tomorrow: https://master.pureos.net/migrations/excuse/cae9e9d1-5e41-4b0a-bfa4-3bb4f2eb707d
2 Likes
That’s what I’ve noticed. I’ve had both - sometimes there is an orderly shutdown and sometimes it has just died. It is not only the kernel that leaves it before it’s too late to act, the user also. 
Keenly awaiting that update …
Is that the kernel update that just arrived today?
I guess you can try and see if that helps
In fact, one way I can test is to let the phone drain for a while, note the displayed battery level, restart the phone, and check if the displayed battery level is still the same or much lower. (Up to now, it has always come back lower than expected.)
I’ll test and report back here.
Edit: Right now, while charging, the display indicates 55% and the voltage is at 3.99, so that would seem to be fairly accurate (based on what @eugenr said above).
2 Likes
Yup! Depending on how much charged the battery was when you first booted it you may need a charging cycle or two to make it accurate, but since then it should work pretty well 
8 Likes
This update seemed to be a bit untidy.
I booted up this morning, it gave me a notification that updates are available, I clicked the notification and it launched some kind of software updater. On the screen it said “Restart & Update”. I think I managed to click that but thereafter the phone became completely unresponsive (touching things on the screen had no effect, time ceased moving forward on the on-screen clock, couldn’t ping or ssh in).
I had to force a reboot. On reboot, there were messages about installing updates, eventually a notification telling me that updates had been installed, and everything was then seemingly normal.
So: overall, no harm done, just untidy.
Does this mean that I should install updates from the shell for now?
Something else wrong?
Fun challenge: What happens if you change the battery?
For the first time, as part of my program of progressively testing everything I can think of, I changed the battery (and I did that with the phone booted i.e. hot swap of fully charged battery for nearly empty battery).
It took a minute or two for it to recognise what the hell I had done - first there was no battery, so LED says charging error (fair enough I suppose), then I inserted a battery, LED says charging but Settings / Power says not, then soon Settings / Power says charging but percentage is not right, then Settings / Power says charging and percentage 99% (close enough).
So that all seems to be working reasonably but is there anything that I should be aware of? am I likely to encounter any problems with this workflow?
Update: Partially answering my own question: No, seems to get confused, with the percentage going backwards even though on charge. A reboot got everything back in synch, which is not ideal, since the point of hot swap is not having to reboot. Will have to try this again later on in order to confirm the behaviour.
1 Like
Same thing - the calibration gets reset, so the gauge uses voltage to approximate the capacity. Then it starts to count the current going from/to the battery and with time starts to take the coulomb counter estimation more into account than voltage for more accurate readings.
Since upowerd isn’t very eager in updating its charge_full reading when it changes, you may want to run sudo systemctl restart upower after changing the battery at the moment so the percentage in UI stays sensible. cat /sys/class/power_supply/max170xx_battery/capacity will always give you the reading straight from the gauge.
[edit] Ah, it just came into my mind that I’m not entirely sure whether the gauge will get correctly reconfigured by the kernel after a battery hot-swap (you may need to reload the kernel module for it to happen). I’ll have to try it myself and see what happens
4 Likes
Big improvement in accuracy since the kernel update.
1 Like
not related to L5 … but will any of the future PureOS updates translate to me being able to have an accurate charge/discharge rate of my UPS ? … in the GUI-front-end i mean (GNOME/‘Power-Statistics’ app)
currently not very interesting for APC UPSs …
This is going to depend on what Debian/GNOME does. I’m not aware of any effort within Purism to support UPS.