I am now daily driving my PinePhonePro for well over a year, but there is one issue that still annoys me:
The PinePhone pro uses Battery fuel gauging as implemented in the RK818 Chip.
Fuel gauging works ok when using one battery. Battery full and empty indications match the battery voltages within a couple of percentage points.
But the daily driving the PPP with only one battery is hard.
When using multiple batteries, however, the fuel gauging becomes really annoying, as the phone will show the percentage of the last (empty) battery until it shuts off.
After a couple of reboots, the fuel gauging seems to reset itself, but rebooting the PPP several times takes time and does not seem like an ideal solution.
Is there a possibility to reset the fuel gauge calibration on eg. each reboot to avoid unintended shutdowns after battery swapping?
(12-30-2024, 01:09 AM)franzthiemann Wrote: I am now daily driving my PinePhonePro for well over a year, but there is one issue that still annoys me:
The PinePhone pro uses Battery fuel gauging as implemented in the RK818 Chip.
Fuel gauging works ok when using one battery. Battery full and empty indications match the battery voltages within a couple of percentage points.
I remember seeing this issue for about a month. Maybe last Oct-Nov or so. I did a full system update early Dec and the battery gauge is stable now.
Device: PinePhonePro (Daily driver)
OS: DanctNIX Arch with Phosh
(01-02-2025, 08:17 AM)mikehenson Wrote: (12-30-2024, 01:09 AM)franzthiemann Wrote: I am now daily driving my PinePhonePro for well over a year, but there is one issue that still annoys me:
The PinePhone pro uses Battery fuel gauging as implemented in the RK818 Chip.
Fuel gauging works ok when using one battery. Battery full and empty indications match the battery voltages within a couple of percentage points.
I remember seeing this issue for about a month. Maybe last Oct-Nov or so. I did a full system update early Dec and the battery gauge is stable now.
Device: PinePhonePro (Daily driver)
OS: DanctNIX Arch with Phosh
But does it work when you change the empty battery for a full one. That is were the problem lies for me.
I would rather have no battery indicator than a battery indicator that makes the phone shutdown even with 4.2V in the battery because it still believes it is empty.
To be more general: Does anyone know how to establish connection with the power management chip from the os?
I believe that setting the GGCON_REG: FUEL GAUGE CONFIGURATION REGISTER from current to voltage mode should resolve the issue, even if it reduces accuracy
01-15-2025, 10:24 AM
(This post was last modified: 01-15-2025, 10:25 AM by biketool.)
I had to deal with this yesterday. I recalled that if you reboot a few times it would reset, no, that doesn't work.
On the N900 we had a script to reset the battery controller.
How does it work for people who have an external battery charger.
Pinephone pro Mobian sid/weekly.
Back on N900 the controller would calibrate based on a full charge to shutdown at minimum voltage.
(01-15-2025, 10:24 AM)biketool Wrote: I had to deal with this yesterday. I recalled that if you reboot a few times it would reset, no, that doesn't work.
Seems like rebooting is not what resets the controller, but waiting out the calibration error time of the controller
(01-20-2025, 09:52 AM)franzthiemann Wrote: (01-15-2025, 10:24 AM)biketool Wrote: I had to deal with this yesterday. I recalled that if you reboot a few times it would reset, no, that doesn't work.
Seems like rebooting is not what resets the controller, but waiting out the calibration error time of the controller
how much time for it to timeout?
(01-20-2025, 11:04 AM)biketool Wrote: (01-20-2025, 09:52 AM)franzthiemann Wrote: (01-15-2025, 10:24 AM)biketool Wrote: I had to deal with this yesterday. I recalled that if you reboot a few times it would reset, no, that doesn't work.
Seems like rebooting is not what resets the controller, but waiting out the calibration error time of the controller
how much time for it to timeout?
I would guess that the RK818 is configured to 16 min.
The value is configured via bits 4 and 5 in the GGCON_REG (according to the datasheet). Possible options are 8 min, 16 min, 32 min or 48 min.
To get the exact time, one would need to check the register. This brings us back to the beginning: How to communicate with this chip?
01-24-2025, 07:19 AM
(This post was last modified: 01-24-2025, 07:20 AM by biketool.)
(01-23-2025, 10:05 AM)franzthiemann Wrote: I would guess that the RK818 is configured to 16 min.
The value is configured via bits 4 and 5 in the GGCON_REG (according to the datasheet). Possible options are 8 min, 16 min, 32 min or 48 min.
To get the exact time, one would need to check the register. This brings us back to the beginning: How to communicate with this chip?
This is the thing with the hardware we have in our hands, if we really had some more devs like used to be around the Nokia maemo lab we would have great battery life(and tweaks for this battery chip), full hardware acceleration. We have the hardware already we just need to be able to use it and that skillset is not found many places anymore in a world where most mobile OS development is already in two small on-campus groups Android and Apple. Plenty of linux devs but their specialty is mostly not mobile or low power embedded.
(01-23-2025, 10:05 AM)franzthiemann Wrote: (01-20-2025, 11:04 AM)biketool Wrote: (01-20-2025, 09:52 AM)franzthiemann Wrote: (01-15-2025, 10:24 AM)biketool Wrote: I had to deal with this yesterday. I recalled that if you reboot a few times it would reset, no, that doesn't work.
Seems like rebooting is not what resets the controller, but waiting out the calibration error time of the controller
how much time for it to timeout?
I would guess that the RK818 is configured to 16 min.
The value is configured via bits 4 and 5 in the GGCON_REG (according to the datasheet). Possible options are 8 min, 16 min, 32 min or 48 min.
To get the exact time, one would need to check the register. This brings us back to the beginning: How to communicate with this chip?
I have been looking into this. It's on an i2c bus. On FreeBSD for example, I can do this to read the GGCON_REG:
Code: i2c -a 0x1c -f /dev/iic1 -o 0xb0 -d r -c 1
On Linux though, there isn't even /dev/iic or /dev/i2c devices (there's iio:device but not sure if that's the same). There is /sys/bus/i2c/.. but that doesn't seem to work with i2c-tools. I'm considering compiling the rk818 battery driver and then dynamically loading it with modprobe so that I can experiment with changes to some of it's settings.
|