Boron Solar Charging with 1.5.0-rc1

The feature to disable DeviceOS management of the PMIC has been added in https://github.com/particle-iot/device-os/pull/2015 and is included in 1.5.0-rc.1.

        SystemPowerConfiguration conf;
        conf.feature(SystemPowerFeature::DISABLE);
        System.setPowerConfiguration(conf);

It’s better to run this in STARTUP() macro, as otherwise in order for this feature flag to take effect, a reset will be required.

2 Likes

Update:
I’m testing the new API and the “old” way (direct PMIC calls).

Both modes will continue to Operate the Charging During an EN Pin Shutdown in the last setting before Shutting Down (Enable/Disable Charging), as expected. Reminder: we need to check the enclosure Temperature immediately after a EN Pin Shutdown or Standby Sleep Mode, to decide if charging should be enabled or disabled.

Both modes also appear to recharge the Li-Po appropriately.
The one difference that I’ve noticed is in my “Mode 2” below (direct PMIC calls), the charging current is determined at Boot/Startup. This is not expected, from what I remember from the PMIC datasheet.
In the Field, this means lower Li-Po charging current if the Panel isn’t producing when the Boron Starts.
Due to this, I prefer the new API mode (SystemPowerConfiguration), or Mode “1” in the code snip below:


SYSTEM_THREAD(ENABLED);

PMIC pmic;
SystemPowerConfiguration conf;

//////////////////////////////////////////////
SYSTEM_MODE(MANUAL);
int myTestMode = 1;   //  1 = API  2 = PMIC
//////////////////////////////////////////////

STARTUP( selectMode() );

void selectMode()  {
  // (1) API MODE
  // Known: 3.78V Li-Po, 850 mW Available from Panel @ 5.08V on TEST STAND, 50 mW used by Boron in Manual Mode, OLED, & INA219
  // Charging Results : 3.84V @ Li-Po, 208 mA, 790 mW , Panel Output (Vusb) holding at 5.07V AS EXPECTED
  if (myTestMode == 1) {
    conf.powerSourceMaxCurrent(900)
    .powerSourceMinVoltage(5080)
    .batteryChargeCurrent(1024)
    .batteryChargeVoltage(4208)
    .feature(SystemPowerFeature::PMIC_DETECTION)
    .feature(SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST) ;
    System.setPowerConfiguration(conf);
  }

  //  (2) PMIC Mode
  // Known: 3.78V Li-Po, 850 mW Available from Panel @ 5.08V on TEST STAND, 50 mW used by Boron in Manual Mode, OLED, & INA219
  // Charging Results: 3.82V @ Li-Po, 114 mA, 435 mW , Panel Output (Vusb) holding at 6.45V, DPDM Not Working
  // After Reset : 3.84V @ Li-Po, 195 mA, 750 mW , Panel Output (Vusb) holding at 5.07V AS EXPECTED
  // After more testing, the PMIC Mode will default to the lower charging depending on if the Source is present (Panel Producing) at Startup or Not.
  // Reset or EN Pin Shutdown while the Panel is operating is why the 750 mW charging is reached in PMIC Mode
  if (myTestMode == 2) {
    conf.feature(SystemPowerFeature::DISABLE);
    System.setPowerConfiguration(conf);

    pmic.begin();
    pmic.setInputVoltageLimit(5080);
    pmic.setInputCurrentLimit(900) ;        
    pmic.setChargeVoltage(4208);            
    pmic.setChargeCurrent(0, 0, 1, 0, 0, 0);
    pmic.enableDPDM();
    pmic.enableCharging();
  }

}

Mode 1 will still obey your call for pmic.disableCharging(); when enclosure temperature is too high.

I’ll perform similar charging tests with the Sleep Modes next to see if any differences show up between the API and PMIC code.

Thanks again @avtolstoy, and everyone else involved.

3 Likes

thanks for your reply. please come back with updates when you’ll have some. also, may i ask you questions if i would have some? i see you’re much knowlegeable than me in these things. thank you

@Abnalsid, Welcome to the Community. Ask away.

