# Charging Limitation for enhanced Battery Life (Feature Request)

Since it is known, that Li-based batteries are stressed most when they are approaching 100% charge, it would be reasonable to offer a firmware option, which allows user-adjustable charge limitation to

Charging to 80% means a small disadvantage at the beginning, but already after one year it pays off and since there is not much battery degradation, after this period it will be a concrete long-term advantage. Some laptops have this feature (Sony, Lenovo). The battery of my Sony Laptop hasn't lost measurable capacitance after four years of daily usage and a lot of charge and discharge cycles (applying a limitation to 80%). This is a very simple-to-implement firmware feature and makes the Jolla sustainable ("green sailing technology") and will be a cool feature for advertisement.

edit retag close delete

3

I found web site, which seems to have valid information about the charging and cylic usage of the lithium battery.

http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries

( 2014-09-13 09:56:11 +0200 )edit
2

I closed my question as a duplicate of this; however, I would like to get answers for these questions:

I would like my Jolla to stop charging the battery at some percentage of the full charge. Let's say it be 80%.

First question: Does Jolla stop charging the phone when at 100%?

Second question: Is there a way to limit it by setting 80% as the "Designed Maximum" Voltage by modifying data in here: /sys/class/power_supply/battery/?

Third question: If not here, where can I change it? 8D

( 2014-10-14 13:55:45 +0200 )edit
4

equally so we would like a power save mode, like N9 has, that will automatically turn off power consuming operations when the battery level drops e.g. 30%

( 2014-10-14 14:06:05 +0200 )edit

Sort by » oldest newest most voted

Hei,

Update for SailfishX

I was afraid this hack won't work on SailfishX. But, hey! SailfishX has a better way to do it:

/sys/class/power_supply/battery/baterry_charge_enable

If '0' is written in it, battery charging stops immediately. And the discharging is way less than JP1301 had. I believe, in that case, the external power supply was logically cut and the phone went on battery only. But this in case, USB power supply is used and the battery is only there for buffering.

I just wanted to share my experiences.

/Update for SailfishX

I refined my method over time. I am leaving the original script as well, but I am posting the way I currently use it.

Here it goes:

I created two short scripts, one for starting, one for stopping charging. All the timeing and battery checking is done by Situations App via the script 'What'. I figured that this leaves the least amount of over-head.

Situations created:

'Start charging':
'When': Accessory = Charger && Battery !> 70% remaining
'What': Command: /the/path/to/charging_start.sh

'Stop charging':
'When': Accessory = Charger && Battery !< 80% remaining
'What': Command = /the/path/to/charging_stop.sh

'Charging':
'When': Accessory = Charger
'What': Command (at end) = /the/path/to/charging_start.sh


Contents of 'charging_start.sh':

#!/bin/sh
# We need to take control over this, every time after reboot.
chmod 777 /sys/class/power_supply/usb/charger_disable
# Set it to allow charging.
echo 0 > /sys/class/power_supply/usb/charger_disable


Contents of 'charging_stop.sh':

#!/bin/sh
# We need to take control over this, every time after reboot.
chmod 777 /sys/class/power_supply/usb/charger_disable
# Set it to stop charging.
echo 1 > /sys/class/power_supply/usb/charger_disable


Start of the original post:

I managed to patch together a shell script that handles the charging on the Jolla phone. It limits charging at around 80% of SoC and (if charger was not disconnected) starts charging at around 40% of SoC. To make full use of it, I installed Situations app from Jolla Store and created a situation that is triggered when charger accessory is connected and runs my script.

The contents of charging_control.sh script:

#!/bin/sh
# We need to take control over this, every time after reboot.
chmod 777 /sys/class/power_supply/usb/charger_disable
# Set it to allow charging.
echo 0 > /sys/class/power_supply/usb/charger_disable

#Set the variables.
soc=$(cat /sys/class/power_supply/battery/energy_now) present=$(cat /sys/class/power_supply/usb/present)
state=$(cat /sys/class/power_supply/usb/charger_disable) #Start the loop and keep cycling while the charger is present. while (($present > 0))
do
present=$(cat /sys/class/power_supply/usb/present) soc=$(cat /sys/class/power_supply/battery/energy_now)

