See UPERFECT X Mini lapdock works with Librem 5
(similar symptoms as “check” and the post after it gives the “fix”)
2 Likes
The patch?
2 Likes
Some advanced approach/direction (if and when needed) of external Librem 5 battery recalibration is already shown here: Bought broken batteries for Librem 5.
EDIT: @irvinewade, I’m anyway quite sure that you already provided solution here.
I’ve applied the “fix” some days ago. But last night, the unused L5 slowly drained the energy and then lost in the last five minutes around 30% of its energy. See picture. Why?
Because of some do-not-match numbers? In short, if your Librem 5 turns off when you take its BPP-L503 battery out this means that you are either using wrong cable to charge this battery or even that you are using wrong power supply (or both) there. If and when you use reliable charging equipment please follow this:
Now turn off your Librem 5 with: sudo systemctl poweroff, insert BPP-L503 battery back into its slot and wait until red LED light off, at phone consumption between 0.08A-0.09A (before this procedure you can still use and charge your phone to almost full). From there you might proceed as you think that suits there better (but I’ll disconnect power supply and power on Librem 5 normally). There are some other commands that I use but: upower -d should do (check/note this output before, when battery out, and after booting your phone back again:
@guru , and this below screenshot shows correctly calibrated battery (and I think that I know how to get there) under PureOS here related output:
There are two things at play there - gauge calibration and its configuration.
The kernel is supposed to automatically configure the gauge with correct values for a given hardware revision if it’s uninitialized, but there are cases where you may end up with incorrect ones being used (for example, if you use boot current versions of Jumpdrive as the first thing after taking the battery out and don’t take it out ever again).
To easily check whether your gauge configuration is right:
purism@evergreen:~$ cat /sys/class/power_supply/max170xx_battery/charge_full_design
4199160
purism@dogwood:~$ cat /sys/class/power_supply/max170xx_battery/charge_full_design
3400000
purism@birch:~$ cat /sys/class/power_supply/max170xx_battery/charge_full_design
2000000
(Chestnut value is the same as Birch)
So that’s the first thing to check. The other thing is that the gauge uses plenty of heuristics in order to calibrate itself and make its readings more accurate. Sometimes this calibration may end up being off, which can be further amplified by certain usage patterns.
In any case, the simplest way to reset both gauge configuration and calibration is to turn the phone off and take the battery out for a moment. Put it back in and you’ll end up with a reconfigured gauge with no calibration, so then give it a chance to learn about your battery for a full charge cycle or two - and then avoid taking your battery out to not reset calibration data again.
If sudden race-to-0 occurs often despite of letting the gauge calibrate for a while, it may be a sign of an aging battery.
2 Likes
@guru, today I have decided to share instruction that will help you, your OS and in particular your Librem 5 battery. Connect power supply of your trust to the Librem 5, remove BPP-L503 battery, execute: upower -d within still opened Terminal, skim this output and execute: sudo systemctl poweroff. Wait for PureOS to shut down your device, insert BPP-L503 battery back into its Librem 5 slot and turn/boot on your Librem 5 again. Read/check if upower -d tells you the truth now.
Today I’m not posting any upower -d screenshots before and after …, rather outputs for comparison (but you are welcomed to do so, up to your own goodwill). energy-full and energy-full-design values are the very same now?
EDIT: Final adjustment of the BPP-L503 battery calibration (through Librem 5 own HW/SW) would involve:
Now wait until red LED light turns off before booting your Librem 5 into PureOS GUI again.
EDIT II: In order to settle down, repeat above procedure until you get to the point that you boot back into 100% of battery capacity and get there real (useful) capacity (energy-full at almost 4.20V) values (another phone battery output, correct/precise upower -d output, shown here):
EDIT III: sudo systemctl reboot needed as final step to get … under still having power supply/bank connected there. Now I can go to sleep well.
Another BPP-L503 battery in process of being trickle recharged (inside of the Librem 5) to 100% of its real capacity (at 4.20V). @guru do you want that I post related screenshot (when this “job” done) for comparison of another Librem 5 battery (within another phone) energy-full value, from upower -d, as well?
I did what you (@dos) adviced and after charging to full (red LED off and 100%) upower-d shows:
Device: /org/freedesktop/UPower/devices/line_power_tps6598x_source_psy_0_003f
native-path: tps6598x-source-psy-0-003f
power supply: yes
updated: Wed 25 Jan 2023 02:04:16 PM CET (63 seconds ago)
has history: no
has statistics: no
line-power
warning-level: none
online: no
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/battery_max170xx_battery
native-path: max170xx_battery
power supply: yes
updated: Wed 25 Jan 2023 02:04:25 PM CET (54 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: discharging
warning-level: none
energy: 11.3431 Wh
energy-empty: 0 Wh
energy-full: 13.8572 Wh
energy-full-design: 13.8572 Wh
energy-rate: 3.04983 W
voltage: 3.98547 V
time to empty: 3.7 hours
percentage: 99%
temperature: 37.7 degrees C
capacity: 100%
technology: lithium-ion
icon-name: 'battery-full-symbolic'
History (charge):
1674651865 99.000 discharging
History (rate):
1674651865 3.050 discharging
1674651865 3.078 discharging
1674651856 2.168 discharging
1674651856 2.617 discharging
1674651856 0.087 discharging
Device: /org/freedesktop/UPower/devices/line_power_bq25890_charger
native-path: bq25890-charger
power supply: yes
updated: Wed 25 Jan 2023 02:04:16 PM CET (63 seconds ago)
has history: no
has statistics: no
line-power
warning-level: none
online: no
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated: Wed 25 Jan 2023 02:04:25 PM CET (54 seconds ago)
has history: no
has statistics: no
battery
present: yes
state: discharging
warning-level: none
energy: 11.3431 Wh
energy-full: 13.8572 Wh
energy-rate: 3.04983 W
time to empty: 3.7 hours
percentage: 99%
icon-name: 'battery-full-symbolic'
Daemon:
daemon-version: 0.99.11
on-battery: yes
lid-is-closed: no
lid-is-present: no
critical-action: PowerOff
1 Like
Voltage there is still too low (way below 4.20V, meaning values are still artificial). Just while energy-full value should be slightly higher than energy-full-design value (design value will not and should not be changed). Therefore, when red LED light off, try to reboot into 100% battery capacity, in order to get calibrated values there (and do not have to remove Librem 5 battery again).
In short, I think that your upower -d output, here posted one, still isn’t perfect, yet way better as what you have had there until now.
This is how it discharges after the first full charge after @dos’ procedure:
and after an additional full charge over night it shows now with upower -d
Device: /org/freedesktop/UPower/devices/battery_max170xx_battery
native-path: max170xx_battery
power supply: yes
updated: Thu 26 Jan 2023 07:13:04 AM CET (118 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: discharging
warning-level: none
energy: 10.1356 Wh
energy-empty: 0 Wh
energy-full: 11.353 Wh
energy-full-design: 13.8572 Wh
energy-rate: 1.08569 W
voltage: 4.00281 V
time to empty: 9.3 hours
percentage: 90%
temperature: 32.3 degrees C
capacity: 81.9286%
1 Like
As your battery looks (not that I’m some expert) like slightly degraded there, please ensure that some power supply/bank is still connected (you’ll be there where you want to be when state outputs fully-charged, as my last two screenshots above show) and:
P.S. I like your progress (but would like to see BPP-L503 battery voltage measurement closer to
4.20) very much.
This means, I should charge the L5 to full while it is switched off. Right?
The exact procedure to follow in the sense of
- do this
- now do this
- and now this
- …
is not very clear to me.
BQ25890 works by itself during reflash process, under Jumpdrive … either when connected to some computer USB port and where BPP-L503 battery cell actually discharges itself (at slower rate, yet discharging while needs to add above 0.47A necessary power that i.MX8 MQ and its periphery are requesting in order to successfully complete the job/task):
or even when actually charging this Li-ion battery as connected to adequate power supply/bank/dock, isn’t it?
And yes, I already gave + to @dos post here for some reason:
This very kind advice applies here as well (providing correct answer), I’m quite sure:
If you use the provided PD charger or an equivalent which is able to supply 3A, I wouldn’t bother with turning the phone off during charging since it’s unlikely that you be hitting that limit, at least as long as you won’t let it pause the charging due to high temperature.
Well, unless you do something like docking it to an external screen to play an online 3D game that uses a camera using cellular connection in a place with poor reception, then the charging will likely slow down due to power draw:)
I thought that this thread applies to the recorded value/output or rather artificial number (and actual main issue/behavior of inserted battery here / of some wrong charging setups on some phones / when those run only on its battery) when energy-full at 26.3287 Wh (like my screenshot shows) or even at:
Yes, and I think my post here is already pretty much complete when it comes to that:
Something isn’t clear there yet?
(btw. I added “during charging” to my previous post in case it wasn’t clear what I meant)
Your post was very clear and I did this as you adviced.
Could we get a patched version in the Purism Librem 5 repo?
1 Like
I guess merge requests eventually merge …