Shockpad antenna considerations

Now that battery life has been addressed, it's time to consider two other key features of the product: the buttons and the antenna. Because the product IS a set of wireless buttons, these elements simply MUST be correct.

With the proliferation of wireless consumer devices lately, I'm assuming most readers have a rudimentary understanding of radio waves. RF energy propagates best through open air, with direct line of site from the transmitter to the receiver. In a home/office environment, wireless signals bounce around and generally reach their destination, albeit at reduced strength. And finally, radio waves fare particularly poorly inside metal boxes, underground, or in the water.

It's metal that I'm concerned about in this case. For both rugged performance and appealing looks, metal buttons would be an appealing choice for Shockpad. But, would the addition of these metal elements have a negative effect on the product's wireless performance? I set out to answer this question using Ansys HFSS simulation software.

First, I needed a simulation-ready antenna. Fortunately, Texas Instruments provides 100% of the native design files for their CC2541-based Advanced Remote Control (ARC) reference design.

Because Ansys HFSS cannot directly import Allegro design files, or gerbers for that matter, I needed to perform some file translation first. Using Allegro PCB Editor, I opened the provided PCB design file (*.brd) and exported the layers to a *.dxf drawing. I then imported the dxf layers into HFSS. Before/after images are shown below:

Before: Allegro view of ARC; an outline of the antenna is seen in the upper left.

After: HFSS view. Instead of replicating the entire ARC design, only the antenna structure was retained. A large uniform ground plane was created as a stand-in for the remainder of the ARC device.

As a baseline check, it's always good to confirm that the antenna is functioning as expected. To this end, I simulated the design, and produced an S11 plot.

Antenna S11, original length

This was not good. The antenna was functioning well, but at 3.1 GHz instead of 2.4 GHz! The antenna was too short. Digging deeper, I traced this unexpected performance back to the limited geometry which I chose to import. As shown below I was missing a small initial section of the antenna.

Satisfied that I understood the source of the discrepancy, I chose to fix it in a field-expedient fashion. My end-goal was to observe the effect of metal buttons upon an antenna, not to perfectly re-create this particular antenna. So, I simply increased the length of the antenna at its tip.

I iteratively added length, and checked the S11 plot, until I had the return loss centered at 2.4GHz. The optimal length addition was 6mm, and the corresponding S11 plot is below:

Now that the antenna is working at the desired frequency, let's examine its radiation pattern.

This image above shows us two things. First, the radiation pattern is fairly balanced; a few nulls exist, but nothing major. Second, note that the red regions exhibit positive gain of 3-5 dB. Now, I turned my attention to buttons. I enlarged circuit board (more FR-4 substrate and more copper ground plane) and then I created six stainless steel buttons. Each button was 20mm in diameter, 4mm thick, and hovered 3mm above the copper ground plane. The revised model, and the resulting radiation pattern are shown below.

It looks like those buttons really made a difference! Radiation in the +Y direction is visibly diminished. But, notice that buttons were not the only change since the prior results; I also extended the ground plane by 100mm in the +X direction. To investigate whether the change in pattern was due to the buttons or the ground plane, I removed the buttons and re-simulated.

Aha! Now, it's clear that the change in radiation pattern has more to do with the ground plane than the buttons. I hear the echoes of Rob and Kate, two excellent antenna engineers I worked with a few years back, saying "the whole thing is the antenna". If the antenna structure were dangling off a 3 story steel skyscraper, then the antenna would truly be the only thing radiating at 2.4 GHz. But, the thrust of modern embedded electronics is to be small. Consequently, the ratio of "ground plane" to "antenna" shrinks; as a result, both the ground plane and the antenna become radiating elements. If the ground plane is part of the antenna, rather than an idealized equi-potential plane, then it follows that geometric changes to the ground plane become relevant to the product's RF performance; for example, this F antenna required a 6mm lengthening to center its resonance at 2.4 GHz.

