1.3.1-rc.1+ change to Boron solar charging (via VUSB) behavior

It appears 1.4.0 may manually override the user’s pmic settings (as you suspected @epbwhiz), but that’s why we have Release Canidates :

This “fix” might be a step backwards for Solar Powered Borons (power critical) where the only benefit is to increase charging current to mains powered Borons (unlimited power source, IE: not power critical).

Who can we tag to answer the question:
Can we eventually set a “Solar” Flag for the PMIC to not use the 1.3.1 modifications that override
setInputVoltageLimit, causing a Solar Panel’s voltage to collapse?

Solar Panel Users actually would benefit from access to a higher setting than (5080), but dropping setInputVoltageLimit to (3880) despite the User’s PMIC settings seems detrimental.

Thanks!

I'd think @avtolstoy would be a good choice.

1 Like

@ScruffR @Rftop We do have plans to introduce an option to disable system power manager and let the user application control the PMIC on its own completely, however not in 1.4.0. System power manager will be interfering with and overriding settings the application might be setting and it has been doing so since the introduction of this feature unfortunately.

As a workaround I may suggest trying to disable the interrupt for LOW_BAT_UC:

void setup() {
    detachInterrupt(LOW_BAT_UC);
    // Delay for up to two system power manager loop invocations
    delay(2000);
    // Change PMIC settings
    PMIC pmic;
    pmic.setInputVoltageLimit(4640);
}

This might be needed to be executed after waking from STOP mode sleep as well.

5 Likes

Users already had several options to increase the Charge Current above 500 mA for special cases when required, see post: (use USB Connector, tie Data Lines, etc) and everyone could still operate remote Borons w/ Solar Panels prior to 1.3.1.

@avtolstoy , Thanks for the Reply. I’ll give that a try the next time I have a Boron on my test rig, unless @epbwhiz beats me to it :wink: .

1 Like

While I can understand that the solutions outlined worked, there was still a chance even before 1.3.1 that the system power manager would override the application PMIC settings.

Another potential solution would be to listen to undocumented battery_state and power_source system events and perhaps attempt to check and modify the PMIC settings if required whenever something changes.

3 Likes

Thanks for the quick response fellas! I’m getting a solid charge light, and a climbing charge % !

To make the root cause more difficult to determine :slight_smile: I shotgunned all suggestions into one code update:

detachInterrupt(LOW_BAT_UC);
delay(2000);
PMIC pmic;
pmic.setInputVoltageLimit(5080);
pmic.setInputCurrentLimit(2000) ; 
pmic.setChargeVoltage(4208); 
pmic.setChargeCurrent(0,0,1,1,1,0); 
pmic.enableDPDM(); 
pmic.enableBuck();

And like I said, the battery is charging, but the result in the status message is interesting:

"power":{
  "battery":{
    "charge":93.92
    "state":"discharging"}
"source":"unknown"}

I’ll let somebody else worry about why the state and source is wonky.

Now to figure out which of the 5 things I changed actually made the difference…

Thanks again!

1 Like

Well that was quick - the detachInterrupt(LOW_BAT_UC) is critical to this issue. As soon as I remarked it out, the charger reverted back to the dim flashing original behavior.

I’ll leave the others in as tuning parameters for performance though.

Thanks again @avtolstoy

2 Likes

I looked through system_power_manager.cpp today.
Hopefully this is the correct location:
https://github.com/particle-iot/device-os/blob/develop/system/src/system_power_manager.cpp

I would love anyone to comment or correct my following assumptions concerning a Solar & Li-Po Powered Boron.

There are (2) lines that impact a Solar Recharged Boron, Line #167 and #191:

The Goal with a 6V Solar Panel is to have the PMIC manage the current to not collapse the Panel’s Voltage. The highest available setting at the moment is 5.08V via pmic.setInputVoltageLimit(5080);

