Shockpad battery selection and runtime prediction

This is a continuation in the Shockpad series. Past posts include:

• codename: Shockpad
• Measuring the impedance of a coin cell
• Current pulses, source impedance, and LTSpice
• Developing a current-draw profile for an intermittent radio
• Choosing a battery for your electronic circuit

Now, for the grand finale in current draw and battery selection, I'll share my spreadsheet which takes in information about the electronic circuit, various battery types, and a product's profile. Using this data, run-time on a fully charged battery can be predicted, and the benefits of various design decisions may be weighed.

The Goal:
Since the key output of my spreadsheet model is run-time, I should share some rough targets. The goal of Shockpad is to be a rugged outdoor product which is immune to dirt/water and does not require regular service/charging. This implies the following general User Needs:

• Fully sealed enclosure - no dust/water ingress (IP67)
• Light weight
• >1 year of use (on a single battery)
• 8 hours per day active use

Using these goals, my baseline assumption is that the radio and battery are fully connected, sealed in the enclosure, and run continuously. Let's see how the modules' baseline performance values compare.

EZ-Key

LightBlue Bean

I've already editorialized a bit in the images. The EZ-Key doesn't look like much of a contender. With an average current draw of 24.24mA, powering the EZ-Key with a CR2032 battery is completely out of the question. Due to the EZ-Key's 2.4V minimum requirement, 3x AAA or AA alkaline cells would be required (versus 2x for the LightBlue Bean). Improvements are certainly possible, but the EZ-Key is starting off at a 100x disadvantage relative to the LightBlue Bean. Therefore, I chose to exclude the EZ-Key from all future analysis.
Of the scenarios above, only a LightBlue Bean powered by an 18650 lithium battery delivered run-time in excess of one year. But, that 18650 cell is also large, heavy, and unavailable to the average consumer. Below, various design improvements will be modeled, with the motivation of increasing run-time and

Turn it off

For simplicity, the baseline analysis assumed that the module would be powered continuously. But, the user needs only call for 8 hours per day of use. If a hardware on/off mechanism were added, then the system's power consumption could be reduced by 66% as shown below.

With this improvement, the user needs can now be satisfied by 2x of either AA or AAA. Alternatively, a software-driven improvement is considered below.

Make it smarter

In the original baseline, there is another important difference between the EZ-Key and the LightBlue Bean. Both modules spend the bulk of their time in the idle state. But, % of Power Budget is a different story. Whereas the EZ-Key consumes 99% of its power at idle, the LightBlue Bean consumes just 9%. Because the EZ-Key is already consuming most of its power in the idle state, increasing it would have little effect. But, if we can extend the Bean's idle time (make active events less frequent), then run-time could go up signficantly. In other words, this scenario assumes a firmware effort to increase the Bean's connection interval to 4s (from 40ms).
The original connection interval (40ms) was faster than any human is able to press the button. But, a 4s connection interval is quite slow. Problematic scenarios now include delayed response and multiple user actions between connections. Therefore, this firmware effort must also assume extra unscheduled transmissions whenever a button is pressed. I've assumed 240 button presses per day for this analysis.

• Converting to milliseconds, 240 presses/day = 360,000 milliseconds between each press
• Recall that the system is also transmitting once every 4000 milliseconds, without any press.

Combining these facts in the model, the run-time prediction yields:

Whereas the on/off hardware upgrade offered a 3x improvement over baseline, the firmware upgrade promises nearly a 10x gain. Even the diminutive CR2032 coin cell nearly meets our one year run-time target.

Do it all

If both the hardware and software upgrades are implemented, then the run-time improves further still:

As expected, the on/off mechanism supplies a 3x improvement. The system will now run off a CR2032 coin cell for 2.4 years.

Conclusions

The user needs outlined above are achievable, but not without firmware/hardware efforts. Domain experts should be consulted, prototypes constructed, and experiments run to determine whether some/all of the proposed improvements are viable. Using two AA batteries, the performance goals can be easily met. A CR2032 may be viable, if all proposed improvements are implemented.
This analysis also shows why the new Bluetooth Smart technology was originally branded, and is still commonly referred to, as Low Energy (BLE). Though these new radios do offer lower active/peak current consumption, the real gains come from lower idle currents and longer idle duration.
Furthermore, this demonstrates the importance of re-programmable behavior - both at the module level and the protocol level.
And finally, simple measurements and spreadsheet calculations have been used to guide various design decisions including component selection, product architecture, and where to devote future resources.

The spreadsheet used for these calculations is available for download by clicking here.