Boron Solar Charging with 1.5.0-rc1

Hardware
21

@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

22

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
23

@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

24

@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
25

@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.

26

@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
27

@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.

28

@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

29

@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).

30

@Rftop,

Thank you, I will give #3 a try. The good news is that EN sleep, today is exclusively at night when solar charging is no an issue. However, this is good advice for future use cases.

Thanks,

Chip

31

Hi Chip, Just a quick note that I ended up having to add the old school pmic.enableBuck() back into my 1.5.0 code today because I was having really inconsistent charging go/no go behavior.

I am wired to VIN for the solar power (and a USB -> voltaic plug adapter cable for testing when the sun is down) combined with the EN switch method of turning the device on and off.

Everything works great after a firmware update (hard reset?), but then after a couple of EN switch cycles, plugging a solar panel in and walking outside would rarely activate the charger. It seems like this soft-start (you know, kind of like the sun coming up in the morning) was not enough to jumpstart the sleepy PMIC?

I also removed SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST because I realized I never connect a solar supply to the USB port, so this was unnecessarily getting in the way of an emergency charge from a portable USB battery pack in the field if needed.

Power wizards please me know if you think these changes will have any undesirable side effects!
Thx

2 Likes
32

@runfastman notified me that the WebIDE link to the shared code in my Original Post isn’t working anymore. It’s been too long for me to edit the post.

Here’s another link to the same (or similar) Code.
https://build.particle.io/build/5e443f4cfb4012000cc300fd
It’s fine with me if a MOD wants to edit the original link and delete this post.

33

This is not working either - you need to use the SHARE THIS REVISION button to create a sharable link.

34

Opps…

https://go.particle.io/shared_apps/5e4d5bfd673b2c000701acf8

35

Thanks for reposting!
It would be great is someone with the knowledge would make a tutorial on Boron with solar. There are a lot of different postings and confusing info.
Options I would like to see covered:

  • Small solar panels in mostly sleep mode.
  • Larger solar panels always on.
  • Solar and USB charge option. (For a device the user also can charge)
36

I agree, but that’s harder to do than it sounds.
A few new features have been introduced into the DeviceOS, which obviously change the operating characteristics. As these new features mature, previous tests might not be valid.

IMO, a detailed guide would only be 100% accurate until the next firmware update.

I’ve been impressed with how well the community shares individual experiences. But even a small change in the install/operation of a Solar Powered Boron can make a difference between users.

The Community could decide on a couple of the most popular use-cases and maintain 1 thread with results as the firmware matures.

I’d think a good starting point would be Voltaic Panels (1W, 2W, 3.5W) using the USB connector w/ Stop and Hibernate Sleep Modes.
Then cheap panels (0.5W, 1W, etc) landed on Vusb w/ the same Sleep Modes.
Once you add using the EN Pin to those cases, you already have a fairly large Matrix of results to maintain/update.

I agree with the idea of a Standardized Code Framework that we can all use as a Base, or Starting Point, to track the changes over time. That would make peer review easier as we share results for each use-case.

37

Update for firmware 1.5.1 with the new API

Testing 2W Voltaic Panel in Full Sunlight on the USB Connector as per original post.
Using “Mode 1” in my code, which is the new API (not direct PMIC Calls)
Using a discharged 5Ah Li-Po @ 3.8V, not the 2Ah in the original picture
The INA219 shows 1.5W (from 2W rated panel) being pushed into the Li-Po…360+ mA.
I’m very pleased with this result.

Enable charging and disable charging PMIC calls (OLED buttons B & C) are working as expected.
SOC is updating as expected.
DPDM is working, even after cycling (Shading) the Solar Panel repeatedly.

Slightly modified code, but no major changes:
https://go.particle.io/shared_apps/5eb6d8c412f99200073ff88e

I’ll let it cook for a while.

2 Likes
38

I just realized a slight issue with 1.5.1 concerning my post directly above this one.
I set the max charging current to 1024 mA with conf.batteryChargeCurrent(1024).
System Power Manager didn’t obey this setting, since the “mostly” discharged Li-Po (at 3.8V resting, 5,000 mAh rated) was being charged at 1450 mA (40% higher than setpoint) for a considerable amount of time until the CV portion of the charge profile.

Relevant Code from link:

STARTUP( selectMode() );

void selectMode()  {
  // (1) API MODE
  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);
  }

The Power Source was the 2W Voltaic Solar Panel on the Boron USB connector.
Charging Current was measured by INA219 feather from the (+) Li-Po conductor.

I love the higher charging current, but this could be a problem for someone using smaller capacity Li-Po’s (charging at a much higher rate than the API setpoint). Mainly, I wonder what I’ve done wrong for the API settings to not be obeyed.