Update w/ Sleep:
Using Stop Mode (System.sleep( {}, {}, sleepTime); ) shows the same recharging performance as previous test in this thread, with both the API and PMIC modes.

I still prefer the new API (what I called mode 1 in the code snip), for the reasons mentioned previously.

Standby Sleep, or System.sleep(SLEEP_MODE_DEEP); will WAKE the Boron when the Solar Panel Output cycles. IE, when the Panel begins to provide a Voltage Source- the Boron will wake up from Deep Sleep.

A typical Solar Install will use a progressive timed sleep schedule depending on the Li-Po Voltage or SOC. It’s not too hard to size the Panel and Li-Po so the Boron can remain on 24/7 most of the time, if needed.
As a last resort- if the SOC drops below 40% for instance, it could go into Deep Sleep Instead of timed, knowing that the Boron will automatically wake from Deep Sleep once the Solar Panel gets sunshine.

Tests performed with a 2W Voltaic Solar Panel using the USB connector on a Boron LTE running 1.5.0-rc1.

@Rftop, thank you very much for the additional information.

One statement that caught my attention was:

Standby Sleep, or System.sleep(SLEEP_MODE_DEEP); will WAKE the Boron when the Solar Panel Output cycles. IE, when the Panel begins to provide a Voltage Source- the Boron will wake up from Deep Sleep.

Is this technique purely software based, or are you adding hardware to make this possible?

Thank you very much!

That has happened out of the Box since 1.3.1-rc1, maybe even before that.
Here’s a Thread.

I’ve tried to quantify what Voltage causes the Wake Event (from Deep Sleep) with an adjustable power supply.
I wasn’t successful, as it appears the speed that the voltage increase occurs plays a role, not just the V.

1 Like

appreciated and thread added to learning task. you are really helpful. if you don’t mind, may i dm you with possible questions?

@Abnalsid Sure, you can message me. I’ll be glad to help if I can.
But post in the forum if you can, as you can get various opinions and thoughts.
Plus, the discussion will likely help others in the future :slight_smile:

2 Likes

i’m always thinking that asking too much questions (some of which might be obvious for some people) might bother someone especially with my small delice project. i’m just trying to be polite. but i’m going to take your advice :slight_smile: thanks

Thank you for sharing. I am starting to get some field experience with Solar powered Boron sensors. As part of this, I wanted to be able to switch back and forth between “Solar Optimized” settings and the system defaults. If I take what you have done for the API approach and added a “default” setting. Would this make sense? Can it be called during program execution or does it need to be done at restart?

// Power Management function
void PMICreset() {
  if (sysStatus.solarPowerMode) {
    conf.powerSourceMaxCurrent(900)                                  // default is 900mA
    .powerSourceMinVoltage(4840)                                     // Set the lowest input voltage to 4.84 volts best setting for 6V solar panels
    .batteryChargeCurrent(1024)                                      // default is 512mA matches my 3W panel
    .batteryChargeVoltage(4208)                                      // Allows us to charge cloe to 100% - battery can't go over 45 celcius
    .feature(SystemPowerFeature::PMIC_DETECTION)
    .feature(SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST) ;
    System.setPowerConfiguration(conf);
  }
  else  {
    conf.powerSourceMaxCurrent(1500)                                 // default is 900mA this let's me charge faster
    conf.powerSourceMinVoltage(4208)                                 // This is the default value for the Boron
    conf.batteryChargeCurrent(1024)                                  // default is 2048mA (011000) = 512mA+1024mA+512mA)
    conf.batteryChargeVoltage(4112)                                  // default is 4.112V termination voltage
    .feature(SystemPowerFeature::PMIC_DETECTION)
    .feature(SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST) ;
    System.setPowerConfiguration(conf);
  }
}

Thanks,

Chip

Chip, as far as I know- that should work.
But you could probably keep the higher values for MaxCurrent and ChargeCurrent between the Solar Vs Default Settings.

For Solar, you should get more Watts from you panel using .powerSourceMinVoltage(5080) verses your (4840)