So, I returned to the simulation and made a few changes. First, I chopped a corner off the ground plane. My intuition was that the "tip" of the antenna should be in free space, not near other copper, because I want to send RF energy into the air, not back into the copper. Furthermore, this seemed to be the area in need of improvement because it is where the radiation pattern was dramatically reduced, as compared to the original simulation. With this many changes going on, I re-checked the S11 plot, and I found that the resonant frequency of the antenna had indeed shifted up to 2.6 GHz. This was just further confirmation that the ground plane plays a significant role in this antenna's performance. My previous 6mm addition was no longer adequate - I added another n mm for a total of m mm beyond the original baseline. As shown below, the revised model exhibits a much improved radiation pattern. It is more uniform, and eliminates the loss of performance in the +Y direction.

Now, with the ground plane "damage" repaired, let's check again to see if those buttons make a difference.

As seen above, the radiation pattern does not suffer noticeably with the addition of 6 stainless steel buttons. Stainless steel buttons may be used for Shockpad, without impacting RF performance, if they will improve the durability and/or aesthetic appeal of the product.

In conclusion, we've demonstrated the power of RF simulation software to both inform product design decisions and reduce prototype iterations. What-if scenarios can quickly be explored, and two alternatives can be compared side-by-side. For Shockpad, the stainless steel buttons remain a viable design option; if used, they will not negatively impact the RF performance.

Further thoughts:

Re-simulating this model, on a modest desktop machine, takes ~10 minutes at zero cost. In contrast, building new PCB prototypes could take 1-4 weeks at a cost hundreds or thousands of dollars. This also provides a practical example of why good antenna designers prefer to make their antenna extra long for first prototypes. On the computer, it's equally easy to add/subtract geometric length to achieve resonance at the desired frequency. But, on physical prototypes, only subtracting can be done easily and reliably. First, build the most accurate simulation possible, but then add a couple of mm for safety.

The power, and limitations, of reference designs are also demonstrated. Thanks to Texas Instruments, I was able to get off to a quick start by downloading their ARC design files. But, because I didn't use them exactly as provided, the antenna didn't perform as expected. I remain a big fan of reference designs, but their limitations need to be understood. Leveraging a reference design can shorten your design cycle, reduce errors, and increase your odds of success. But, the designer must still think critically and apply good engineering to produce a proper design.

What is Shockpad?

Okay, time for more details about project Shockpad. Several folks, after reading the battery life discussion, have been asking, "what is it?"

Simply stated, Shockpad provides simple remote control buttons for a smartphone, in a highly ruggedized package.

Existing products do provide elements of this functionality. Many headphones contain in-line controls for volume up/down, play/pause, and perhaps even skip forward/back. Many Bluetooth hands-free devices provide a button to answer a call. But, as is the present trend in tech, these controls are all very sleek and small.

Suppose you want to skip to the next track while snowboarding, or adjust volume while motorcycling, or answer an incoming call while wearing greasy work gloves.

Shockpad provides control buttons for individuals in harsh environment, engaged in active pursuits.

Ideally, Shockpad should survive being dropped in water, dropped on the floor, stepped on, run over, and thrown against the room.

It should have a long battery life, a simple interface, and the buttons should be individually accessible with mittens/gloves; the buttons should be distinguishable with little/no visual feedback. Here are some visual cues.

Buttons like this:

For people like this:

Shockpad-related posts:

I've organized my posts by topic below. There is also some value in reading them chronologically.

Miscellany:

Teaser

Batteries and Power Consumption:

Battery Impedance

Managing current pulses

Profiling current draw for a device

Battery Considerations

Power Budget and Battery Selection

Wireless Performance:

Antenna Considerations

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.

Choosing a battery for your electronic circuit

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

In a prior post, I drew an analogy to constructing a tall building. Within that analogy, my posts on characterizing radio modules as well as measuring and mitigating source impedance might be grouped into the category of foundation work. Now, for the first time, we get to work above ground!

When pairing a battery to an electronic design, we begin with the non-negotiable factors and then move to softer parameters which are open to tradeoffs. In other words, a few numbers must be right for a system to function at all, while many other factors contribute to how well the solution works.

1) Voltage