#If SoC is over around 80%, charging is disabled.
if (($soc > 5400000 &&$state == 0)); then
echo 1 > /sys/class/power_supply/usb/charger_disable
state=1
fi

#If the SoC drops below around 40% and the charger is still connected, charging is enabled.
if (($soc < 2500000 &&$state == 1)); then
echo 0 > /sys/class/power_supply/usb/charger_disable
state=0
fi

#Sleep for a while before re-checking the situations.
sleep 120
done

#Re-enable charging when the charger is removed. Preparing for the next time.
if ((\$present < 1)); then
echo 0 > /sys/class/power_supply/usb/charger_disable
fi


The contents of the charging_control.desktop file:

[Desktop Entry]
Type=Application
Name=Charging Control
#The location of my script:
Exec=/home/nemo/.scripts/charging_control.sh
Icon=icon-l-terminal


The .desktop file can be put into any of the two folders:

1. /home/nemo/.local/share/applications

2. /usr/share/applications

Limitations:

With Situations app (by Pastilli Labs) currently only the second location works.

The script can only be run as root.

Disclaimer: As always, proceed at your own risk. I will be sorry if you happen to brick you device, but it won't be my fault. This script is working for me, though.

I know that this script is not at all professional. It might have limitations or defects. If you notice one, please let me know, so I can update my post.

PS.: If somebody feels to create a daemon out of the above, please do it. But send me a copy.

LVPVS out.

more

Thanks a lot! Especially keeping difficulties in supply of Jolla batteries in mind this is of great help!

( 2015-03-05 16:47:55 +0200 )edit

You are welcome! Actually, the battery (still the original one) of my First One (from december 2013) is at 85% of health. Should I have used this method of charging from day one, I guess my battery would be over 90%, if not 95%. LVPVS out.

( 2015-03-05 16:53:32 +0200 )edit

How do you run this script as root? Apparently "situations" runs this script as "nemo", or am I mistaken?

( 2015-03-08 10:40:18 +0200 )edit

Got around the issue (temporarily) by chmod 777 /sys/class/power_supply/usb/charger_disable as root. Just that I need to do it again after next phone restart.

btw. your battery must have gotten old when you have 5400000 as 80%. I have set the limit to 6000000 which wil get me to approx 75%.

( 2015-03-09 20:28:58 +0200 )edit

I have tried this with Sailfish OS 1.1.6.27 and apparently I can write to /sys/class/power_supply/usb/charger_disable, the value is not saved. I wrote a Python script based on your idea. My script will be called by systemd every minute using timer and service file. I find this much more readable. However, it just does not work since the changes to charger_disable are not retained at all.

( 2015-06-29 23:02:07 +0200 )edit

This is unnecessary. 100% charge on a lithium battery isn't actually 100% of the total possibility of the battery as this would put the lithium battery in an unstable potentially explosive state.

Consumer batteries tend to operate in the 10-90% capacity range, so when you charge your phone/laptop etc battery, it may read 100% but in actuality it is only around 90% of the total capacity possible of the battery, same with 0% actually being around 10% of the battery. If you were to fully discharge the lithium battery, it would most likely not work again as lithium batteries like to operate in particular regions and also why memory effects don't exist.

So in summary, by messing around with the levels you are actually doing yourself a disservice, just leave it as it is, where it works most optimally.

Source: I'm an EE.

more

1

As an engineer, I approve the source.

( 2015-09-22 14:32:31 +0200 )edit

The closer you get to the maximums/minimums of a battery during its use, the more you are using it up.

Source

LVPVS out.

( 2015-09-22 14:57:45 +0200 )edit
1

"Trust me! I am an engineer!" Great one! :-D

( 2016-07-13 17:22:36 +0200 )edit

