Voltaic 0.6 Watt Panel for BORON

I am curious to see if I can use this panel (0.6 Watt 6 Volt Solar Panel | SunPower SMT Solar Panel) with my boron systems.

I’ve tried many times in the past, and it is usually hit or miss. Now with deviceOS2.0.1 I’ve started to try again.
This is with the solar panel going into VUSB, and the standard LiPo that comes in the box going into the LiPo JST.

The panel can produce 110mA at 6.07V, I am testing in sunny Colorado with full sun.

Heres the relevant code:

STARTUP(batt_settings());
SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);
SystemPowerConfiguration conf;

...

void batt_settings(){

  conf.powerSourceMaxCurrent(110)   // for P123
        .powerSourceMinVoltage(5080) // 5.080v
        .batteryChargeCurrent(1024)  // I don't think this matters since powerSourceMaxCurrent is set at 110
        .batteryChargeVoltage(4112)  // default is 4.112V termination voltage
        .feature(SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST);

  System.setPowerConfiguration(conf); // retains these 
    
}

So with this code, some borons will have the charge light on, and some borons will just blink the charge light once every second. But even the borons that do have the charge light on, the diagnostics still say the power source is undefined and that it is not charging.

Does the PMIC not handle this low-power panel? or am I making a mistake somewhere?

Thanks.

1 Like

I’ve always understood a solar panel to require a MPPT or some sort of solar control to be able to provide any reliable, sustainable battery option, even for these low power IoT devices. I’ve never tried to run it directly. Obviously the one concern is that a cloud comes over and the whole thing dies for 2 minutes.

There are some low power solar input power trackers out there, which would be the interface (and most times with additional LiPo battery to smooth out clouds). Would be interested to see what you eventually come up with, and how it works.

Check these out for some ideas.

Regards from sunny South Africa…

@neal_tommy,

For serious applications, you are correct. However, many of us have found that adding a large capacitor on the DC-IN line from the panel and setting the correct values in the power configuration API yells a result that charges very well using the Boron’s built in power management IC.

Chip

Good to know about this suggestion! N

I wonder if I need some custom hardware for this…

Can someone chime in with what the minimum current required is to charge the Boron?

OK small update…

When I run the following code, the charge light will be on only until the code hits setup. So that delay(10000); will keep the charge light on for 10 seconds, but as soon as it hits setup, the charge light reverts back to the 1Hz blinking.

STARTUP(batt_settings()); 
SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);
SystemPowerConfiguration conf;
SystemSleepConfiguration config;
//PMIC pmic;


void batt_settings(){

  conf.powerSourceMaxCurrent(900)
        .powerSourceMinVoltage(5080) // 5.080v
        .batteryChargeCurrent(900)  // default is 2048mA (011000) = 512mA+1024mA+512mA)
        .batteryChargeVoltage(4208);  // default is 4.112V termination voltage

  System.setPowerConfiguration(conf); // retains these 

  delay(10000);

}

void setup() {
  //charge light turns from solid to blinking @1Hz right here
  pinMode(D7,OUTPUT);
  digitalWrite(D7, HIGH);
  delay(2000);
  Particle.connect();
}

@SammyG , This is strictly a guess, but maybe your PowerConfig Settings aren’t actually being used during the 10 sec delay since that’s the next operation after the changes are made and still within the Startup() Macro ?

IIRC, the charge light only burns when the charge rate is ~50 mA or more ( from memory, might be incorrect).

The 1Hz blinking “could” simply be the DPM working correctly, but just at the threshold for that particular panel and light intensity to maintain the panel at 5.08V.
I’ve seen this situation several times on my Solar Panel Test Stand, where increasing the intensity immediately stopped the 1Hz blinking pattern. The Boron was always re-charging, it’s just the LED fools ya.

You might want to try Particle’s INA219 and OLED feather (here’s a thread) for bench testing.
It removes the guesswork and tells you what’s actually being stored or sourced (to/from) the Li-Po at any operating condition. I don’t have the 0.6W voltaic to test, but my guess is 70’ish mA “net” in full sun at 5V .

If you add a POT, you can perform a curve trace for your specific panel and know what it produces at 5.08V at various light intensities. The INA219 feather is an inexpensive tool with a lot of potential uses on the test bench if you don’t have the benefit of Lab Grade Equipment.

Thanks @Rftop. I setup my INA219 rig with a photon and will test it out tomorrow.

FWIW, this same behavior is also happening with a larger, but still small, voltaic panel (1.2 Watt 6 Volt Solar Panel | SunPower SMT Solar Panel). It is a 1.6W panel producing 200mA @ 6.07v.

Snow today, will have to wait till tomorrow.

Here are some test results:

First, the 1.2W (200mA) panel under LED light bar in the lab:

I’ve noticed that when I call STARTUP(batt_settings()); , I get varying results. For example, the following code was called in STARTUP

void batt_settings(){ 
  conf.powerSourceMaxCurrent(900)   // for P123  !!!!Charge light turns on under LED bench light conditions.
        .powerSourceMinVoltage(5080) // 5.080v
        .batteryChargeCurrent(1024)  // default is 2048mA (011000) = 512mA+1024mA+512mA)
        .batteryChargeVoltage(4112);  // default is 4.112V termination voltage
        //.feature(SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST);
  System.setPowerConfiguration(conf); // retains these 
}

