//set charging current to 1024mA (512 + 512 offset)
pmic.setChargeCurrent(0,0,1,0,0,0);
Be careful with changing this from the default 512mA. I have tested it at 900mA and it was running pretty warm/hot. We dialed it back to 512mA to avoid thermal issues when the ambient temperature is high. You can measure the PMIC case temps at room temp and roughly add the difference between room temp and your max operating temp and see if it exceeds the PMIC's ratings. This is something we should characterize better in the datasheet, and then add notes to setChargeCurrent in the Docs.
Leaving the fuel gauge on adds about 200uA to the 130uA drain (330uA or so total). That might be acceptable to you, but I wasn't finding much value in keeping the fuel gauge on while I was waiting for it to charge back up again. In theory though, keeping it powered will give you the best average of what the battery's capacity is. Just know that it takes about 90 minutes to update SoC with a step change in battery voltage from (3.15V) 0% to (4.15) 95%. Not that you'll be charging in step changes but it's notable if you crank up the charging current. We can adjust this filter response (via fuel gauge programming) to match the "system" but currently I haven't spent enough time with that part of it to create a recommendation. If you are interested in looking at it, I can point you to some resources.
Even with setting the charge currents to 1 amp I never see it charge the 2000mA battery at more than 350-400mA for some reason.
I changed the charge current to see if it worked and I plan on using larger batteries. Plus when your charging off solar you want to be able to charge quickly when the sun is available on partly cloudy days so if you had a solar panel attached that could supply 1 amp of current then it would be wise to charge at that rate to harvest as much power as possible when possible.
Good to know the Fuel Gauge consumes 200uA, I need to dust off the uCurrent Gold and put it to good use.
I think I'm fine leaving the fuel gauge ON since it provides stable SOC readings vs. what I was seeing turning it OFF and ON. I would benefit from turning it off so I'll look at your sleep code and see what I can scavenge from it.
never mind, Iâm guessing if you turn off the fet the system would reset itself because total loss of power. then it would just restart and turn off again
It could but why not just automate the process via our code above so the Electron comes back online automatically when itâs been solar recharged to a safe level again.
If your not solar charging then yes your plan is better than killing a Electron, itâs going to shut down anyways.
That's probably because every time power is reapplied to VUSB or VIN, the PMIC IRQ is fired and system firmware updates the charging rate to 512mA. This solved a previous issue where it would default to 50mA and not charge up the battery if the electron was on.
Even if you do want to change the battery to a larger one, you need to respect the ability of the PMIC on the electron to do it safely and efficiently for you (re: temperature dissipation conversation).
@Dbub Interesting. So is there any way to force the charging current to 1 Amp if I wanted to and the heat from the PCIM was properly monitored and dealt with?
Currently you'd have to punch setChargeCurrent() at a regular interval to ensure it remained set. Just more often than your solar power is coming and going would be fine. You could use a Software Timer to do this. This would be a good API feature to avoid the Software Timer workaround, but as you can image lower on the priority list because it comes with a price tag of ensuring you keep the temperature managed.
My team is looking at using something like an rc circuit that pulses either the reset pin or maybe even the battery pins to simulate disconnecting and reconnecting the battery once the battery is at some certain voltage.
@calebatch Thatâs not really needed. Just use my sleep code above, it works great for me.
If you put it into deep sleep at your preset SOC level of lets say 20% the Electron will have enough power in the battery to wake up every hour and check to see if the SOC level has risen above 20% for like 20 days straight before the battery will completely die which is plenty of time to recharge it if youâre using solar.
If your not using solar to charge then just putting it into deep sleep and waking up less often will give you even more than 20 days, could be months depending on the sleep mode and wake frequency before the battery dies completely.
Our device has an lcd screen on it that can be activated in the field so battery could still possibly die. We are tripling battery strength and implementing your code. But we are also trying to make sure we can come back from worst case.
We also are having something get overwritten part of the time when battery hits 0. Several electrons have come back to us with firmware not booting. We are looking at that more today.
This might be an ignorant question, but what about on the U260/U270 Electron? Would the varying current draw make a difference? Other than that, I'm using 0.5.1 firmware.
@calebatch it sounds like this is something you are seeing more than once? I would love to talk to you about it before you try to do anything to your electrons to revive it. If you've already tried to revive these non-booting units could you describe the measures you took and what the outcome was. Also if you do not have a JTAG tool, I'd be interested in having you ship me one of your non-booting electrons so that I could do a post mortem on it.
The tests I originally performed were on a G350 which has a higher peak current, so it should represent more of a worst case scenario. The U260 and U270 both consume lower peak currents. Is there any reason you are not using the latest 0.5.x or 0.6.x firmware?
I think elevatorguy might have a JTAG tool. Weâre with the same company just made our accounts before then. We are using 0.5.1 because most of these units deployed with that firmware several months ago and their location is very remote so we donât usually have a good enough connection to update the firmware.
Also, I am sure once we get more electrons back from the field we can send you a couple.
Adding my reply to the original post to this thread as well:
Hi all. Sadly we have now experienced this as well Even worse, it happened while we were demoing our product overseas However, the reason I really wanted to post is that we may be able to add an important bit of information: Our battery was charged. It was probably around 60-70% charged. However, our product has this button on its exterior that we use to hard power off the unit: https://www.adafruit.com/products/9151
That button breaks the ground connection to the battery (battery becomes open circuit when OFF). We were demonstrating this, ie using our on/off button. We turned our product on and everything worked fine, we turned it back off and then when we went to turn the unit back on again we got the blue light of death. So in our case I am pretty sure it wasnât from a battery drain, but from the on/off cycle. Now, there is one complication to this: before re-powering after our last successful power-on our external case was opened. This should not have made any difference at all and is unlikely to have contributed to the failure, but it is a change that happened right before the failure so I have to report it.
[EDIT] Ug, I should also mention that solar panels were also connected to the Vin/GND pins, but the unit was inside so minimal I/V was coming in through these.
Mod edit (@harrisonhjones): Merged two posts (see EDIT for second post content)
@SirT sorry to hear about your troubles. Is there a basic schematic you can share for your connections? You can PM this to me if youâd like. Iâd like to better understand the power connections when the battery is opened. Would there be any difference if the battery was opened on the positive side? Your link above did not work, is this the button? and if so are you connecting the LED as well? Were you by any chance updating the firmware at all before you removed power? Or can you think of any process in your firmware that would be harmfully interrupted by removing power? Would you try completely removing power for a minute or so and restoring power with the USB only and then Battery only and see if the unit would power back on?