There are lots of really complicated and difficult ways to design for lower energy consumption, but most of us do not have the time or budget to do them. Yet, there are many really simple ways to reduce energy consumption which only take a few moments of our time. It is largely a matter of being conscience of the decisions we are making.Here are a few ideas:
- Use larger resistors
Does that pull–up/down resistor really have to be 1k? Could it be 10k or more? There are always engineering trade–offs to be made. Increasing resistor size increases noise and can make your design more susceptible to EMI, but there are many cases where resistor values can be increased with no discernable effect. Think about this, at 3.3V a 1k resistor will burn up 11mW, change that to 10k and the power consumption drops to 1mW. Your signal line should be in the correct default state (high for a pull–up and low for a pull–down) to ensure no energy is being spuriously expended.
- Turn off unnecessary LEDs
We (I) often use LEDs for debugging purposes, such as internally on an enclosed board. It helps us get some visual information about the system while debugging. Did you remember to turn those off in your release version? LEDs can consume a significant amount of power (1.5V @ 10mA = 15mW) which adds up for each LED that is needlessly left on.
- Dim or blink required LEDs
LEDs that provide visual information to the user can be dimmed or blinked to reduce power consumption. Try to determine whether those LEDs are really necessary in the first place – are there other indicators which are providing the same information? A laptop typically has a power LED and a screen which both provide feedback that it is on, while cellphones have no power indicator other than the screen. Does the laptop really need the power LED to be on all the time? What if it was only on when the screen was turned off, or flashing while in sleep mode? What if the battery indicator flashed when the laptop was off and the battery was full instead of being permanently on? How else can you convey the same information?
- Put microprocessors to sleep
Microprocessors are often waiting for an event such as a timer or communications interrupt. It is normally a simple task to put a device to sleep while it is idle. Some simple code can reduce the power consumption (and extend the battery life) of your device.
- Turn off unnecessary peripherals
Microprocessors usually have a number of peripherals which are either not used, or not used all the time. If unused peripherals are clocked that means that energy is being banished to heat just to clock something that is idle. Not all devices support this, but more and more are coming out with these features (such as the Luminary Micro range).
- Use low power components
Duh! That may seem obvious, but take some time to look at the quiescent current of the components you choose when designing. Faster components (like high speed op–amps) typically require more power when idle, while slower components require less. Consider using a slower op amp or lower power transceiver.
- Use a higher bus voltage
When you are running long wires (e.g. power bus around a warehouse) use the highest voltage that is practical. This will help reduce power loss due to copper losses. It also means you can use thinner cable, or run more units from a single cable (if cable current is a limiting factor).
- Use a lower bus voltage
Have you considered using a lower system voltage (e.g. 1.8V instead of 3.3V)? The limiting factor is often peripherals which require certain voltages, but you can consider other peripherals or use level translators. There are a lot of trade–offs to consider here, so use your engineering wisdom to come up with the best solution.
- Consider latching relays
Normal relays require a continuous current flow to keep them in the on position, while latching relays only require a short pulse to switch from one position to the next. You will have to consider cost and a small amount of extra circuitry, but these are particularly valuable where there are power supply limitations.
Photo courtesy of Windell H. Oskay, www.evilmadscientist.com