However, performing the detachInterrupt(LOW_BAT_UC); in setup() as per @avtolstoy suggestion appears to circumvent the issue. Thanks Again!

He mentions this might need to be performed again after a STOP mode Sleep, which I assume comes from the initDefault() call on Line #84

Looking at initDefault(), it appears to NOT change setInputVoltageLimit, so no harm here.
It will however change the Li-Po termination Voltage, which is the safe bet for a Default.
So we would need to set pmic.setChargeVoltage(4208); again after a Stop Sleep, for users that can monitor temps and safely charge to 4.20V.

From my limited understanding and research, it looks like this is a viable approach to getting Solar Borons “Back-to-Normal”.
Any comments or suggestions are greatly appreciated.
Thanks

1 Like

Hey everyone. Just wanted to give an update that we have a PR which will be included in the next DeviceOS release that changes and adds a few things:

  1. We’ve reverted the changes to the default PMIC settings we use when powered by VIN. These are now again 3.88V min, 900mA max for the PMIC to enter DPM mode and reduce current consumption.
  2. When powered by USB host or USB-compliant adapter, the current limit is automatically negotiated with the other side and voltage input limit is still set to 3.88V.
  3. Another addition is a higher level power configuration API allowing to notify the system about the expected PSU parameters. These settings are persisted and work correctly even without the application running (e.g. while the device is in safe mode). See ‘Example App’ section for the example usage.
  4. The PR also adds a couple of methods to query current power source, battery state and state of charge more easily. See ‘Example App’ section as well.

In general, if your power source cannot go below 5V and can supply maximum 1A of current, all that is required is the following code block which will store these settings in the persistent storage:

    SystemPowerConfiguration conf;
    conf.powerSourceMaxCurrent(1000).powerSourceMinVoltage(5000);
    System.setPowerConfiguration(conf);

This can be run in STARTUP() block as well. There is no harm in keeping it in the application forever, as the settings will only be overwritten if there are any changes to the already stored configuration.

As this is a feature that for now only exists in the form of the PR, one for now may use Workbench deviceOS@source feature to build out of ch42646/power-management branch.

3 Likes

Thanks @avtolstoy for working on this - fingers crossed for a successful merge and release so we can get the Particle solar train back on track! :+1:

1 Like

I’m having some issues with the power manager that aren’t solar related. Our application does not use solar.

We do the following power management:

  • Enable disable charging for ambient temperature
  • Enable disable batfet for ambient temperature
  • Disable watchdog, then sleep and wakeup for LOW_BAT_UC. We do this for a wake on power feature.
  • We have a coprocessor that has the ability to power cycle the electron via LiPo and VUSB

Our application was running OK until we started upgrading devices to 1.0.1 then 1.4.4. The problems we are seeing are:

  • Buck is being disabled. We have to manually reenable in our application
  • Charging is being disabled, we cannot reenable in our code without your workaround here. Devices seem to get stuck in a weird state where battery_manager thinks the battery is disconnected, then it won’t go back to charging.

Is the intention with battery_manager for the user application to avoid making settings changes to PMIC? Is there a way to disable battery_manager? I don’t see that option implemented in your PR.

1 Like

@hwestbrook, I agree, the issues are NOT limited to Solar Borons.
I'm planning on starting a new Thread that contains all my test results for the Boron's, with the hopes that compiling/discussing the issues (that started to appear in 1.3.1) in one place will help find the answer.

In the meantime, here are a few links:

I have many projects sitting on the Shelf because of 1.3.1 firmware and newer.

Its my opinion that Particle assumed (incorrectly) that these issues were only for Solar Recharged Borons which is limited Scope/Customers. Hopefully the Boron will get the attention it deserves in the near future after the smoke clears from the Mesh :wink:

@Rftop in the same vein of putting together a new thread with your test results, I have been thinking it may be helpful to put together a current best setup/practice for borons that are are setup for remote locations with solar power etc.

