标签: consumption

Heat dissipation is often tied with power usage; that's not news. But sometimes, in our focus on minimising power consumption and thus subsequent dissipation, we forget that there are situations where properly managed dissipation is the whole point of the design.   This became very clear after I read a fascinating article in a recent issue of IEEE Spectrum about the ineffectiveness of the standard home oven. The article, " Recipe for a Better Oven " by Nathan Myhrvold (yes, the former chief scientist at Microsoft) and W. Wayt Gibbs, discussed the many shortcomings of the standard home and even commercial baking oven.   It was both illuminating and somewhat discouraging for many reasons. It's not just that the oven is wasteful in terms of energy use, it's that it also does a poor job despite that inefficiency; whereas I had hoped that the inefficiency was a necessary part of the tradeoff for getting the baking done right.   I already knew that the simple on/off control of the gas line or electric power was a marginal approach. Anyone who has studied any control theory knows that a loop with on/off control, rather than true proportional control and a PID (proportional-integral-derivative) control strategy, is not good at keeping the error between setpoint and actual value small, unless you are willing to switch that on/off valve at a fairly high rate.   While it is true that thermal situations tend to have relatively long time constants and so can accept a somewhat lower cycling rate than some other situations, oven vendors like to keep the valve's cycle time to a few minutes. So it is common to see swings of ±50°F (about ±25°C) around the setpoint. That's just not good enough for many recipes or foods.   The problems of the standard oven design and subsequent performance go well beyond the basic temperature-control loop. Only after I read the article did I realize how much I hadn't known about the implications of oven design and the cooking process.   For example, the heat source doesn't cool the food directly; instead, it heats the oven walls (metal or brick), which then re-radiate the heat to the food. The article explained how this leads to very uneven heat zones in the oven for conventional metal-wall ovens, and numerous other problems. (The article did highlight some ways to improve an oven's performance, which was nice to see.)   These other problem are not trivial, either, as they have to do with how different foods are affected by the radiant heat of the oven walls versus direct heating; not surprisingly, it does make a difference, just as different types of electrical load impedances affect power supply performance. (There are times when I felt the whole discussion of oven idiosyncrasies was akin to the mysteries of black-body radiation , which were finally resolved with the development of quantum theory in the 1920s by Max Planck and others.)   The irony of the oven problem is that for most engineers, the primary concerns regarding heat are twofold: minimizing generation of it in the first place, through the use of low-power circuits and high-efficiency supplies; and maximizing its removal, using convection, conduction, and radiation via use of fans, heat sinks, cold plates, and even advanced active techniques. It takes a 90° or even 180° shift in thinking to begin to understand heat and its effective delivery as an outcome rather than as an obstacle.   Have you ever been faced with a design challenge that required that you reroute your established way of looking at something, to a very different course? Did you realize the differences right away, or did you have to really step back to understand the many inherent assumptions you were making and how they had to be changed as well?

Heat dissipation is typically linked with power usage; that's not news. But sometimes, in our focus on minimising power consumption and thus subsequent dissipation, we forget that there are situations where properly managed dissipation is the whole point of the design.   This became very clear after I read a fascinating article in a recent issue of IEEE Spectrum about the ineffectiveness of the standard home oven. The article, " Recipe for a Better Oven " by Nathan Myhrvold (yes, the former chief scientist at Microsoft) and W. Wayt Gibbs, discussed the many shortcomings of the standard home and even commercial baking oven.   It was both illuminating and somewhat discouraging for many reasons. It's not just that the oven is wasteful in terms of energy use, it's that it also does a poor job despite that inefficiency; whereas I had hoped that the inefficiency was a necessary part of the tradeoff for getting the baking done right.   I already knew that the simple on/off control of the gas line or electric power was a marginal approach. Anyone who has studied any control theory knows that a loop with on/off control, rather than true proportional control and a PID (proportional-integral-derivative) control strategy, is not good at keeping the error between setpoint and actual value small, unless you are willing to switch that on/off valve at a fairly high rate.   While it is true that thermal situations tend to have relatively long time constants and so can accept a somewhat lower cycling rate than some other situations, oven vendors like to keep the valve's cycle time to a few minutes. So it is common to see swings of ±50°F (about ±25°C) around the setpoint. That's just not good enough for many recipes or foods.   The problems of the standard oven design and subsequent performance go well beyond the basic temperature-control loop. Only after I read the article did I realize how much I hadn't known about the implications of oven design and the cooking process.   For example, the heat source doesn't cool the food directly; instead, it heats the oven walls (metal or brick), which then re-radiate the heat to the food. The article explained how this leads to very uneven heat zones in the oven for conventional metal-wall ovens, and numerous other problems. (The article did highlight some ways to improve an oven's performance, which was nice to see.)   These other problem are not trivial, either, as they have to do with how different foods are affected by the radiant heat of the oven walls versus direct heating; not surprisingly, it does make a difference, just as different types of electrical load impedances affect power supply performance. (There are times when I felt the whole discussion of oven idiosyncrasies was akin to the mysteries of black-body radiation , which were finally resolved with the development of quantum theory in the 1920s by Max Planck and others.)   The irony of the oven problem is that for most engineers, the primary concerns regarding heat are twofold: minimizing generation of it in the first place, through the use of low-power circuits and high-efficiency supplies; and maximizing its removal, using convection, conduction, and radiation via use of fans, heat sinks, cold plates, and even advanced active techniques. It takes a 90° or even 180° shift in thinking to begin to understand heat and its effective delivery as an outcome rather than as an obstacle.   Have you ever been faced with a design challenge that required that you reroute your established way of looking at something, to a very different course? Did you realize the differences right away, or did you have to really step back to understand the many inherent assumptions you were making and how they had to be changed as well?

