Battery Charge doesn't work if starting when EN grounded

@ielec, great work drilling down on why enableBuck() helps !

I’m still unsure on the reasons behind the different results between landing the source on Vin/Vusb verses the microUSB Connector. It seems the only physical difference is the diode, as mentioned previously.

Now might be a great time to determine and officially document the various use-cases and how DeviceOS handles these now and in the future (if possible on the OS side).

  • Vin/Vusb verses microUSB connector
  • DC power supply (stable voltage) verses Solar Power (where DPM manages the current to maintain input V)

That’s (4) primary Input Combinations.
Throw in Mode1/Mode2 (API vs PMIC) for each means 8 use-cases.

Now consider EN Pin Shutdown, Stop Sleep, and Hibernate Sleep.
That’s 24 cases, but should cover just about any install imaginable.

But moving forward, most folks will likely concentrate on the new API, so we could scratch the PMIC calls (mode 2 tests) … and we’re back down to 12 cases to cover the Input Type & Location, along with EN Shutdown & Sleep modes.

Am I missing anything?

1 Like

Is there any update to this thread? If not, could anyone help me with a working battery charge setup for my use case? My use case:
Boron 2G/3G, OS - 1.5.2
Solar panel (6v nominal, 5W) input via VBUS pin
External timer switches Boron EN pin

I was using:

void setup() {
   FuelGauge fuel;
    PMIC pmic;

void loop() {

void Power()  {
PMIC pmic(true);
    // Delay for up to two system power manager loop invocations
    pmic.setInputCurrentLimit(900) ;   
    pmic.enableBuck();                .

But recently that has stopped working too. The orange charge light still comes on with solar input but it flickers rapidly at about 50Hz. While this is the case the SOC reads ~>95%, but as soon as the solar input is removed the SOC instantly drops to its previous low level as if it has received no charge at all. I’ve tried a 6V lead acid battery input instead of the solar for testing purposes but same result.

I have tried the API code above and cannot get that to work either.

SOC is an approximation and it takes time and a few battery cycles for the SOC number to be accurate.
You will get better data while testing by using/publishing the Li-Po Voltage instead of SOC, especially since you are performing EN Pin Shutdowns. I believe a complete Shutdown also restarts the SOC approximation in the PMIC.

I’ve tested dozens of Solar Panels for the Boron LTE, with the last 5 or so Firmware Releases.
A Panel with a USB connector (like a Voltaic 2W for example) seems to perform the best with all Firmware and physical applications, for me anyway.

But your comment below has me puzzled. I cant think of a good reason for this:

It’s been recommended to perform the detachInterrupt in a Startup Macro (not just in Setup).
My guess is you haven’t actually disabled System Power Manger.

My results (Boron LTE on 1.5.1) showed much better performance using the USB connector vs Vin/Vusb Pin for a Solar Boron using EN Pin :

  MODE 2 (PMIC) using USB Connector
  Charging works fine during and after an EN Pin Shutdown.

  MODE 2 (PMIC) using Vin/Vusb Pin
  Charging works during and after an EN Pin Shutdown, but it wont resume charging during EN Shutdown if it wasn't charging when EN Pin was pulled low (Cloud).
  Slightly different than Mode 1 Vin/Vusb.  The important condition occurs AT the time of Shutdown verses during Shutdown

Hey Rftop, you have done more with solar and Boron any anyone else on this forum - you are the guru, thanks for your thoughtful comments! Thanks for the tip on connecting the solar panel to the USB connector - that is definitely something worth trying. When you say

perform the detachInterrupt in a Startup Macro (not just in Setup)

Can you please explain what that looks like? Also, how do I ensure I have disabled System Power Manager?
Overall, it’s a bit disappointing that after nearly two years, Particle are still struggling to provide adequate support for the solar charging of the Boron. Can we please get an official update from someone at Particle on this issue?

Take a look at this post, and the entire Thread :
Disable System Power Manager

But as previously mentioned, I haven’t found a need to disable System Power Manager when charging through the USB connector.

The Startup Macro is used in the sample code in this current Thread.
It’s where I select between Mode 1 (API) or Mode 2 (PMIC).

It’s probably best to stick with the New API, especially since the Device OS firmware will likely continue in that direction.