tjoms99 / xiao_sense_nrf52840_battery_lib Goto Github PK

Hi @Tjoms99
Thanks for the lib.

I am very new on Zephyr and was struggling wit a lot of code samples - I was unable to get most of the examples running.
Not with you code :-) Cool.

But the output of the logging shows pretty random values.
Any hint?

Cheers
Felix

17:18:59.440 -> [00:08:39.338,806] �[0m main: Battery at 3756 mV (capacity 44%) �[0m
17:18:59.440 -> [00:08:41.338,958] �[0m main: Battery at 4149 mV (capacity 97%) �[0m
17:18:59.440 -> [00:08:43.339,111] �[0m main: Battery at 3753 mV (capacity 44%) �[0m
17:19:01.476 -> [00:08:45.339,263] �[0m main: Battery at 4140 mV (capacity 96%) �[0m
17:19:03.470 -> [00:08:47.339,416] �[0m main: Battery at 3759 mV (capacity 44%) �[0m
17:19:05.461 -> [00:08:49.339,569] �[0m main: Battery at 4113 mV (capacity 93%) �[0m
17:19:07.450 -> [00:08:51.339,721] �[0m main: Battery at 3999 mV (capacity 74%) �[0m
17:19:09.445 -> [00:08:53.339,874] �[0m main: Battery at 3762 mV (capacity 45%) �[0m
17:19:11.477 -> [00:08:55.340,026] �[0m main: Battery at 4146 mV (capacity 97%) �[0m
17:19:13.467 -> [00:08:57.340,179] �[0m main: Battery at 3756 mV (capacity 44%) �[0m
17:19:15.449 -> [00:08:59.340,332] �[0m main: Battery at 4146 mV (capacity 97%) �[0m
17:19:17.440 -> [00:09:01.340,484] �[0m main: Battery at 3756 mV (capacity 44%) �[0m
17:19:19.440 -> [00:09:03.340,637] �[0m main: Battery at 4152 mV (capacity 98%) �[0m
17:19:21.435 -> [00:09:05.340,759] �[0m main: Battery at 3762 mV (capacity 45%) �[0m
17:19:23.474 -> [00:09:07.340,881] �[0m main: Battery at 4149 mV (capacity 97%) �[0m
17:19:25.463 -> [00:09:09.341,003] �[0m main: Battery at 3798 mV (capacity 49%) �[0m
17:19:27.444 -> [00:09:11.341,125] �[0m main: Battery at 3951 mV (capacity 69%) �[0m
17:19:29.473 -> [00:09:13.341,247] �[0m main: Battery at 4146 mV (capacity 97%) �[0m
17:19:31.455 -> [00:09:15.341,369] �[0m main: Battery at 3759 mV (capacity 44%) �[0m
17:19:33.447 -> [00:09:17.341,491] �[0m main: Battery at 4149 mV (capacity 97%) �[0m
17:19:35.435 -> [00:09:19.341,613] �[0m main: Battery at 3756 mV (capacity 44%) �[0m
17:19:37.475 -> [00:09:21.341,735] �[0m main: Battery at 4143 mV (capacity 97%) �[0m
17:19:39.466 -> [00:09:23.341,857] �[0m main: Battery at 3759 mV (capacity 44%) �[0m
17:19:41.459 -> [00:09:25.341,979] �[0m main: Battery at 4149 mV (capacity 97%) �[0m
17:19:43.452 -> [00:09:27.342,102] �[0m main: Battery at 3759 mV (capacity 44%) �[0m
17:19:45.445 -> [00:09:29.342,224] �[0m main: Battery at 4068 mV (capacity 86%) �[0m

Summary

Enhance the API to support periodic sampling of battery voltage. This feature will enable users to start and stop periodic sampling, set time intervals, and register callbacks for sample readiness. Additionally, provide a one-shot function to request a sample on demand.

Features to Implement

1. Periodic Sampling

   • Start/Stop Periodic Sampling: Allow users to initiate and terminate periodic sampling of the battery voltage.
   • Set Sampling Interval: Enable users to configure the time interval between each sample.
   • Register Callbacks: Users can register callback functions to be invoked when samples are ready.

2. One-Shot Sampling

   • Request Sample: Provide a function to request a single sample of the battery voltage.
   • Callback Integration: Both periodic and one-shot sampling should utilize the same registered callback functions.

Hello, I don't know if this is an issue with your Lib but I added it to my project and connected a 3.7 Lipo. It first worked fine but after connecting and disconnecting an usb c cable to charge, my chip is now dead... could not determine what happened.

The readme.md is out of date and needs to be repolished

Battery State Determination and Capacity Calculation Enhancement

Summary

Currently, a lookup table is used to determine the battery's charge level based on voltage. This feature can be enhanced by allowing the MCU to determine the battery state dynamically.

Existing Implementation

The lookup table for voltage and capacity in percentage:

static BatteryState battery_states[BATTERY_STATES_COUNT] = {
    {4200, 100},
    {4160, 99},
    {4090, 91},
    {4030, 78},
    {3890, 63},
    {3830, 53},
    {3680, 36},
    {3660, 35},
    {3480, 14},
    {3420, 11},
    {3150, 1}, // 3240
    {0000, 0}  // Below safe level
};

Proposed Feature

Enable the MCU to determine the battery state by running a fully charged battery and discharging it down to just before a safe level. The safe level must be user-defined before running the test.

Discharge Functionality:

• Discharge could be achieved by either powering all the LEDs or activating the BLE.
• The MCU should monitor and record the voltage drop rate at specific voltages.

Improving Capacity Calculation:
Currently, the capacity is determined using linear interpolation:

for (uint16_t i = 0; i < BATTERY_STATES_COUNT - 1; i++)
{
    // Find the two points battery_millivolt is between
    if (battery_states[i].voltage >= battery_millivolt && battery_millivolt >= battery_states[i + 1].voltage)
    {
        // Linear interpolation
        *battery_percentage = battery_states[i].percentage +
                              ((float)(battery_millivolt - battery_states[i].voltage) *
                               ((float)(battery_states[i + 1].percentage - battery_states[i].percentage) /
                                (float)(battery_states[i + 1].voltage - battery_states[i].voltage)));

        LOG_DBG("%d %%", *battery_percentage);
        return 0;
    }
}

Expected Outcome

• Dynamic Battery State Determination: The MCU can determine the battery state dynamically, improving accuracy.
• Enhanced Capacity Calculation: More accurate capacity calculation by considering the actual discharge rate instead of linear interpolation.

Summary

Addressing the issue of current draw by certain GPIOs when enabled, with a focus on optimizing power consumption.

Affected GPIOs

These three GPIOs are drawing current when enabled:

#define GPIO_BATTERY_CHARGE_SPEED 13
#define GPIO_BATTERY_CHARGING_ENABLE 17
#define GPIO_BATTERY_READ_ENABLE 14

Proposed Solution

When not in use, two of these GPIOs can be disabled to save power:

• GPIO_BATTERY_CHARGE_SPEED
• GPIO_BATTERY_READ_ENABLE

Details

• GPIO_BATTERY_CHARGE_SPEED :

  • Should be disabled when the charger is not connected.

• GPIO_BATTERY_CHARGING_ENABLE:

  • If disabled, the battery driver will not be able to detect when a charger is connected or disconnected.
  • Consequently, it will not be able to reconnect GPIO_BATTERY_CHARGE_SPEED automatically, and this would have to be done manually which is something we dont want.

• GPIO_BATTERY_READ_ENABLE:

  • Should be enabled just before a voltage sample is taken.
  • Should be disabled immediately after the sampling is done.

Hi @Tjoms99, this looks like great work.

Can I request that you put a license with this repository, so I know how I can use your code you've published?

I'm developing a battery powered low power application that currently uses ~17ua while sleeping, when I initialize the lib the fact that we keep these 3 gpios active (I think that's the cause)

   ret |= gpio_pin_configure(gpio_battery_dev, GPIO_BATTERY_CHARGING_ENABLE, GPIO_OUTPUT | GPIO_ACTIVE_LOW);
    ret |= gpio_pin_configure(gpio_battery_dev, GPIO_BATTERY_READ_ENABLE, GPIO_OUTPUT | GPIO_ACTIVE_LOW);
    ret |= gpio_pin_configure(gpio_battery_dev, GPIO_BATTERY_CHARGE_SPEED, GPIO_OUTPUT | GPIO_ACTIVE_LOW);

makes my current go up to ~180ua which invalidates the lib for my use case. A workaround is to disable the pins

    ret |= gpio_pin_configure(gpio_battery_dev, GPIO_BATTERY_CHARGING_ENABLE, GPIO_DISCONNECTED);
    ret |= gpio_pin_configure(gpio_battery_dev, GPIO_BATTERY_READ_ENABLE, GPIO_DISCONNECTED);
    ret |= gpio_pin_configure(gpio_battery_dev, GPIO_BATTERY_CHARGE_SPEED, GPIO_DISCONNECTED);

while sleeping and reenable them when I want e.g. to read the batt voltage, this way I can achieve ~17ua current again. however, it's far from ideal since I will lose "on-demand" charging ability when I plug the usb cable in, right?

thoughts?