Too much voltage, and electronic components fail immedately. Too little, and they refuse to turn on. Therefore, a candidate battery must first and foremost never exceed a circuit's maximum input voltage.
Next, the battery's end-of-discharge voltage should ideally be greater than the circuit's minimum input voltage. If the battery's "empty" voltage is significantly lower than the circuit's minimum, this implies that a fraction of the battery's capacity is not useful to the circuit. A small mismatch, say 5% to 10% of the total capacity, might be acceptable. But, if 50% of the battery's capacity is not useful, it might be time to consider using a different cell, or connecting multiple cells in series.

2) Average Current

The next priority is average current. Most battery datasheets provide both a nominal current rating and constant-current discharge curves. These discharge curves graph the cell's output voltage vs. time, while holding the output current constant. You should be concerned if your circuit's average current draw is significantly larger than any of the datasheet curves. A cell's source impedance, along with other chemical factors, produce an exponential reduction in useful capacity for high current levels. Short bursts can be dealt with, but consistently overloading a cell simply won't produce good results. Choose a different cell, or perhaps connect multiple cells in parallel.

3) Peak Current
Compare the battery's peak current capabilities to your circuit's peak demands. I've already written about mitigation strategies, at length, in another post. In short, the symptoms/problems associated with excessive peak current include:

• Brown-outs
• Reduced battery life

4) Derate total capacity

Operating near the limits of items 1-3 above may require an adjustment in the total capacity expected from the cell. Additionally, operating the cell at extreme temperatures may also require a capacity derating. And finally, an extra safety/performance margin may be subtracted simply to guarantee that actual performance always exceeds predictions.

5) Capacity units - mAh vs mWh

Battery size is often discussed in terms of current*time: mAh. If your circuit uses a linear voltage regulator, then mAh is a perfectly good computational choice. But, if the circuit's primary regulator is a switcher (buck, boost, SEPIC etc.), then power*time (mWh) may be more appropriate.
The difference between a standard AAA and 9V battery illustrates this difference nicely. The AAA cell is rated for ~2x the mAh of the 9V cell (1400 vs. 900). But, computing mWh tells a different story. Though proper mWh calculation requires compensation for declining voltage during discharge, a a first-order approach is to simply multiply mAh * nominal voltage. This give:

• For the 9V battery: 9V * 700mAh = 6400mWh
• For the AAA battery: 1.5V * 1400mAh = 2100mWh

So, the 9V battery contains more power than the AAA. This makes sense since the cells use the same chemistry, but the 9V battery is 6x larger and weighs 4x more.
Now, let's map the mAh vs. mWh matter back to voltage regulators. If a given circuit contains a 3..3V linear regulator and is powered by a 9V cell, then >60% (1-[Vout/Vin]) of the battery's power will be wasted as the linear regulator converts it to heat. Worse yet, an elaborate cooling strategy may be required to dissipate all that heat. If a linear regulator is used, then it is advantageous to choose a battery voltage which is only slightly above the circuit voltage. If an efficient switching regulator were used instead, then as little as 10-20% of the battery's output power would be lost in the conversion from 9V down to 3.3V. A large mismatch between battery voltage and circuit is less problematic in this case.

Developing a current-draw profile for an intermittent radio

This is another in my series on project Shockpad.

• codename: Shockpad
• Measuring the impedance of a coin cell
• Current pulses, source impedance, and LTSpice

Previously, I focused on measuring batteries. Now, it's time to turn our attention around, to two candidate radio transceivers.

The two transceivers I'd like to compare are:
The Bluefruit EZ-Key from Adafruit

The LightBlue Bean from Punch Through Design

Both are Bluetooth modules. The EZ-Key is a "Classic" device while the Bean is a "BLE" device. I'll discuss application/functional differences later; let's' measure some current draw!

First, let's understand the voltage input requirements of each module.
The EZ-Key lacks a formal datasheet, but the FAQ states:

• Voltage: ~3V

Meanwhile, the LightBlue Bean Datasheet states:

• Voltage: 2.0V to 3.6V

So, in addition to measuring current, I also need to determine the minimum input voltage for the EZ-Key.