yeah, maybe you´re engineer, i am just IT technician, but surely you wil agree that overnight charging is battery destroyer.so if you charge to full and then have set some state (example 85%) when charging will start again, it is good for battery life, because battery will not reach 100% multiple times through the night.so you charge to 100% and if usb still connected, it will charge again at 85%.but i think no battery will discharge itself from 100 to 85%, so you pick up your phone in the morning with battery state maybe 96% and you don´t have to be afraid of battery life, because it was charged just once through the night.

( 2019-11-03 23:23:57 +0200 )edit

That would be a cool feature, but don't forget that fully discharging also reduces battery life, so a complete solution would provide dis/charge intervals, with good suggested defaults for different scenarios' needs.

more

2

If the firmware of the phone is written properly, then a fully discharge should be prevented anyway: it should switch off the phone when the critical final discharge vottage (which is 3.3V for Li-Polymer batteries) is reached. This should be the 0% capacity reference level.

( 2014-09-10 23:27:48 +0200 )edit

That's a different thing, that's to prevent a life and death situation of the battery. What we are talking about is prolonging it's lifespan, which requires not to discharge the battery completely (completely = up to the firmware limit)

( 2014-09-11 17:08:13 +0200 )edit

There is the /sys/class/power_supply/usb/charger_disable entry in sysfs. You will have to chmod it on every boot and you can disable charging by writing 1, enable again by writing a 0. This was purely done for testing and is not really recommended to use. But in case you really want you can write something that keeps track of the charging state (you can also read that from sysfs) and set/unset the charging based on that.

Anyway at your own risk and not recommended.

more

1

Now this is why I will never regret pre-ordering Jolla! I put up a question and a few hours later I get replies... Even from a Sailor. Cheers, @Philippe De Swert

( 2014-10-15 16:20:04 +0200 )edit

May I ask why is it not recommended?

( 2014-10-15 16:50:20 +0200 )edit

@mornfall: Well it is not really tested. So the effects on the battery are a bit unknown (although you guys hope it will live longer, it is just not tested). And depending on whatever script/software etc you make, it might be that your phone will not charge without manual intervention. @LVPVS: You're welcome! We try to help when we can. Thanks!

( 2014-10-15 16:53:15 +0200 )edit

@Philippe, ok, thanks; it sounded a bit like you knew that it's going to backfire so aren't recommending it... something to improve life expectancy of the battery would be good though, laptop batteries rarely last 2 years for me and we can't even get replacements for jolla?

( 2014-10-15 17:13:07 +0200 )edit

@Philippe De Swert, I don't want to shoot myself in the leg by creating a daemon with some over-head to change the key according to the SOC, thus loosing some stand-by time to conserve the battery itself. Do you think if it is possible (or worth trying) to make the phone think it has reached maximum designed SOC when actually at 80%? Maybe by changing the content of voltage_max_design? Would it require to re-calculate all the other max values? Or are these numbers taken from elsewhere?

( 2014-10-15 18:13:36 +0200 )edit

Try my app Charger Control available through Warehouse to control when to charge and not. Next version hopefully adds support for automatic switching at configured charge levels. Works only on the original Jolla phone for now.

more

Little usage experience from me. When I started to use these scripts 3-4 months ago the capacity of the battery was ~90%. With the scripts I'm charging the battery to 61% and discharge it to 59%, all night on charger, during the day the charge level drops to 40-50% (depends on the usage), and in the evening on charger again. During these 3-4 months there was constant increasing of the battery capacity. Now it shows 102.10% capacity (8.15 Wh vs. 7.98 Wh by design) and it looks like it will continue to increase in the (near) future. I'm curious if I unlocked some hidden capacity with that usage model, or (probably) there is a bug in the controller/sensors/system. And what will happen if I make a full charge now - if I will see wrong percent of the charge level, or an explosion :)

more

Do it! Do it! :-)

( 2016-07-13 17:24:52 +0200 )edit

You may also need to visit this site for some information about writing. I think that it could provide some additional help in your situation. This could be really helpful

( 2018-03-14 12:21:09 +0200 )edit