This is not a trick question. Your options for answers are as follows: Always Sometimes Maybe It depends As with most engineering issues, the correct answer is either c or d, based on your perspective, your priorities, and the specifics of the situation. It also is related to the basic definition of power and energy: Energy is the time integral of power. Many people, however, confuse "energy" and "power" both in concept and as physical entities.   I started thinking about this again after reading a brief Wall Street Journal piece, " Europe's Dirty Floor Mandate " (subscription required), and a related article in the Telegraph, " EU to ban high-energy hair dryers, smartphones and kettles ." According to the WSJ, "Consumers are only now noticing Regulation 666/2013, adopted by the European Commission last year and taking effect next month, which bans the manufacture or importing of vacuum motors whose power output exceeds 1,600 watts, with the limit dropping to 900 watts after Sept. 1, 2017."   The Telegraph reports that similar power-reduction plans are in place for appliances such as hair dryers. All of this, of course, is in the name of "saving energy."   Here's the problem: If you can accomplish the same task with a lower-power motor as compared with a higher-power motor and in the same time , you certainly will have saved energy. But if it takes longer due to the reduced power level, you may end up using the same or even more energy. In the case of reducing the motor power in a vacuum cleaner, the consumer may have to run it longer, so we are back to basics: Actual energy used is the time integral of power.   Perhaps it is possible to reduce a vacuum cleaner's power consumption significantly, while getting the same results, by using a more efficient motor and airflow arrangement. I don't know how efficient a vacuum cleaner really is or how much upside potential there may be. I do know that more efficient motors generally require more copper wire in their windings, so power consumption may be reduced for a given suction rating and airflow volume, but the total cradle-to-grave energy "expense" may actually be higher. It's hard to say.   (Side note: I never understood why vacuum cleaner "powerfullness" was discussed in terms of motor current draw -- amps. That always seemed to be looking at the wrong end of the story, and it assumed all motors and their vacuum cleaners had equal input current/output performance ratios.)   What really has me puzzled is the push toward greater electrical efficiency in appliances where the core function is to provide heat, such as hair dryers. A 1,000W dryer will surely take longer to dry hair than a 1,500W unit.   Aren't hair dryers and other electric-heat products 100% efficient by definition, except perhaps for some losses in their fan and an IR drop in their AC wires? I once measured a commodity 1,200W hair dryer's power consumption in no-heat/cold-air-only mode. I found that the very noisy fan took only about 50 W, an insignificant amount compared to the 1,200W full-heat rating. Even a somewhat better fan motor would not make much difference in overall energy use.   Have you seen other examples where people confuse energy with power and think that, by reducing one, they will automatically save on the other? Have you seen cases where reducing power consumption has actually increased energy use? It even happens with power-miser low-power systems that have a sleep mode. Sometimes it is more energy efficient to have a short, high-power activity burst and a longer sleep period, rather than a longer, medium-power burst and shorter sleep mode.