EZ-Key Voltage

To determine the EZ-Key's minimum voltage, I powered the module from a bench supply and paired it to my PC. I then reduced the supply voltage, very slowly, until my PC reported that the link was lost. I repeated the experiment three times to confirm my results. I found that the EZ-Key's minimum input voltage was 2.4V, slightly higher than the LightBlue Bean's value.

Current measurement circuit

The circuit to measure current draw is relatively simple:

This is known as low-side current measurement. Low-side measurement is slightly simpler than high-side because the power supply and oscilloscope are allowed to use a standard ground reference (earth ground). All current passing through the radio module must pass through R_SENSE before returning to the power supply; therefore, DUT_GND will not be equal to earth ground. To be precise, the voltage at DUT_GND, which we'll call V_SENSE, can be computed as:

• V_SENSE = R_SENSE*DUT_CURRENT

So, if the value R_SENSE is known, then current draw can easily be calculated as

• DUT_CURRENT = V_SENSE/R_SENSE

Choosing R_SENSE

Some thought, and experimentation, are involved in the selection of R_SENSE. Recall that V_SENSE is the ground reference for the radio module. So, the module's operating voltage is:

•  V_DUT = V1 - V_SENSE

That is, V_SENSE robs from V_DUT. Recall that EZ-Key requires 2.4V to operate. If V1 = 3.0V and 100 ohms is chosen for R_SENSE, then the EZ-Key module will experience a self-induced brownout (V_DUT < 2.4V) at any current draw above 6mA. So, to avoid brownouts, R_SENSE should be small. But, is there such a thing as too small? The smallest resolution on my oscilloscope is 20mV/division. So, I target V_SENSE ~= 50mV for a measurable value that's unlikely to disturb the circuit. If the DUT's current draw is unknown, start with a very low value resistor (0.1 ohm or 1.0 ohm) and increase resistance progressively until a reasonable signal is obtained. But, there's one more possible complication with R_SENSE.

Dealing with wide dynamic range

For some devices, radio transceivers chief among them, the procedure outlined above can leave you in a pickle. Problems arise when devices idle along at a relatively low current draw, but periodically draw large bursts of current for very short duration. It is not uncommon to see a 1:100 ratio between the idle current and the burst. In this case, an R_SENSE chosen for the idle period may produce a brownout during the burst, but an R_SENSE chosen for the burst will render the idle current too small to measure. Different R_SENSE values are needed for each domain. To accomplish this, I like to attach two resistors in parallel; one is sized for each operational mode. I watch a few burst/idle cycles to get a sense of the timing, and then I remove the lower value resistor immediately following a burst event. Sure, the DUT will brownout when the next burst occurs, but I'll have already captured my measurement by stopping/triggering my oscilloscope.

EZ-Key measurements:

I observed a baseline current draw of 24mA for the EZ-Key module. This agrees with the FAQ's claim of "25mA at all times." Every 30-40ms, I observed an 88mA burst of current lasting 150us. This was significantly higher than the FAQ's claim of "an extra 2mA on average during transmission." R_SENSE was 2.5 ohms for these measurements.

In summary, here are the EZ-Key's values, in table form

Mode of Operation (name)	Current Draw (mA)	Duration (ms)
Active	88 mA	0.15 ms
Idle	24 mA	39.85 ms
Total		40 ms

LightBlue Bean measurements:

Before taking current measurements, I used the BeanLoader interface to reprogram the module. I began with a low power profile called "bean sleep", but I modified the code slightly (to eliminate the red LED flash). The module was programmed to "sleep" for a duration of 2s, and so I was surprised to see current bursts every 40ms. It seems that "sleep" refers to execution of user code rather than the radio itself. Regardless of the user code settings, the radio appears to maintain a 40ms connection interval; this is likely to avoid exceeding the connection timeout duration on the host. I observed a baseline current draw of 29uA. Every 40ms, I observed a 24mA burst of current lasting 500us. R_SENSE was again 2.5 ohms for the burst measurement. But, to measure the 29uA sleep current, I had to change to R_SENSE = 220 ohms.

