Good runtime, but inaccurate charge level indicator despite calibration

uConsole
,
1

Does anyone have any idea why my charge level indicator is extremely inaccurate despite calibration?

I have a CM4 with a HackerGadgets NVMe battery board and two SAMSUNG E35 batteries. I get a runtime of about 4 hours. That’s great.

The problem, however, is that the battery level indicator (Rex’s Trixie Image) shows 100% for about 2 hours, then drops and switches off at around 75 to 80%. I’ve already performed the battery calibration three times, with no improvement.

I also have the problem that the uConsole no longer starts up when I shut it down after about 2 hours and then try to boot it up again. The green LED behind the power button then flashes briefly and goes out again. I can only boot it up again after recharging.

I’d be grateful for any advice.

2

Doesn’t anyone have any idea? :thinking: :confused:

3

I dealt with a similar problem before I upgraded to the NVMe board and moved to a flatpack battery (10,000 mAh). I’ve only done a full charge and drain once with the new battery but on the first drain, I got between 5 and 6 hours and the battery level showed 17% when the device shut off.

With the 2,000 mAh 18650s I’d been using, the battery level indicator was very inconsistent – sometimes it would show a number in the 70-80% range when shutting off, others it would get down under 5%. It would run for about the same amount of time though, no matter what. I’m hoping the new battery and battery board will be more consistent, but only time will tell.

1 Like
4

Thank you very much for pointing that out.

It’s clearly down to the discharge curve. It’s great that the E35s maintain a stable voltage for so long, but apparently the voltage on my batteries doesn’t drop as linearly as shown in many diagrams. Or perhaps I had an insufficient load during calibration (idle with low backlight).

I’ll now try calibrating the battery under a higher load.

5

Well, I think I’ve found the cause.

I ran the battery calibration again, but this time I didn’t let the uCosnole run idle until it shut down; instead, I ran it under load. I played a Full HD video several times using VLC and also set the screen brightness to around 50%.

Whilst the uConsole was running, the battery indicator steadily dropped, and the last figure I noticed was just over 20%. That seems reasonable to me. I then fully recharged the batteries, and now the battery indicator appears to be dropping at a ‘reasonable’ rate and no longer stays at 100% for hours, before dropping dramatically.

3 Likes
Turns off at ~55% charge
6

I’m trying to calibrate my new 26650 batteries, because I’m seeing similar issues. My uconsole has been switched on and in use for ~20 minutes now and still shows 100% charge. Yesterday I tried running the calibration script and leaving the uconsole idle until it shut down. Then after the uconsole shut down, I recharged it while t was switched off. This doesn’t seem to have fixed the issue.

So I have a question. When you “fully recharged the batteries” did you do it with the uconsole switched on or off?

7

Battery calibration seems not to work well. I thought I was the only one!

8

don’t leave uconsole idle till shutdown, calibrate under load

1 Like
9

I charged the batteries while the uConsole was switched off.

As @white-round-square already mentioned, it’s best to perform the calibration under load. However, I’ve noticed that the charge level indicator is also more accurate during operation the higher the load is, not just the calibration.

1 Like
10

I had a lot of trouble trusting the battery monitor on Trixie. Even after calibration, it was frequently inaccurate, and I often had to physically remove and reinsert the batteries just to reset the counters. Even then, the readings were unpredictable.

Since my workload is relatively heavy (mostly SDR usage), the system would sometimes simply power off around 30% battery remaining, likely due to a mix of temperature, current draw, voltage sag under load, and similar factors.

Because of this, I decided to test two different high-drain batteries: one focused on capacity, and another focused on sustained amperage. I ended up having to explicitly declare the battery characteristics inside config.txt so the battery gauge could behave more accurately.
[pi5]

# Molicel M35A 3500mAh (10A)
#dtoverlay=clockworkpi-custom-battery
#dtparam=charge_full_design_uah=7000000
#dtparam=energy_full_design_uwh=25900000


# Molicel P30B 3000mAh (30A)
dtoverlay=clockworkpi-custom-battery
dtparam=charge_full_design_uah=6000000
dtparam=energy_full_design_uwh=22200000