One equation gets constantly bandied about when talking about power consumption of electronic devices. If you’re designing battery-operated ultra-low-power devices, it’s critical that you, well, ignore it. Power is proportional to junction capacitance times the voltage squared times the frequency, multiplied by the time the system is awake. I have seen engineers’ eyes light up by the V-squared term; they immediately start looking for a way to lower Vdd to get more battery life. As we’ll see in a future article, there is some benefit to dropping the power supply voltage. But this equation is irrelevant to ultra-low power systems because it measures power – watts – not current. High-performance systems live and die by power; have you seen the cooling towers on desktop CPUs? Battery-operated systems are constrained by battery capacity, which is measured in amp-hours; typically the units are milliamp hours (mAh). Power is not the issue for figuring battery lifetime. Think in terms of current. The following graph shows how one of Microchip’s nice low-power MCUs uses current as a function of clock frequency:   Note that doubling the clock rate from one to two MHz uses much less than twice the current. The reason is that the CPU is only one of the powered components. Memory and peripherals suck coulombs, too, and not all of these needs vary with clock frequency. There’s a static, constant draw, and one which is a function of frequency. It’s not hard to pick points off the graph at 3.5 volts and solve a couple of simultaneous equations, which gives: Constant current: 0.39 mA Dynamic current: 0.11 mA/MHz At one or two MHz most of the current is used by constant loads. At higher frequencies the constant draw is still significant. It’s clear that wise designers will run at the max possible clock rate to get back to sleep as quickly as possible. This is the advice given by all of the MCU vendors. And it’s wrong. Or at least naïve. Recently I showed how a battery’s internal resistance increases as it is depleted , and included the following graph, which shows the voltage delivered by the battery depending on load.     If one were to follow the advice to run as fast as possible, coming out of a sleep state means the system will be drawing perhaps a lot of current. Over time, the battery’s internal resistance will increase to a point where it may have a lot of capacity left, but cannot power a speedy current-hungry MCU. Wake up, and Vdd drops below the minimum allowed, so the processor crashes. At least one series of MCUs advertised for ultra-low power operation consumes 200 uA/MHz, maxing at 48 MHz. That’s about 10 mA just for the MCU. The battery might not be able to sustain a 10 mA load, but at 1 MHz - 200 uA - it can have plenty of life left. The moral is to wake up at a low clock frequency. Ramp it up while watching Vdd, stopping a bit above the MCU’s cutoff point. Be sure to factor in the needs of I/O you’ll be powering up. Alternatively one could apply some a priori knowledge (e.g., track consumed mAh in the code and use data such as in the graph above to estimate the operating point) to set the clock frequency. But if you take the vendors’ advice and wake up at full throttle, the useful battery lifetime may fall far short of your design goal.