In summary, here are the LightBlue Bean's values, in table form

Mode of Operation (name)	Current Draw (mA)	Duration (ms)
Active	24 mA	0.5 ms
Idle	0.029 mA	39.5 ms
Total		40 ms

In my next post, we'll finally get around to the fun bit of determining which batteries meet the needs of these radios. We'll also predict total product run time given a particular battery choice.

Current pulses, source impedance, and LTSpice

In my last post, I discussed the measurement of source impedance. The conclusion was that source impedance is indeed non-negligible for project Shockpad. This time, I'll discuss what to do about it.

First, I'll remind you what we're up against and what we hope to accomplish:

The battery: I hope to use a CR2032 coin cell to power the Shockpad. The source impedance for this battery begins at ~10 ohms and climbs to 100 ohms (or even 1k ohm) as it is depleted.

The circuit: My circuit draws short pulses of current. For 500us, the current draw spikes up to ~24mA.

Powering my circuit with a CR2032 is problematic for two reasons.

The First Problem: First and foremost, this design runs a high risk of brownout. Consider the image below to be our "before" graph. We'll discuss the particulars later, but it should be easy to convince you that dropping from 3V down to 1.4V or 0.5V could cause performance issues.

The Second Problem: Suppose that the circuit does NOT brown out (we haven't yet discussed it's max/min voltage requirements). Energizer says that repeatedly subjecting the CR2032 to large pulse currents, even if the duration is brief, will reduce the cell's total life. In the Energizer graph below, a fairly representative pulse current has reduced the cell's life to 175mAh (that's a 22% loss from the 225mA nominal capacity).

So, we have two goals which initially appear to be in conflict. To solve the first problem, we actually want to supply MORE energy to the circuit so that the voltage does not drop. To solve the second problem, we want to draw LESS energy from the battery at exactly the same moment. Fortunately, our electronics toolbox contains capacitors. Capacitors store energy, and they deliver it much more rapidly than a battery. If we can add an appropriately sized capacitor to the circuit, we can shelter the battery from large pulses without starving the circuit for voltage. I'm sure I could go to my toolbox, pull out a 4700uF monster, and call it a day.

But, that would hardly be efficient in terms of cost, size, or weight. In general, a capacitor's cost and physical size scale with its value. (Note: voltage rating has a big impact on size/cost too, but that can be held constant in this example) So, we want to determine the minimum capacitance value which will solve our two problems. 4700uF may be laughably large, but can we possibly get by with that tiny 0805 ceramic sitting on top of the coin cell? I'll show how LTspice can be used to answer these questions.

SPICE is the general term for electronic circuit simulation software. LTspice, from Linear Technology is widely used by professionals and hobbyists alike. Linear Tech has a vested interest in providing good simulation tools to their customers since their product line is heavily slanted toward analog components such as regulators and op-amps. In my opinion, the tool's popularity is due the straightforward user interface and price (free).

The circuit for this simulation should look familiar. It is virtually identical to source impedance measurement circuit which I presented last time.

After running the simulation, we'll be probing two points. To see if we've addressed brownout, we'll probe the voltage at the top of R1. To see if we've adequately reduced the current delivered by the battery, we'll probe the current through Rsource. As a baseline, I started with a very small value for C1. 4.7uF produces the voltage graph shown earlier in this post, and this current graph:

4.7uF Current Waveform

So, with C1 = 4.7uF, we have large current spikes and a big voltage dip. As we test out larger capacitors, we need a definition of success. My circuit contains a radio module. The datasheet for that component lists a minimum operating voltage of 2.0V. Good vs. bad current is not as clear. Energizer uses 23mA and 6.8mA as examples of "bad" pulses which reduce battery life. Meanwhile, CR2032's are normally tested at 190uA (or 15k ohms) of continuous loading. So, somewhere between 190uA and 6.8mA, we transition from acceptable to unacceptable. When in doubt, engineers often resort to a factor of 10. So, we could say that the cutoff is 190uA * 10 = 1.9mA. Or, we could say that the cutoff is 6.8mA / 10 = 680uA. For now, we'll be agressive and aim for 680uA. If this becomes problematic, there's some margin/wiggle room up to 1.9mA.

The solution method presented here is essentially guess-and-check. If 4.7uF was too small, let's increase by a factor of 10 to C1 = 47uF. This produces the following graphs:

47uF Voltage Waveforms

47uF Current Waveforms

The voltage graph shows good news. C1 = 47uF has significantly improved the voltage situation. The lowest voltage observed is 2.5V, well above our 2.0V requirement. But, current draw is a different story. We DID make some improvement; recall that the peak was at 24mA for C1 = 4.7uF. But, a coin cell spends much of its useful life around 10 ohms of source impedance, and we still have a peak current draw of 16mA when Rsource = 10 ohms. So, we need to try a larger capacitor, but we really only need to look at the current waveform to gauge its effectiveness. Another 10x step, to C1 = 470uF, produces the following graph:

470uF Curent Waveforms

This is much better than before, but we have not reached our original goal. Another 10x step would put us back at that so-big-it's-silly 4700uF capacitor that I discussed at the beginning. To be academically thorough, I did run the simulation, and I can report that it does bring the peak draw down, below our original goal of 680uA, to a pleasant 470uA. But, a 4700uF capacitor is simply not practical. At this point, I'm going to depart from the simulation and talk about other constraining factors before arriving at a best-effort component selection

So, let's talk compromises. Though it would be great if we could bring the peak current down below 680uA, there are other capacitor constraints. It needs to be a surface-mount component, not a through-hole part. Also, the capacitor should probably not be taller than the coin cell battery (3.20mm max height). My original photo contained an 0805 ceramic capacitor. I ran a Digikey search for 0805 ceramic capacitors rated for 6.3V, and the largest value was 47uF - not even close to our needs. Moving up to a 1210 package, 100uF is available - but this is still woefully inadequate. Having exhausted my options with ceramic capacitors, it was time to pick a new chemistry. Aluminum electrolytic capcacitors are known for providing large capacitance values at a low price. Unfortunately, they are not known for being low-profile. A quick parametric search, limiting height to 3.95mm (slightly taller than a CR2032) showed a 100uF 6.3V part as the largest available. Also known for their bulk, at a slightly higher price point, are Tantalum capacitors. If you look inside a modern cell phone (another product that draws large bursts of current), you're likely to see many yellow 2-terminal components; those are tantalum capacitors. Applying the same height/voltage constraints to my search, I found values all the way up to 2200uF! But, this part also shows us one reason why tantalums are not used everywhere and all the time - it costs several dollars even in quantity. I'm choosing to filter out all parts whose low-quantity price is above $2; I assume this will translate to an actual negotiated volume price <$1. Applying the price filter, the height filter, and the 6.3V filter, I'm left with 470uF as the largest tantalum capacitance available. There seems to be a few choices in this size, Kemet, AVX, and Vishay all have competing product lines. Here's a representative part from Kemet.

Because we settled out on 470uF, the predicted current can be found in the image above. We did not reach the aggressive goal of 680uA, but we are well below Energizer's two textbook examples of peak current (6.8mA and 23mA). Recall that our baseline simulation (4.7uF) showed a sustained peak current of 24mA. By adding a 470uF capacitor, the peak current is truly that (a peak) rather than an extended duration at the maximum value. And, magnitude of the peak has been reduced by a factor of 10 - an engineer's favorite number.

So, where have we been and what have we learned? The current consumption profile for my device is near the upper end of what the CR2032 can support. Without careful design, my system's actual run-time would fall noticeably short of nominal predictions. But, simulation shows that adding a bulk capacitor can bring the circuit's needs and the battery's capabilities into much closer alignment. On the other hand, practical constraints of size, cost, and weight mean that we can only afford to reduce, not eliminate, pulsed current draw as seen by the battery. This issue should be re-visited when prototype hardware is available. Actual circuit performance and battery life should be tested as a part of the hardware verification and validation activities.

OR

Depending on the project's risk tolerance, this level of uncertainty may be unacceptable. The CR2032 looks like it could work, with careful design. An alternate approach would be to abandon the CR2032 battery entirely and choose a different cell which will easily supply this circuit's needs (for example, two alkalaine AAA's). What is more important? Do we optimize size/weight now and accept long-term risk related to runtime? Or, do we increase the size/weight right now in exchange for an assurance of easily meeting the runtime goals? Which parameter is more important to the end user? In the future, perhaps I'll present a weighted/ranked list of user needs to inform this decision.

You can download your own copy of LTspice here.
You can download my simulation schematic here.
For another view on this topic, check out White Paper SWRA349 from Texas Instruments.

Measuring the impedance of a coin cell

If you want to construct a building, you have to start with the foundation. Humans have been digging holes and mixing concrete for millenia now, and these humble tasks remain the all-important starting point for the most advanced of modern structures.

A proper foundation is not a glamorous thing: you can't see it and it doesn't actively DO anything. The measure of a good foundation is the very fact that NOTHING happens for a very long time. But, cut corners at the beginning and... well, everyone knows about the tower in Pisa. Here's a domestic example with a dramatic ending.

The same is true in electronics. At the end of the project, software is often called upon to patch deep flaws in the system architecture or hardware, because "it's too late (or expensive) to go back and do it right".. The beginning of any project is the time to ensure that the underlying hardware architecture will perform as desired; fixing it later will only increase the cost, often exponentially.

Battery impedance is not a spec. which gets much thought. I recently purchased a new cordless drill, and I assure you that I did NOT ask about the battery's impedance. Consumers definitely know their battery chemistry: Lead-Acid for cars, Alkaline AA's, toxic NiCd rechargeables, and of course the modern workhorse Lithium. They've even learned a bit of electrical terminology: higher Voltage makes a more powerful drill, and cell phones with more mAh won't die mid-day.

Often, neglect for a battery's source impedance is reasonable. If relatively small currents are drawn from a relatively large battery, at moderate temperature, then source impedance will be negligible. But, when those two "relatives" or one "moderate" no longer apply, source impedance suddenly becomes a conversation topic.

For my present project, I'm hoping to use a CR2032 coin cell as the power source.

Panasonic lists the standard drain for their cell as 200uA.
This project's circuit is known to draw tens of mA for short periods.
Energizer provides this helpful graph showing that pulse currents reduce the total capacity (mAh) of their cell.

Because this project's anticipated current draw will be LARGE relative to the battery's ratings, source impedance warrants a closer look.

To measure source impedance, I used the following circuit.

For this measurement, the battery is modeled as an ideal voltage source and a series resistor R(source). As noted in the image above, Open Circuit Voltage (OCV) is measured with SW1 open, and Closed Circuit Voltage (CCV) is measured with SW1 closed. Note that an oscilloscope is used for measurement. A simple multimeter could be used, but the oscilloscope adds value because it can be set to trigger on a falling edge, capturing the CCV value an instant after SW1 is closed. Because batteries rely on chemical reactions, the CCV will decay as SW1 is engaged for longer durations. This decay is shown in the Energizer graph shown below.

I created a spreadsheet to record measurements and compute R(source).

The result: R(source) was nearly 14 ohms for the CR2032 I tested, which agrees with data provided by Texas Instruments and Energizer. The cell used for these measurements must be relatively fresh/new because values for R(source) are predicted to rise to 100 ohms or even 1k ohms as a CR2032's capacity is consumed through use.

After measuring the source impedance of the CR2032 cell, I know that it is significant and must be considered in my product design.

In future posts, I'll discuss the current consumption profile for my circuit in greater detail, and I'll also present a strategy for smoothing out short-duration current spikes to reduce stress on the battery.

My Excel spreadsheet is available here.
My measurement circuit is available in pdf format here.

codename: Shockpad

I'm working on a project right now that blurs the lines between academia and fun/hobby work. More to come, but here's a view of the bench at present.

And I just ordered one of these on eBay:

CLASSIC CONTROLLER FOR NINTENDO NES 8 BIT SYSTEM CONSOLE CONTROL PAD

				CLASSIC CONTROLLER FOR NINTENDO NES 8 BIT S... US $3.99 New in Video Games & Consoles, Video Game Accessories, Controllers & Attachments
				View on www.ebay.com	Preview

Fun with USB

When is a deal not a deal? Well, a sub-$5 powered USB Hub is no longer a good deal when it requires: an engineer, a >$5 debugging device, and spare parts from the basement to get it working. Plug-and-play did not accurately describe my experience.
Click here to read my Amazon review.

But, product complaints aside, I guess I have to acknowledge the existential satisfaction which I derived from receiving a puzzle, finding the solution, and sharing it with others. There you go folks, next time you need a gift for the engineer who has everything, skip the Comic Book store, stroll right past the Strategy Games aisle. Give them some cheap electronics paired with the challenge, "I'll bet you can't figure out what's wrong with THIS!"

The Lab is Getting Respectable

First, there was just me, a laptop, and a license for OrCAD. No pic needed :)
A little discussion here: I've created past designs using (in order of preference): Altium Designer, OrCAD/Allegro, and Mentor Graphics. When it came time to spend my own money, I REALLY wanted to work in Altium, but I simply couldn't justify the buy-in premium over OrCAD/Allegro. One subtle plus for the now-integrated OrCAD/Allegro - the entry-level PCB Designer/PCB Editor uses the same *.brd format that the high-end Allegro suite does. The more expensive licenses simply unlock more constraint-driven routing tools etc. I'd say, right now, I can sketch a schematic more quickly in OrCAD but I can route a board faster in Altium. So, I guess it's kind of a wash.

But, if you design a board, sooner or later the time comes to power it up and verify functionality.

So, I bought some stuff.

What a mess!

But now, things are now organized and ready for productivity!

Better yet, the white desk is a sit/stand model. With a little cranking, the work surface can be raised/lowered to reduce single-posture fatigue.

I've noticed that some folks wonder about what to buy for their first electronics workstation. This is, admittedly, the most equipment I've ever purchased for myself. But, I've worked in a variety of labs and manufacturing environments. So, perhaps my choices can benefit others. Here are some of the key elements I chose:

Quality signal measurement
Rigol DS1102E
100MHz bandwidth should cover basic communication busses and clock sources with a little extra headroom to observe transients on said lines.

Quantity signal measurement
BitScope Micro
What it lacks in bandwidth, it makes up for in affordability and plentiful digital inputs. Good for sniffing an entire SPI bus, performing packet decode on I2C/CAN, or even serving as a simple function generator. I also like that they publish their API.

Bench supply.
TMS 30V 5A
I probably could have gotten by with the array of wall-warts I have sitting around, but it's really nice to be able to turn the current limit waaaaay down during initial bring-up.

Programmer
Olimex ARM-USB-OCD-H
My firmware collaborator is a big open source fan. End-to-end open source with Eclipse IDE, gcc compiler, and Olimex programming pod.

Soldering Iron
Hakko FX-888D
The smaller components and traces get, the more sensitive everything is to over-cooking. Hakko is a trusted name for accuracy and durability.

Hot air rework tool
Yihua 878AD
In the age of BGA's, QFN's etc, hot air is a must. As a bonus, it includes another soldering iron whose tips are compatible with the Hakko. Having two irons is nice if you want to use "tweezer" a component off... I felt validated in my choice when I read this recent article on Hackaday.

Adafruit USB Isolator
With two different USB peripherals connecting to my target board, I decided that isolation might be a good idea. I looked at some nice enterprise-class isolated hubs, and came to the following conclusions. 1) Nobody has isolated high-speed USB. It simply isn't a thing. You can spend $35 or $350, and you won't get beyond full-speed. 2) The price is right! I have high hopes for the low-cost isolator, but even if it doesn't work out, it's no great loss. My hopes ARE founded in a bit more than blue sky optimism though... one of Adafruit's marketing images shows an Isolator, Bitscope, and RasPi connected to one another.

And finally, with all this goodness on one desk, I needed to go find another power strip in the garage.