After editing config.txt, you will need to reboot the uConsole.

To verify that the battery was correctly recognized, use:

upower -d

This is a very useful tool to validate battery parameters, power draw, charge/discharge behavior, voltage, estimated runtime, and overall battery health. It also helped me better understand why the shutdown behavior under heavy SDR load was so inconsistent.

In my particular use case, the Molicel P30B 3000mAh ended up being the most reliable and efficient option. With heavy SDR load, it was still able to reach around 2% before shutting down.

ATTENTION: These parameters apply only to these exact battery models. Do not reuse these values for other batteries. Look up the correct specifications for your own cells before changing anything.

Also remember: you are dealing with lithium batteries. Misconfigurations, bad cells, improper charging, physical damage, or incorrect parameters can be dangerous and may result in overheating or fire.

ONLY use these parameters if you are actually using these exact batteries.

Hope this helps someone.

Note: CM5+AIOv2+NVMe Battery Board (Linux clockworkpi 6.12.93-v8-16k+ #4 SMP PREEMPT Thu Jun 11 20:31:33 EDT 2026 aarch64 GNU/Linux)

5 Likes
11

Thank you for all the info so far. It looks like I will need to manually edit my battery so that the OS knows that I am using 2x 5000mAh cells. We can’t just expect the “calibrate” script to automagically fix this.

So I have found the relevant files in /sys/class/power_supply/axp20x-battery.

I see that edit energy_full is presently set to 24790000. I assume this is in microwatt hours: if I divide this number by nominal battery voltage (3.7) I get 6700000. If I divide that by two (because the uConsole uses two cells) I get 3350000. If I divide by 1000, (to convert from microwatts to milliwatts) I get 3350, which seems like sensible value in mAh for a good-quality 18650 cell.

So, working the other way, I should use some value between 5000 (the claimed capacity of my 26650 cells) and 4500 (subtracting 10% from the claimed capacity as a safety factor). To start conservatively, using 4500 would give me a final value of 33300000, in place of the original 24790000. A quick sanity check says this is about 30% more than the original value, which shows I haven’t screwed up too badly.

Unfortunately, I am unable to edit the values in this directory. For example, if I try sudo nano energy_fullI can’t save my changes.

It is probably clear that I am not a linux commandline guru. Any suggestions on how I can modify these settings to accommodate my new battery? Or is there a “better” way to inform the OS of the changes?

Thanks.

12

I should also add, that when I try a similar approach on a Lenovo laptop running an old version of Linux Mint, I have no trouble editing values in /sys/class/power_supply/BAT0. For example, I have successfully changed charge_stop_threshold to 95, from its default value of 100.

14

Saw this elsewhere in the forum, but don’t have the energy to go find it, LOL…

sudo nano /boot/firmware/config.txt

Type the command above (substitute your editor of choice for nano). Scroll to the “[all]” section. Add the following, substituting your battery values, on a line by itself.

dtoverlay=clockworkpi-custom-battery,charge_full_design_uah=14000000,energy_full_design_uah=14000000

Save and reboot.

1 Like
15

Thanks, with your keywords I found the relevant post at https://forum.clockworkpi.com/t/uconsole-still-often-unpredictably-dying-at-50/19796/4

Rex has given some good info in that post explaining the settings. Note that in your example, energy_full_design should have units of uwh, not uah. This setting should be in microwatt-hours, not microamp-hours. This is usually calculated by multiplying the amp-hours by the nominal voltage of the battery (3.7V for lithium-ion chemistry). My cells are rated at 5000mAh, but I was conservative in my settings and used 9000000 uah (i.e, 2x 4500mAh cells). Hopefully this keeps them from ever overcharging, though possibly at the expense of a slight decrease in total runtime.

I’ve updated the settings in config.txt and rebooted. Now I need to charge to 100% and run the calibration script again to see if it works :slight_smile:

16

Oh my gosh, you’re right! Thanks for catching my mistake. I’ve corrected, rebooting, then going to do a fresh calibration session.