I have several versions of Code for Trial #1 (Solar) where I made adjustments.
I’m not sure which one was the “Final”. I need to look at those closely.
As you know, sleep modes are available now which makes Trial #1 almost obsolete.
Sub-mA Sleep currents on the first firmware update means we’re better off using Sleep when Solar is an option IMHO.
However the PMIC adjustments and temperature monitoring for Li-Po charging are still valid with Sleep Modes + Solar.
Trial #2 was a cold start every minute. Be aware that the Cellular Data Reporting wasn’t working in the Particle Console for several weeks around the time of this test. So I have no idea how much Data this actually used with the cold starts every minute. The SIM data usage spontaneously ramped-up after the trial was over and the Boron had moved on to other duties.
Please Note: Boron LTE’s stopped working on My local Cell Tower about 2.5 months after Trial #2.
I don’t know if these are related.
I’m glad we have the results for 3xAA without waiting a year for the batteries to deplete, but I don’t see any need for someone to repeat it with such an aggressive 1-minute interval ( no idea if that was your plan, just sharing my thoughts ) .
@Backpacker87 reported ~ 5MB/month for a Boron waking every 5 minutes using the EN pin & external timer.
It appears NOT connecting the the Particle Cloud helped significantly with data usage, per the thread below.
This is good news, as I wasn’t able to measure Data usage for Trial #2 during my battery tests last year when the Console had hiccups with Boron Cellular Data reporting.
Since the Data usage question seems to be answered now, here’s some more examples for a project that requires primary batteries:
A power budget for my location would be calculated using any publish schedule (1 mWh each publish) and the Quiescent current of 7.5 mWh per day.
The L91 is rated at 4,500 mWh for a 100 mA constant load (for the time spent connecting & publishing).
From looking at various discharge profiles, it’s safe to assume in excess of 5,500 mWh for the 76 µA shutdown current (just as a point of reference).
If you left the Boron LTE in standby mode, and never pulled the EN Pin high except for an Alarm/Emergency Condition, 3xAA batteries would last 2 years waiting until it’s needed (7.5 mWh per day to reach 5,500 mWh rating for shutdown current).
But most of us will want to send data at some scheduled interval for most projects. For a 2-hour Schedule over 1 Year:
Operating: 1 mWh per Event * 12 Publish Events per day * 365 days = 4,400 mWh
Shutdown: 7.5 mWh per day * 365 days = 2,700 mWh
Total = 4,400 + 2,700 = 7,100 mWh.
7,100 mWh requires 6xAA in a 3 Series, 2 parallel configuration. (2) sets of 3xAA.
That leaves you 30% additional capacity for a safety factor, or an increased update rate.
For 3xAA only @ 1 hour Shedule:
Works out to be ~ 5 months before the 3xAA L91 batteries need replacing.
Operating: 150 days * 24 publish Events * 1 mWh each = 3,600 mWh
Shutdown: 7.5 mWh per day * 150 days = 1,125 mWh
Total = 3,600 + 1,125 = 4,725 mWh.
4.20V would be the Battery Alarm Threshold for 3xAA, to start sending a notification that 3 new batteries are required.
Note: The 1 mWh per Startup/Publish Event will likely be reduced if not Connecting to the Particle Cloud each cycle, by pushing data directly to your backend service (as @Backpacker87 did with Ubidots to minimize Cellular Data on each Event).
A comparison to the initial Sleep Mode in 0.9.0:
System.Sleep uses 700 - 800 µA Sleeping Current, or 10x that of Shutdown via the EN Pin.
But System.Sleep will continue to improve.
IMHO, for Projects with Solar or other recharging methods, Sleep Mode is the clear winner.
For power sensitive battery projects, the external timer wins.
Since the EN pin is not a GPIO pin of the main controler but the enable pin of the switch/regulator (which is meant to deal with higher voltages than its output voltages) there is no risk in that (as long you stay within the specs of the switch/regulator.
Quick question, when the TPL chip pulls EN low to disable the Boron, where does the program resume when the EN returns High via the timer? Doe the program pick up where it left off in the main loop ? or does it reset and run the setup again?
Here’s my understanding:
While operating, the PMIC decides if all the requirements are met for a Charge Cycle.
Once started, that Charge Cycle will continue even after a EN pin Shutdown, until the Cycle is completed or interrupted. The Boron will need to Boot before another Charge Cycle is started.
For instance: A Solar Boron will continue to recharge after EN pin Shutdown until the Panel Voltage collapses (significant Cloud Cover).
[Edit] But if your project has a Power Source Available for recharging, why not just use Sleep Mode instead of EN Pin ? The Boron can Sleep @ < 1 mA.
What’s interesting is that I can get the charge light to come on after the device is disabled when I plug in a usb powered by a wall charger… but when I plug in the usb from my Mac the light doesn’t come on…
Yes I’ve been looking at stop mode sleep vs this enable pin… hitting the enable pin just seems to be more efficient.
My devices are solar powered and go out in some remote places. They read a lot of sensors that can draw decent current. Also in some locations like northern Canada, there may be a number of days where I can’t charge the batteries because it won’t get above freezing. Using the enable pin will virtually ensure that I will never have a power failure.
I saw your thread about the sleep current in stop mode, and it looked like you could get down to 1.2mA… have you found out how to get any lower since?
I’ve never noticed that, but I just tried and confirmed.
My Guess is that during EN pin Shutdown, the PMIC reverts to it’s default/basic configuration.
The results would suggest that the Minimum Voltage or Current isn’t being met with a Computer USB port, but can be met with AC/DC charger, which makes sense.
But I seem to recall confirming that the user defined PMIC settings were obeyed after EN Pin shutdown… at least back in 0.9.0 firmware days. I could be remembering incorrectly.
System Power Manager can now change all your PMIC settings behind the scenes now, which significantly hurts Solar Powered Borons. I’ve paused my work with Solar Boron’s for now until that’s addressed. Most of my long term testing is invalid now.
Of course, a 12V Panel charging a SLA is still a good option if you have the space.
I’ve done some digging today, and apparently detaching the Interrupt shouldn’t cause any unforeseen problems. I’m going to ask a few questions in the previous Thread dealing with detachInterrupt(LOW_BAT_UC) and Solar Charging a Boron later today.
[Edit] Link to Post, for clarity.