but basically half of the time I would get this reading, like the code just wasn’t kicking in:

Sometimes (but not every time) when I would pull the panel away from the light source, and then put it back, the charge light would come on and I would get this reading:


which is interesting because the code called for .powerSourceMinVoltage(5080). The previous program uploaded to the device WAS calling .powerSourceMinVoltage(4840), but this reading was 100% taken with the program that called .powerSourceMinVoltage(5080). After uploading the program again, I had the same issue where when it did work, it wasn’t hitting the 5.080v that it was suppose to. idk what happened here, but its not the main issue so I’m not too focused on it right now.

When I started calling batt_settings(); from void setup(), this error did not occur (and the voltage went back to 5.080 like it should).
So this may have been my problem in the original post, that the device seems very picky/ finicky when the power settings are called in STARTUP. I don’t know how this is even possible, more likely I’m doing something weird.

Now, here are the results from the panels outside in full sun.
This is still the same code. But now outside, I test both the 0.6W panel, and the 1.2W.

With the 0.6W panel, here is what is looks like with the batt_settings(); code called in void setup():

With the 1.2W panel, here is what is looks like with the batt_settings(); code called in void setup():

In both cases, the charge light is on, and after a while I can actually see the battery voltage increase. So it is in fact charging.

Now, when the code is changed to call STARTUP(batt_settings());, when batt_settings(); is no longer in void setup(), here is what I get with both panels SOMETIMES:


This is the same error experienced in the lab setting. The device is picky on which power source was plugged in first.

Panel first, then battery: error condition.
Battery first, then panel: works perfect.

In both his these cases, when batt_settings(); is called in void setup(), I can do any permutation of disconnecting the battery and the solar panel, and it never has a fault.

I was originally calling batt_settings(); in STARTUP because my devices were using the EN pin to sleep, and this seemed necessary back in deviceOS1.5.2/4.

Does it make sense to anybody how calling the power settings in STARTUP could have these weird effects?

1 Like

Well, it appears based on your testing that we shouldn’t use the API in a Startup Macro, in 2.0.1 and beyond. Good Job.

Have you had a chance to test the charging performance w/ the various sleep modes?
Hibernate caused problems the last time I attempted to Validate the Boron LTE, but that was 2.0.0.rc-1

New development.

Even when batt_settings(); is called in void setup():
If the panel (in full sun) is connected before the battery, the error will occur. However if the panel (in the shade) is connected before the battery, it functions normally.

Alright… well worst fear confirmed.

Just uploaded exact same code to a different Boron, and no matter what, this is what it gives me.
Along with the charge light blinking @ 1Hz.

:face_with_symbols_over_mouth:

Does anything change after a reset?

I’m guessing the Boron in the above post is sourcing the Panel for it’s operating current, but the PMIC has decided the required conditions are not met to start a charge cycle.

What if you call batt_settings() again after a couple minutes of runtime. If the Boron then starts charging correctly, it would suggest System Power Manager is still not playing nice with the API settings.

Nothing changes after a button reset, or a battery pull.

In the sun, the panel will power the device even without a battery, so maybe you’re right.

Tomorrow I will test with calling batt_settings(); again after 30 seconds or a minute.

Any ideas why two different devices, on the same OS, with the same code, would act so differently?

The boron that works with the solar panels is behaving well during ULTRA_LOW_POWER sleep. Tested that today for a couple hours and it kept charging as expected. Haven’t tested with Hibernate yet.

I know It’s a long shot, but are you sure you targeted the same 2.0.1 for Boron #2 ?

I can say that after hundreds of hours of Solar Testing Borons, I’ve never found the PMIC to not behave according to it’s datasheet. Device OS is full of wonderful functionality, but unfortunately the System Power Manager can cause unwanted hick-ups.

Just checked on the CLI with particle identify to make sure.

Your system firmware version is 2.0.1

The target has been set on deviceOS@2.0.1 throughout these tests.

I will triple check tomorrow and test again.

Just tested on the bench LED light again. Same problem… Even after re-calling batt_settings(): 30 seconds in. Updated the deviceOS again to 2.0.1, made sure the target is set to deviceOS@2.0.1.

In the past I have had different borons act differently when it comes to charging, but now I actually can prove it. Will test with another boron tomorrow.

1 Like

Thanks for testing that idea.

This might not be plausible for your project, but you may want to try/test using the micro USB connector instead of Vin for the Solar Panel Input. My previous testing usually ended with the USB connector being the better choice.

If you want to dig deeper, you could read the PMIC registers directly to attempt to decipher what’s happening.

Or an easier approach might be to make the PMIC calls directly in Setup() like we did in the old days, instead of using the new API to see if you notice any differences on LTS2.01.

@chipmc has graciously shared his code in this forum that works for him with his carrier board. You may want to try his FSM approach and settings. I’m not sure if he migrated to LTS 2.x.

@Rftop ,

Thanks for the mention and, yes, I am on the LTS 2.x. Happy to share anything that could be of use.

Chip

1 Like