I have been working to optimize the battery life of my Solar powered Electrons. I have noticed the sleep state and time I wake each hour is having an effect on the rate of charging. Here is what I see:
If the Electron is awake and I start charging, it can draw up to the default 500mA of current at 5V.
If the Electron is asleep and I start charging, it will only draw ~90mA of current at 5V
So far so good as this behavior has been covered in other posts. Here where I see two distinct behaviors:
When I wake from SLEEP_MODE_DEEP for very short (100mA) periods to pet the watchdog and go back to sleep, the charging rate stays at ~90mA.
When I wake from regular System.sleep(), I stay awake for 3 seconds and once the Electron goes back to sleep the charging rate is the full 500mA.
Why this matters: My plan if the battery level ever gets critical is to go into SLEEP_MODE_DEEP and let the battery charge enough to enable normal operations (checking each hour). It would be helpful in this case, if I could get the higher charging rate.
Is there a command I should execute when waking from SLEEP_MODE_DEEP to enable the charging rate to increase before going back to sleep?
Are you using the code I provided a while back or something different?
I ran the code in Setup that forced the PMIC to charge at higher rates and all I had to do during the day was run that setup code one time while the solar panel was feeing voltage to the Vin pin to keep the PMIC charging at the higher rate all day long.
As long as the voltage from the solar panel was seen by the PMIC it would not revert to the lower charging rates, soon as solar panel voltage dropped to zero volts you had to run the PMIC increase charging current code again since he main firmware would always write the default charging current registers.
I have made some changes but, it is based on what you originally sent. Here is the PMIC code I run at startup:
power.begin(); // Settings for Solar powered power management
power.disableWatchdog();
power.disableDPDM();
power.setInputVoltageLimit(4840); //Set the lowest input voltage to 4.84 volts. This keeps my 5v solar panel from operating below 4.84 volts (defauly 4360)
power.setInputCurrentLimit(900); // default is 900mA
power.setChargeCurrent(0,0,0,0,0,0); // default is 512mA matches my 3W panel
power.setChargeVoltage(4112); // default is 4.112V termination voltage
power.enableDPDM();
So, it does not seem to be required when normal sleeping - only from DEEP sleep. The voltage from the panel may well go to zero (overnight) so, you are saying I need to rerun this upon waking from DEEP sleep if I want the charge rate to increase?
Couple questions as I try to reduce the amount of code run during these hourly awakenings.
Do I have to run all these commands?
Should I put a conditional such as power.getChargingStat(); so I only run this code when it is charging anyway?
Also, one more question now that my little Electron is out in the park, there is thermal management right? I have a temp sensor on the carrier but I am assuming there is thermal regulation to prevent charging outside the 0° - 45° C range - right?
Anytime the SMT32 processor starts up from scratch the default Particle firmware and settings for the PMIC are loaded which is why it will always default to the 50ma charging rates unless you push the charging current up in the setup code.
Your new PMIC settings will stick as long as the PMIC does not loose voltage on the Vin pin, and if you do not restart the processor from scratch where the default Particle firmware settings overwrite the PMIC registers which will cause the charging current to revert back to 50ma.
That make sense?
Yes, that's correct.
Running this code happens so fast it should have zero impact on power or time consumption and only increase charging speeds.
I do not think that is necessary. I ran the code I provided with a 3w solar panel for like 3 months into the winter and it worked perfectly fine solar charging wise.
The only issue I saw was eventually it would act like it was sending data to Ubidots but that data was not received by Ubidots, I assume this was a cellular issue, a battery pull was required to reset the modem, although Rickkas's AT command to reset the modem via software would have probably worked also.
From looking at the temp sense TS pin on the PMIC for the Electron it looks like they did not add a temp sensor to the design and just hard wired a resistor divider to always say the battery temps are in a safe range.
So no charging will not stop when temps drop below 0F and that's exactly what I expereienced last winter when I was testing my Electron with 3w panel. It charged just fine during the winter from solar so I would not worry about it too much.
Does the PMIC lose it's config when the power is removed? (even if the Electron is not sleeping)
Is the PMIC simply defaulted back because the Electron has effectively rebooted when coming out of deep sleep?
I would like to know if I have to "refresh" the PMIC config on re-establishment of VIN. even if not sleeping.
Thanks
Marshall
EDIT - Just saw your response come in
Your new PMIC settings will stick as long as the PMIC does not loose voltage on the Vin pin, and if you do not restart the processor from scratch where the default Particle firmware settings overwrite the PMIC registers which will cause the charging current to revert back to 50ma.
It does not lose it's config but the default Particle fimware will overwrite whatever has been set in the PMIC chip every time you boot up the Electron.
If you set higher charging current and then go to sleep the higher charging current will remain if it has voltage on the Vin pin while going into an OFF or Deep Sleep state. Soon as Vin drops out it reverts back to the 50mA charging rates for some reason.
I would just run this higher charging current code in setup and always put my Electron into Deep Sleep with Network Standby mode and wake up and send data every couple mins for testing.
When the battery hit 20% SOC would just wake up every hour running that same PMIC higher charging current code in Setup and start running my normal code again soon as the battery SOC went above 20% again. This way every hour I was making sure the PMIC was forced into the higher charging current modes which made sure the solar panel was not operating in 50mA charging mode for any more than 1 hour when the sun came up.
I’m finding that if the voltage on the VIN comes up too slowly the PMIC is not starting properly. To attempt to overcome this, I’m measuring the supply volts on VIN, when the volts drop to below a threshold (4000mV in my test case) I disable VIN on the PMIC using the disableBuck, when the sun comes up the next day there is no load on the panel (as the disableBuck is set) and it can float to it’s open circuit voltage, when it reaches a decent level. I re-enable the Buck.
From your comments above I was thinking that when I re-enable the buck I might as well squirt down my config to the PMIC to make sure it has the charge settings again as well.
Edit:
For your reverting back to a low charge current issue, perhaps it is because the PMIC has a charge timer on it, it will run for 8 hours and then stop charging.
I disabled it - you have to write the register directly as the code for the PMIC is not complete. I was going to put it in the PMIC file, but that is another lesson in how to locally compile and submit the changes etc
Here’s my code.
void battery_pmic_disableSafetyTimer(bool disable_safety){
uint8_t DATA = pmic_readRegister(CHARGE_TIMER_CONTROL_REGISTER);
if (disable_safety == true){ //don't stop charging
DATA &= 0b11110111;
}
else{ //enable the input setting the HIZ to 0;
DATA |= 0b00001000;
}
pmic_writeRegister(CHARGE_TIMER_CONTROL_REGISTER, DATA);
Not sure what I would do without your advice on Solar.
Why am I disabling watchdog and DPMP - I copied the structure of these statements from some code the @BDub shared. I don’t think the DPMP thing is an issue as I am not powering from the USB connector. As for the watchdog, it was the one source of errors (flashing red light) and since I put this code in, I have not had that error. I can do some experimenting when I get back home (in a couple weeks).
I have modified my code to run the PMIC lines when it wakes from DEEP in the morning and when it wakes in the LOW_BATTERY_STATE. Will do some experiments to make sure but, it seems like a logical step.
I guess you are right about this code running quickly so will run it without modification or doing a charging check.
Vert disappointing about the temp circuit. I guess I could add some logic to my code to check the temp and disable charging when it is too hot or too cold. Given this is Raleigh, I have till Jan to put this in place. I wonder what the thinking was here as thermistors are very cheap and require not more effort to place than a resistor. Will need to see if the E0 has a similar limitation. Perhaps this is a reason to switch.
I think the biggest issue is that usually the thermistor is attached to the actual battery to measure the actual battery temp and not the ambient or board temp. Normally a battery temp sensor is not placed on the actual PCB because it can be affected by other components like buck converters that generate heat.
If you have any spare pins you could measure temp via a thermistor attached to the battery via the Electron pins. Personally, I would just let it run without temp set points since the charging currents are so low. If the charging currents were higher I would for sure enable it but with the lower currents, it's harder to affect the battery chemistry that higher current levels can.
I'm positive this is the same setup that the E0 has. Easy to measure temps via a spare pin though if you're worried about it. Or you could attach wires to the solder pads on the Electron but if they are using 0402 sized resistors that's not going to be fun. You would have to check the firmware setttings for temp thresholds on the PMIC also since it is a programmable setting.
Makes sense, I guess this was an engineering trade off. That said, a thermistor on the board even if not perfect seems better than “tricking” the charge controller into thinking all is well.
Something to consider for the next rev. The good news is that I have 6+ months of temperature data and have stayed inside the temp profile so far - love that NC climate.