The Good News on 1.5.1 using the new API:

  1. Disabling Charging by calling ``pmic.disableCharging();` (button “B”) appears to work 100% of the time. Tested fine throughout the entire Voltage Range of the Charging Cycle.

  2. Re-Enable Charging (button “C”) seems to work ~95% of the time. I haven’t collected enough data to characterize the conditions when this fails. But when it does fail to resume charging, calling pmic.enableCharging(); once or twice More (button “C”) seems to work. That makes me think that locking the PMIC call (per other forum posts) may be the answer when using the new API.

However- the ~5% “failure” has only appeared towards the end of the Charging Profile, although all conditions to allow charging are met (as far as I know). When this “failure” occurs, I can briefly cover the Solar Panel to force a Li-Po Source ONLY, and the Boron will usually resume charging when the Panel begins producing current again. So there’s a good chance the PMIC is operating correctly and I’m just forgetting something from the datasheet that happens towards the end of the charge profile. I’m leaning towards this not actually being a bug/issue.

I haven’t been able to reproduce the charging issues others have mentioned with 1.5.x.
Since my test rig is running Manual Mode (no modem) and no Sleep, those problems are likely related to how the PMIC is managed by the System Power Manager during/after Sleep events ?
Even if the Modem gets in a funny power state, that shouldn’t impact the PMIC performance.

The only issue in regards to Solar Charging on 1.5.1 (without SLEEP) that I’ve seen so far is the charging current can be higher than the API set-point when using a Solar Panel (current producing) during DPDM operation (vary the Current to maintain min V across Panel) while charging a “discharged” Li-Po during the CC (Constant Current) phase of the PMIC’s charge profile. That’s a pretty specific circumstance that’s easily mitigated by proper Panel and Li-Po selection.

[EDIT] - I spoke too soon. The API wont obey the charge termination voltage, in my code .
Charging stops at 4.10 - 4.11 V even with my .batteryChargeVoltage(4208) call in a Startup Macro. The Boron still operates at the default 4112 mV setting.

The call for .powerSourceMinVoltage(5080) does work perfectly when using the USB Connector with my Startup Macro. The PMIC maintains the current to prevent the Panel Voltage from collapsing. The 5080 setting could just be persisting from previous User Firmware Flashes ?
But the other (3) parameters are having problems for me:

  • .powerSourceMaxCurrent(900)
  • .batteryChargeCurrent(1024)
  • .batteryChargeVoltage(4208)

So I removed .feature(SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST) ; which could likely be the culprit. No Luck.
I also tried to restore the default configuration prior to making Changes. No Luck

void selectMode()  {
  // (1) API MODE
  
  // Added 05/10/20
    System.setPowerConfiguration(SystemPowerConfiguration());  // To restore the default configuration before making changes

  if (myTestMode == 1) {
    conf.powerSourceMaxCurrent(900)
    .powerSourceMinVoltage(5080)
    .batteryChargeCurrent(1024)
    .batteryChargeVoltage(4208)
    .feature(SystemPowerFeature::PMIC_DETECTION)
  //  .feature(SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST) ;  // removed 05/10/20
    ;
    System.setPowerConfiguration(conf);
  }

I now realize that my previous charging results are Invalid due to using the USE_VIN_SETTINGS_WITH_USB_HOST feature, but I must still be missing something important with the New API calls.

Any Suggestions ?

39

UPDATE for Device OS 2.0.0.rc-1 , Boron LTE

Using the same bench setup as the Original Post.
The LED Test Light Stand at the current configuration produces 119 mA @ 5.08V (606 mW) using the Voltaic 2W panel placed at a repeatable position. So 606 mW is the available Solar power for the tests below.

Using the USB Connector for Solar Input results in the following entering the 2aH Li-Po @ 3.95V:

Awake            116 mA     458 mW
Stop             122 mA     482 mW
EN Pin           122 mA     482 mW
Stop w/ Network  
Hibernate        123 mA     483 mW

That’s ~80% of the available panel power being stored into the Li-Po… not bad.
All modes maintained the Solar Panel at ~5.04 V, so DPM still works.

3 of the 4 modes handled the Cycling of the Solar Panel Output to simulate Clouds.
Hibernate Sleep will wake the Boron LTE when the Solar Panel Cycles (not good).
DPM also gets wonky after a Cloud wakes the Boron from Hibernate.

A side note: using Stop Sleep with Network Standby results in 10mA of sleep current (seems too high). If your external watchdog performs an EN Pin Shutdown during this, the PMIC will have problems with DPM. I realize that’s an edge-case.

I also tested a 6V DC Power Supply using the same API settings for comparison:

*6V PowerSupply  255 mA    1060 mW

Power Configuration settings used for all tests:

  conf.powerSourceMaxCurrent(900)
      .powerSourceMinVoltage(5080)
      .batteryChargeCurrent(1024)
      .batteryChargeVoltage(4208);
  System.setPowerConfiguration(conf);

Solar Charging through the USB connector w/ 2.0.0.rc-1 appears good so far, but there are still some quirks with this release that need investigation prior to official roll-out.

Particle only gets 1-shot at the initial LTS release.
I’d recommend more physical testing prior to leaving Release Candidate Status.
For the past 2 years, I’ve tried to get Gen3 hardware to pass Validation Testing (prior to a 2-week Trial) so I could use Gen3 in Industrial Environments.
I have high hopes for LTS 2.0.0, but it’s still not ready due to a lack of physical testing(IMHO).

I’m going to perform detailed testing for Stop Mode and EN Pin Shutdown, mainly to stress test the API and PMIC as a Li-Po nears the termination voltage under different operating conditions w/ DeviceOS 2.0.0.rc-1. I hope Particle will do the same :sunglasses:

I know that not everyone is concerned with Solar Recharging, but we’ve seen in the past that some of the issues discovered in Solar Tests also show up with a Boron on AC/DC power supply.

Cheers !

3 Likes
40

I have a TI BQ4050 battery management chip that communicates over i2C like the PMIC chip on the Boron.

The Bq4050 communicated fine on the Photon but not on the Gen3 devices unless I put the BQ4050 chip into 400khz I2C mode to be able to read the chip correctly as some other guy told me to try this after having the exact same issue.

I’m not sure what is going on or if the TI PMIC chip also was or is having issues communicating over I2C. I

m not sure if Particle has made communication changes for the PMIC in the HAL but something looks to be different as far as I2C communication with TI Smbus chips from my and others experience which were not there on the Photon and Electron.