From: Roman Smirnov <r.smirnov@omp.ru>
To: "luiz.dentz@gmail.com" <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ v2] battery: improve the display of the charge level
Date: Tue, 28 Oct 2025 09:05:00 +0000 [thread overview]
Message-ID: <b00aa0b2f8a92c4bd7e3b1f3e599652cb60ce7e3.camel@omp.ru> (raw)
In-Reply-To: <CABBYNZL22wrX1m2EzzPEw8gPsyM_Gurxmtf_rsKDxB9N0Y6Zfw@mail.gmail.com>
On Mon, 2025-10-27 at 11:59 -0400, Luiz Augusto von Dentz wrote:
> Hi Roman,
>
> On Mon, Oct 27, 2025 at 11:19 AM Roman Smirnov <r.smirnov@omp.ru> wrote:
> >
> > The battery charge level may fluctuate due to uncalibrated
> > sensors. Commit smooths out such fluctuations.
> >
> > The algorithm for determining uncalibrated sensors consists of
> > finding the number of changes in charge direction (i.e., "spikes").
> > If the number of spikes is zero, the device is charging or discharging.
> > If there is one spike, it may mean that the device has started charging
> > or has been disconnected from charging. If there are two or more
> > spikes, this is a clear indication of an uncalibrated sensor.
> >
> > Check that the battery charge is fluctuating. If the battery charge
> > is fluctuating, use the average charge value, otherwise use the current
> > value.
>
> Is this method based on something used already? Or it is yet again
> something you came up with?
>
I looked into the Linux kernel, where I found the use of the average
value instead of the minimum:
1. https://elixir.bootlin.com/linux/v6.17.4/source/drivers/power/supply/cw2015_battery.c#L306
2. https://elixir.bootlin.com/linux/v6.18-rc2/source/drivers/power/supply/adc-battery-helper.c#L121
I couldn't find an algorithm for determining uncalibrated sensors,
so I came up with my own.
> > Fixes: https://github.com/bluez/bluez/issues/1612
> > ---
> > src/battery.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 62 insertions(+)
> >
> > diff --git a/src/battery.c b/src/battery.c
> > index 59e4fc570..f97d9b8f3 100644
> > --- a/src/battery.c
> > +++ b/src/battery.c
> > @@ -33,10 +33,16 @@
> > #define BATTERY_PROVIDER_MANAGER_INTERFACE "org.bluez.BatteryProviderManager1"
> >
> > #define BATTERY_MAX_PERCENTAGE 100
> > +#define LAST_CHARGES_SIZE 8
> > +#define MAX_CHARGE_STEP 5
> >
> > struct btd_battery {
> > char *path; /* D-Bus object path */
> > uint8_t percentage; /* valid between 0 to 100 inclusively */
> > + uint8_t *last_charges; /* last charges received */
> > + uint8_t lru_charge_id; /* oldest battery charge */
> > + float avg_charge; /* average battery charge */
> > + bool is_fluctuating; /* true, if the battery sensor fluctuates */
> > char *source; /* Descriptive source of the battery info */
> > char *provider_path; /* The provider root path, if any */
> > };
> > @@ -92,6 +98,11 @@ static struct btd_battery *battery_new(const char *path, const char *source,
> > battery = new0(struct btd_battery, 1);
> > battery->path = g_strdup(path);
> > battery->percentage = UINT8_MAX;
> > + battery->last_charges = new0(uint8_t, LAST_CHARGES_SIZE);
>
> I'd prefer to use a queue rather than an array for looking back.
>
> > + battery->lru_charge_id = 0;
> > + battery->avg_charge = 0;
> > + battery->is_fluctuating = false;
> > +
> > if (source)
> > battery->source = g_strdup(source);
> > if (provider_path)
> > @@ -105,6 +116,9 @@ static void battery_free(struct btd_battery *battery)
> > if (battery->path)
> > g_free(battery->path);
> >
> > + if (battery->last_charges)
> > + g_free(battery->last_charges);
> > +
> > if (battery->source)
> > g_free(battery->source);
> >
> > @@ -217,6 +231,39 @@ bool btd_battery_unregister(struct btd_battery *battery)
> > return true;
> > }
> >
> > +static void check_fluctuations(struct btd_battery *battery)
> > +{
> > + uint8_t spikes = 0;
> > + int8_t step = 0;
> > + int8_t direction = 0;
> > + int8_t prev_direction;
> > +
> > + for (uint8_t id = 0; id < LAST_CHARGES_SIZE - 1; id++) {
> > + prev_direction = direction;
> > + step = battery->last_charges[id] - battery->last_charges[id + 1];
>
> I prefer to avoid this type of construct, even though it seems to be
> safe to access id + 1 since the loop is limited to LAST_CHARGES_SIZE -
> 1, I'd rather use a queue to access elements, anyway I also think it
> is probably a good idea to store the direction as well.
>
I will prepare the next version, which will use a queue. Thank you for
your review.
> > +
> > + /*
> > + * The battery charge fluctuates too much,
> > + * which may indicate a battery problem, so
> > + * the actual value should be displayed.
> > + */
> > + if (step > MAX_CHARGE_STEP) {
> > + battery->is_fluctuating = false;
> > + return;
> > + }
> > +
> > + if (step > 0)
> > + direction = 1;
> > + else if (step < 0)
> > + direction = -1;
> > +
> > + if (direction != prev_direction && !prev_direction)
> > + spikes++;
> > + }
> > +
> > + battery->is_fluctuating = (spikes > 1) ? true : false;
> > +}
> > +
> > bool btd_battery_update(struct btd_battery *battery, uint8_t percentage)
> > {
> > DBG("path = %s", battery->path);
> > @@ -231,6 +278,21 @@ bool btd_battery_update(struct btd_battery *battery, uint8_t percentage)
> > return false;
> > }
> >
> > + if (!battery->avg_charge)
> > + battery->avg_charge = percentage;
> > +
> > + /* exponential smoothing */
> > + battery->avg_charge = battery->avg_charge * 0.7 + percentage * 0.3;
> > + battery->last_charges[battery->lru_charge_id] = percentage;
> > +
> > + if (battery->lru_charge_id == LAST_CHARGES_SIZE - 1)
> > + check_fluctuations(battery);
> > +
> > + battery->lru_charge_id = (battery->lru_charge_id + 1) % LAST_CHARGES_SIZE;
> > +
> > + if (battery->is_fluctuating)
> > + percentage = battery->avg_charge;
> > +
> > if (battery->percentage == percentage)
> > return true;
> >
> > --
> > 2.43.0
> >
> >
>
>
next prev parent reply other threads:[~2025-10-28 9:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 15:11 [PATCH BlueZ v2] battery: improve the display of the charge level Roman Smirnov
2025-10-27 15:37 ` Bastien Nocera
2025-10-28 8:54 ` Roman Smirnov
2025-10-27 15:59 ` Luiz Augusto von Dentz
2025-10-28 9:05 ` Roman Smirnov [this message]
2025-10-27 16:37 ` [BlueZ,v2] " bluez.test.bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b00aa0b2f8a92c4bd7e3b1f3e599652cb60ce7e3.camel@omp.ru \
--to=r.smirnov@omp.ru \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).