In past weeks, I reviewed two devices that measure the current consumption of embedded systems (the Real-Time Current Monitor and the µCurrent ). Ultra-low power consumption is a hot trend, and, happily, more tools are coming to market to help us. IAR—the company that makes compilers and integrated development environments (IDEs)—also sells a range of debug probes. Its I-jet is a $300 probe targeted at ARM processors that have a JTAG or SWD (serial wire debug) port. It provides all of the usual resources for debugging embedded systems in the code domain—breakpoints, watchpoints and the like—via a quite intuitive IDE.   I wrote a lot of code to understand the I-jet's behaviour and found that these standard debugging features worked extremely well. But here I'll focus on the device's current-monitoring feature. The Real-Time Current Monitor andµCurrent both measure current consumed by a system. That's very useful and I employed them often in extensive experiments I've been doing on ultra-low power systems (forthcoming soon on this site). But these two products can't correlate current to the code. Sometimes it's important to understand why there's a spike in current consumption: is there an error in the firmware? Is the code poorly organised to minimise the use of coulombs? Perhaps the wrong sleep mode has been selected. The I-jet couples code to current. But first, one clarification. IAR's literature talks about its power-profiling abilities. These abilities do not exist. The device measures current, not power. And really, in many cases we're not interested in power but want energy: power*time, which indicates how much we've sucked from a battery. One of my few beefs with the I-jet is its inability to measure energy. A nifty improvement would be to figure watts and then integrate that over some user-defined range to compute the total milliamp-hours consumed. A capacitor might be needed to integrate between samples, but everything else would be, as they say, "just a software change." First, the specs: The I-jet is powered via USB and in turn sources power (up to 400 mA) to a target board. I'm told there will be a way to measure current on boards with their own supply later this year. It can resolve to 200µA at a 200kHz bandwidth. 200µA to 400 mA is better than a three order of magnitude range. But really low-power systems that have sub-µA sleep numbers will be hard to monitor. The I-jet's ADC has eight inputs so I wonder if a future version will offer a lower range. The bandwidth is much greater than that of the previous tools I reviewed. But it's much too narrow to monitor instruction-level current changes, although in reality those may get swamped out by decoupling capacitors on the target board. (A note about bandwidth—some commenters to my previous articles seemed to miss the point that measuring to sub-microsecond rates is tough. Fast ADCs can be expensive, but beyond that, the gain of op-amps degrades as the signal's frequency increases. The amplifier's gain-bandwidth product tells us at what frequency the gain is unity; if 1MHz, then count on only a gain of 10 at 100kHz. A lot of gain is needed since the IR drop across the sense resistor is tiny at low currents. Check out TI's parametric search to see some typical gain-bandwidth products. Sure, plenty of fast op-amps are available, but cost and complexity increases.) The displayed resolution is 1µA, which is somewhat deceiving. I think this is a mistake that can mislead developers—or is it a clue about a future enhancement? The numbers highlighted in yellow are typical. Note that the 200 uA resolution means the two right-most digits are meaningless and the third is optimistic: Presumably a sense resistor is in the line to the target. Running a program that alternately added and removed a 15-mA load resulted in about 20-mV difference in supply voltage to the board, suggesting a sense resistor of an ohm or two. At first I couldn't get the I-jet to work at all (a cockpit problem), so popped off an email to the FAE. Bam! Maybe two minutes later he responded with the solution. ARM processors have an optional macrocell that can sample the program counter at a high rate of speed, time-stamp each sample, and spit the results out the serial connection. The I-jet sets up this resource and monitors the resulting data, at the same time sampling current. Though the I-jet has a 200kHz bandwidth, the useable resolution may be lower depending on how fast your board can push packets out. On my 72MHz board it was very reliable at 70k samples/second, but faster data gathering led to overflows on the serial interface. That's about 14µs/sample. Fast events (again, assuming they are not integrated to oblivion by decoupling caps) could be missed. The "power" debugging is fully integrated into the IDE. It's easy to set a breakpoint to stop execution when the current exceeds or is under any value. Or, one can graph current consumption and display it in a list. Double-click on a point in the graph and the IDE highlights the corresponding code in the C source and disassembly windows. Here's an example:   The graph shows the current going up in steps, since at each step another LED is getting turned on. The bottom window shows where I instructed the IDE to breakpoint if the current exceeds 40 mA. That happens just after calling LEDsSet to put 0xF out, turning on the final LED, pushing power to (see the current log, middle window) 42,706µA. The "while" is highlighted as that's where the current jumped to over 40 uA. Notice the "skidding" in the graph—the power went above the break value and the code continued to run for a while. Indeed, variable "i" in the watch window has incremented 40616 times after the break should have happened (it's a register variable so, at the CPU's 72MHz, things are happening fast). Using the time stamps in the current log window it turns out the skidding lasted 12,625µs. I'm guessing the I-jet, or perhaps the PC, gets a signal that the break condition has occurred, and then sends a break command to the CPU. The skidding, though, turns out to be mostly unimportant since the code aligns almost perfectly with the current graph and log; looking back in the current log at the time stamps and PC the current jumped no more than 16µs before the first execution of the "while", which is about the resolution of the sampling interval. The skidding makes for a bit more work for the developer, but it's so easy to navigate in the graph window it's not much of a pain. Oh, and the graph just screams—it's really fast, and is displayed even when the code is executing. You can select the display resolution in increments from 10 ns to an hour. So much data winds up in the log window that it's cumbersome to move around in it; I'd like to see a search feature. There's a lot of wasted space to the right of the log window's data; a cool feature would be to annotate each entry with the code that was executing. Somewhat analogously to the Real-Time Current Monitor the IDE will display current either linearly or logarithmically. The latter is hugely important to profile a system's overall operation over a wide dynamic range. For instance, this is a linear display: The same data in log form shows much more detail:   The screen can get really busy with various windows open. I wish one could "undock" windows from the IDE and move them around on the desktop, which would use a multiple-monitor environment much more effectively. The I-jet is a big advance in monitoring current in low-power systems. It's easy to use and provides phenomenal insight into a system's operation in the current domain. If you're working with an ARM-based device that has energy constraints, this is a must-have tool. I'd like to thank Shawn Prestridge of IAR for his help.