LED Charge Status on Solar Boron LTE (2.3.0-rc1)

I’m getting ready to start a new set of Solar Charging Trials for the Boron LTE, in preparation for LTS 2.3.0 final. I’ve noticed something strange with the Charge Status LED. It’s been a while since I was involved with Solar testing and I’m afraid I’ve forgotten a lot.

Question: What’s the minimum mA required for the PMIC to light the Charge Status LED ?

Background: Since Solar Charging is extremely easy with decent sunlight, I’m going to focus this Trial on Cloudy Weather performance across 5-10 different sizes (and Models) of small Solar Panels.
The Test Hardware Setup is the same as here : Tripler Board, INA219, and OLED feathers.

The Boron LTE (2.3.0-rc1) is Cloud Connected and the test rig draws 95-100 mW from the Li-Po consistently after the initial Boot-up and Cloud Connection (includes the INA219 and OLED screen power requirements). For instance: that’s 24 mA @ 3.93V.

During preliminary testing in Cloudy conditions, some Solar Panels will light the Charge Status LED while others will not. It’s not necessarily related to the Panel’s Size or Power Rating. I was expecting this, as it’s the purpose of the planned Trial. The strange part is even though the Charge Status LED is ON, the INA219 sometimes shows no reduction in the power sourced from the Li-Po.
IE: The Boron thinks it’s Charging, but the same -95 mW (-24mA) is leaving the Li-Po.
Obviously, as light levels increase, the power & current leaving the Li-Po will approach Zero and then into the Positive range (recharging).

I’ve searched the PMIC Datasheet and this forum for the minimum mA required for the Charge Status LED with no Luck. But I’m pretty sure it’s been discussed previously.

Any ideas on what’s going on in this situation?

I know that in the real world this isn’t a big deal, but it’s fairly important to my proposed Trial to determine a great (Panel/Battery) combo for long-term Solar applications on LTS firmware.

The initial Goal is to be able to remain Online 24/7 a minimum of 2 weeks of Cloudy weather before needing a Sunny day or to Start a progressive Sleep schedule.

Thanks in Advance for any insights or comments.

1 Like

That depends on what the charge current is set to. Check out the power management settings for more information.

Sounds like a cool project you’re working on!

Thanks for the reply @Colleen .

But I’m afraid that don’t see the answer in the FAQ.
It’s my understanding that batteryChargeCurrent sets the Maximum current allowed for recharging.
I typically only use it for a drastic change in Li-Po size, to keep charging at 0.5C or lower.

It’s pretty easy to get a Solar Boron LTE in a state where the Charge Status LED is ON, but the Boron is actually sourcing slightly more power from the Li-Po than normal.

Again, I know this isn’t a big deal to most people, and I’m not “looking” to find problems.
But I wont be deploying Long Term Solar Boron’s with an INA219 onboard, so I’d love to get a handle on the actual conditions for Solar recharging.

It’s going to be hard to make accurate predictions when to apply the Progressive Sleep Schedule for a Remote Solar Install if the Boron reports it’s recharging when it’s actually not.

Has anyone started the Code for a register dump of the PMIC whenever System Power Manager makes changes ?

@Colleen , I’d vote for a comprehensive tutorial for Low-Powered Solar Use, with Provided “Baseline” Code that we can all test against. It would be a Living Document that’s updated/refined via Peer Review. I’d also vote that it starts with the LTS branch.

The great @no1089 has done some work on this. This will give you the values as set:

void setup() {
    // See system_power.h for these definitions
    // typedef enum {
    //     BATTERY_STATE_UNKNOWN = 0,
    //     BATTERY_STATE_NOT_CHARGING = 1,
    //     BATTERY_STATE_CHARGING = 2,
    //     BATTERY_STATE_CHARGED = 3,
    //     BATTERY_STATE_DISCHARGING = 4,
    //     BATTERY_STATE_FAULT = 5,
    //     BATTERY_STATE_DISCONNECTED = 6
    // } battery_state_t;

    // typedef enum {
    //     POWER_SOURCE_UNKNOWN = 0,
    //     POWER_SOURCE_VIN = 1,
    //     POWER_SOURCE_USB_HOST = 2,
    //     POWER_SOURCE_USB_ADAPTER = 3,
    //     POWER_SOURCE_USB_OTG = 4,
    //     POWER_SOURCE_BATTERY = 5
    // } power_source_t;

    int powerSource = System.powerSource();
    int batteryState = System.batteryState();
    float batterySoc = System.batteryCharge();
    
    constexpr char const* batteryStates[] = {
        "unknown", "not charging", "charging",
        "charged", "discharging", "fault", "disconnected"
    };
    constexpr char const* powerSources[] = {
        "unknown", "vin", "usb host", "usb adapter",
        "usb otg", "battery"
    };

    Log.trace("Power source: %s", powerSources[std::max(0, powerSource)]);
    Log.trace("Battery state: %s", batteryStates[std::max(0, batteryState)]);
    Log.trace("Battery charge: %f", batterySoc);
}

void loop() {

}

batteryChargeCurrent == the current the battery is charged at, not the maximum. If it’s set higher than the solar panel can provide then it’s not charging.

That’s a really interesting idea, thanks. I haven’t looked at Low-Powered Solar Use much but it seems vey useful overall. I’ll look into it as a tutorial offering.