For example general current best setup could be described as:

  • Firmware: 1.1.0 (I believe the consensus is that 1.1.0 is the best current update that still behaves well with solar)
  • Panel Wattage: 1W (6V panel)
  • Lipo Capacity: 5000 mAh
  • Sleep Cycle: System.sleep(D1,RISING,SLEEP_NETWORK_STANDBY,600); (network standby w/ 5min sleep interval
  • PMIC settings: pmic.setInputVoltageLimit(5080); // for 6V Solar Panels
  • Antenna setup: Aftermarket antenna and pigtail

What do you think?

Just to be clear — these are issues I’m having with Electron 3G and Electron LTE. It makes sense the Boron and Electrons would share the issue as they have essentially the same charging circuit. Electron users probably aren’t complaining because most haven’t upgraded to these later firmwares. We wouldn’t be upgrading to these except for we need support of LTE on Electron.

I think this power manager program has pretty serious issues for all of the cellular particle devices.

I’d like to know what particles firmware team intends for us to do with battery manager — it would be nice if they outlined what use case they were thinking of when they implemented these features and how we should be interacting with them. There is almost no documentation related to PMIC.

Have you tried running the new PR that @avtolstoy posted above? I have it running on a (solar powered)
Boron and charging is back to normal.

The ideal setup would always have the device running the latest DeviceOS. Running 1.1.0 puts you at risk of bricking your uBlox due to lack of changes brought later on. LTE is also a lot less reliable <1.2.1.

PR 1992 introduces the power manager, and you can run it on a custom DeviceOS build if you cannot wait for DeviceOS 1.5 that is due in the next week.
This has solved the issue with Solar charging, I have been testing it for two weeks now.

Hi @hwestbrook ,

@avtolstoy indicated documentation will be provided once DeviceOS 1.5 is released. The focus right now is to get everything ready, tested and released.

Reviewing that PR, I don’t see where I can disable this new power management scheme. I see there is a new flag HAL_POWER_MANAGEMENT_DISABLE but its got a TODO label and I don’t see that it is implemented.

What I am trying to get at in my last post is that Particle has completely changed how it manages the PMIC between 0.6.1 and 1.4.4 and not provided any justification or use cases.

  • What problem is being solved with this new PMIC management?
  • How are users intended to interact with it?
  • How did Particle gather requirements for these changes?
  • How is Particle messaging breaking changes?

We are trying to implement a PMIC scheme that seems pretty simple and well within the abilities of the Electron:

  • LiPo charging enable / disable based on temperature
  • Sleep and then wake on power source changes

Is this possible? Its unclear to me after reviewing that PR.

I don't use Workbench, so I'll wait a week instead of using the PR.

I'd also suggest a repeatable approach to future testing, maybe even using the Tripler, OLED, and INA219 from the Particle Store (so we can all perform tests using standardized and inexpensive equipment). Those (3) items plus a pigtail make quick work for checking the Current entering and leaving the Li-Po, as well as Vin. Works great for everything except drilling down on the Sleep Current.

I typically set my Minimum Input Voltage for the PMIC in the Code, and use a variable power supply to sweep through a wide input voltage range, and record the V, mA, an mW, entering the Li-Po (3.8-4.0V) throughout the Voltage Sweep. After about 1 min I'll have the Boron enter Sleep for 1 minute. The Charging Results are also recorded during and after the Sleep event.
Remove Li-Po and replace for a spot check.
Shutdown via EN Pin for another spot check.

Then change the Min Input Voltage in the Code and repeat all tests, etc, etc, etc.

IF everything seems in order, I'd try a Li-Po at a low voltage, maybe 3.5V to confirm nothing funny happens.

I'm sure others will add to those suggestions, but that's what I'd consider a minimum before releasing a Candidate.

@hwestbrook, I believe I remember one of the reasons was an attempt to have the Boron and Electron’s charging characteristics more aligned. And the ability to operate a Boron 2/3G without a Li-Po.