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

Hardware
1

Hi all, I’ve updated a Boron to 1.3.1-rc.1, then 1.4.0-rc.1 to try and fix the notorious reconnection memory leak issue, and it looks like my solar charging behavior has been seriously affected.

I noticed this entry in the 1.3.1-rc.1 release notes:
https://github.com/particle-iot/device-os/pull/1846

My setup is a Voltaic 2W panel wired directly to VUSB and GND pins. It is rated for 340mA at 6.5VDC
https://voltaicsystems.com/2-watt-panel/

My application firmware has these PMIC entries in it. These were left over from some testing I was doing early on to increase charge performance, but as you can see from the comments, I kind of abandoned that when it wasn’t needed. The unit normally recharges the 2500 mAh battery within 90 min of full sun, which is more than aggressive enough.

    //Set up PMIC chip for optimal solar charging of InputVoltageLimit = 5080, ChargeVoltage = 4208
    //If LiPo doesn't charge when connected to USB, especially with long cables dial InputVoltage back to 4840 - 4640
    //If LiPo gets too hot (ambient > 113F) or explodes, dial Charge Voltage back to 4112
    PMIC pmic;
    pmic.setInputVoltageLimit(4640);
    pmic.setChargeVoltage(4112);

The first unit that stopped charging was after the aforementioned firmware update, but it is a 3hr drive away so I’ve not been able to connect locally to downgrade it and confirm solar recovery.

So instead I took a precious virgin spare off the shelf, set it up as typical, downloaded the same program at firmware 1.2.1, which is what the 7 others in the field (and still working fine) are at. Connected the solar and got a nice steady, strong LED and a status of:

"device":{
"power":{
"battery":{
"charge":71.46
"state":"charging"}
"source":"USB host"}

Sent version 1.4.0-rc.1 down, and charging LED immediately changed to a very dim very rapid flicker, and status poll reports:

"device":{
"power":{
"battery":{
"charge":40.32
"state":"discharging"}
"source":"unknown"}

I also tried removing the PMIC references above, but no change in behavior.

Is it possible that the surgery in issue 1846 has made the PMIC pull too much current and is now collapsing the cell, since it can supply max 340mA and not the 500mA of typical USB (new max is now 800mA)?

I’m not very good on the electrical side, so I’m going to rely on someone like @Rftop or @RWB or @rickkas7 that helped me with the original bits to chime in on that one.

Any ideas guys?

2

I’ve been doing a lot of Solar Panel testing with 1.3.1 and 1.4.0 lately, but with Xenon not Boron.

I don’t have a complete understanding on what all #1846 changed, but the PMIC should still obey your
setInputVoltageLimit setting. If 1.4.0-rc.1 doesn’t, then that would be problematic.

Can you try pmic.setInputVoltageLimit(5080) and pmic.enableDPDM() to see if your panel will recharge ?

3

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 :

image
image1004×556 35.4 KB

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!

4

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

1 Like
5

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

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
7

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
8

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
9

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
10

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:

image
image902×807 41.6 KB

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

image
image855×381 15.9 KB

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.

image
image686×502 22 KB

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
11

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
12

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
13

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
14

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

15

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

16

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.

17

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.

18

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.

19

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.

20

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.