@Rftop,

I use a 6V 3.5W panel from Voltaic Systems and these values (recommended by @RWB) have worked well for me.

Is the idea of a 5.080V value, to keep the panel from loosing power when a cloud comes by? Is there a reference somewhere that gives the rationale for these values? Not questioning your advice, just want to learn.

Also, for the default case, is this documented in the API? Since 1.5.0 is still a release candidate, where can I go to read the API. I don’t believe it is documented here yet.

Thanks,

Chip

No, it helps in Cloudy and Sunny Conditions.

Here’s an example with a Voltaic 2W panel for my specific test stand, which is a 100W LED light.
image
[disregard the “cold” curve, that’s before the LED test light was at full output]

For the 2W panel shown above, the 5.08V PMIC setting will produce 10% more than 4.84V would…under my test stand. I would have guessed the difference would have been higher.

Here’s a graph showing how the Max Power Curve depresses down and shifts slightly to the left as the Brightness decreases (Clouds):
image
The voltage at the Max Power for each curve doesn’t change much and is obviously panel specific.
Your 6-Volt 3.5W Voltaic Systems Panel will always produce the most Power when the load can be adjusted to maintain the Panel at 6.5 Volts, but 5.08 is our highest setpoint.
image

I dug through several PR’s and the Source Code, and combined that with posts from @avtolstoy.

I was one of the vocal one’s requesting the Disable function for System Power Manager (which is now available with rc1).
But I’m now a fan of the New API and SystemPowerConfiguration in rc1 :sunglasses:.

3 Likes

@Rftop,

Do you know of any documentation of Sleep 2.0. There is a glimpse of it in the release notes:

void setup() {
    SystemSleepConfiguration config;
    config.mode(SystemSleepMode::STOP)
          .gpio(D0, RISING)
          .duration(30min)
          .ble();
    System.sleep(config);
}

But, I would like to see the documentation. This is the last piece in the puzzle before I can complete my carrier board project.

Any ideas?

Thanks, Chip

@chipmc,
I looked back at my “starter” Code for Sleep 2.0 and noticed I had these 2 links in my Comments:

sleep_hal.h

Sleep 2.0

I hope this helps ya.

1 Like

@Rftop I see they have released the official 1.5.0 firmware with support for lower Sleep power consumption levels for better battery life.

Would love to see what your testing shows as far as actual new sleep power consumption levels.

@avtolstoy,

The requirement for a reset is an issue. So, in the case where we want to enable and disable charging based on temperature, does this mean we cannot use the new SystemPowerConfiguration API?

Thanks, Chip

1 Like

@chipmc, It’s my understanding that what @avtolstoy detailed was when you want to completely disable SystemPowerConfiguration to make the direct PMIC calls yourself.
If you intend to use the new API, you will still be able to disable charging “on-the-fly”.

From my preliminary testing (release candidate), the new API wouldn’t over-ride a direct pmic.disableCharging() call anyway…say for instance due to temperature.

I “believe” I covered all the bases, but maybe not. Please describe if you see something different.

@RWB, I’ll share my Sleep results as soon as I get a chance to test the Final.

@Rftop,

I am sure that you have covered all the bases and I am just trying to make sure I understand. As you know, I have added temperature control over charging and detailed my approach here:

In this approach, enabling and disabling charging is relatively simple and can be done each time I check the temperature.

So, it seems like there are a few approaches:

  1. Stick with the old approach.
  2. Disable power management (SystemPowerFeature::DISABLE) and then take acre of all the settings myself. I am not clear about what this entails and would hate to make a mistake here.
  3. Use the new API and the old pmic.disableCharging() just as I do today? Is this a valid approach?

Thank you for your time and explanations, I just want to make the best choice and would love to take advantage of the new API.

Chip

@Chipmc, I’d vote for #3 in your list, mainly due to post #11 in this Thread.

If you use EN Pin Shutdown or Standby Sleep Mode, you might want to “limit” the time between waking up to check the temp (if the enclosure temperature was already approaching your threshold at Sleep time).