Many of today’s electronic devices are never truly “off.” Even when a device is in sleep mode, it draws some amount of power—and drains batteries. Could this power drain be smaller? In this article, Jeff addresses this question by looking at more efficient ways to for a system to “play dead” and regulate power.
Most modern home appliances never really turn off, unless you unplug them. They spend most of their time in standby mode, but some are wirelessly communicating all the time. These “energy vampires” or “phantom loads” can end up costing you $4 to $13 on a monthly household bill of $100! We pay up without a second thought.
When the device runs on batteries, it’s a totally different story. Or is it? Your cell phone is never off. Most will last the day. And we seem to be OK with having to throw it on the charger every night. That’s just the price of connectivity. However, it can all get overwhelming, if we need to recharge our laptop, watch, Bluetooth earpiece, Fitbit, radio, game consoles, hearing aids, shavers, cars and phone every night. Are you a slave to any of these?
Many projects I’ve done do not have to be ON 24/7. For instance, last month’s project using an Arduino took 360 mA while active (actually playing an MPS file). In sleep mode the power was cut to 90 mA. Although reducing power to 25% while in sleep mode may seem like a savings, I wouldn’t call this low power. That actually requires 2 A per day to sleep! As it turns out, there are other things that draw current besides the microcontroller—in fact the MCU’s draw can actually be quite small.
It’s the other devices in the circuit that can lead to a not-so-minimal current draw. This project isn’t about altering “other projects” to try and minimize the draw, but rather, to “cover up a stink with a smell,” so to speak. How can we “play dead” periodically using as little current as possible, and then control and regulate the power to an external device more efficiently? Let’s assume we are using some battery with a voltage higher than what we will be regulating to.
QUIESCENT CURRENT
When designing a circuit from scratch to run on batteries, instead of using an Arduino or other MCU module, I’d want three things: 1) Use a regulator that has a low quiescent, no load, current. 2) Choose an MCU that has a reasonable sleep-mode current. 3) Measure the battery state, so execution can proceed only if there is sufficient battery voltage. Let’s begin with a look at the typical linear regulator specifications.
MC7805 10 mA Quiescent Current
MC78L05 5 mA Quiescent Current
MC78LC50 3.6 µA Quiescent Current
TPSM84205 Significantly < 1mA Quiescent Current
— ADVERTISMENT—
—Advertise Here—
While this doesn’t seem like a big deal, you can improve the “no load” requirements by a factor of greater than 1,000 by designing with a specialized component. Although the difference between a TO-220 and TO-92 device means supporting 1 A of current compared to 100 mA, most of our circuits don’t require anywhere near 1 A of regulated current. So, the “L” device can be used in circuits that require up to 100 mA. The “LC” device is not available in a through-hole device. You will need to work with an SMT device, but it will also handle 100 mA. Recently a TO-220 linear replacement has been introduced that replaces the linear regulation with a switching regulator. This can reduce the wasted drop of the linear regulator, but its very make-up requires it to run even at no load or very low loads. The quiescent current is therefore not as low. Although specifications are not given, the switching frequency is slowed to some minimum. I measured in-circuit results that were somewhere between the MC78L05 and MC78LC50 currents shown above.
MICROCONTROLLER CURRENT
The current consumption of MCUs is based on many factors. Without going into the specifics of each manufacturer, let’s touch on the main things that will affect most MCUs. Three features will affect not only the operating current but also the sleeping current:
Operating Voltage: The higher the voltage, the higher the current
Operating Frequency: The higher the frequency, the higher the current
Peripheral Control: The ability to disable unused peripherals reduces current
The first two are fairly straightforward, and your requirements may force you into using a certain system voltage. While we generally run our systems as fast as possible, this is often overlooked as a way to reduce operating current. You don’t want to lower your operational speed below the point where your program execution can’t keep up with the design requirements. You’ve most likely chosen an MCU that includes hardware peripherals that are required to implement your solution to the objective. The ability to disable their circuitry will prevent them from adding unnecessary consumption to the total.
That all makes sense in operational mode, but what about low-power/sleep modes? Well, what can you live without? The level of consumption is directly affected by the number of peripherals that must continue to operate while the program execution has been temporarily suspended. This is where interrupts come into play. To reduce consumption, we need to suspend program execution completely, and the only way to begin execution again is for something to trigger an interrupt. This may be in the form of a reset or other external input, or some peripheral signaling the completion of a task. The task might be an A/D conversion, a character received via the UART, a timer expiration or any of the other potential interrupts of your MCU.
Each enabled peripheral will add consumption based on its required clocking (when necessary). Obviously, an external or change-of-state interrupt will have the lowest consumption, because the system is in a static state awaiting some external force. Periodic automatic interrupts require the use of a clock, and this relates back to operating frequency. Running the clock at the lowest speed possible will conserve the most current. While execution generally runs at megahertz or higher frequencies, many MCUs offer 32 kHz oscillators that can be used for RTCs (Real Time Clocks), so they make perfect low-frequency clocks for timing period wake-ups. If your design includes an external RTC, you can take advantage of its coin cell battery to keep time, and provide an interrupt to wake up your processor from its minimum current sleep mode.
ADDITIONAL BATTERY LOADS
When monitoring for “battery voltage,” a simple voltage divider will reduce the battery voltage to a level that will not exceed the maximum permissible voltage to the ADC. Its total resistance is a load on the battery, so you will want to use resistors that are as high as possible—without exceeding the recommended source resistance on the ADC. Normally, with a fast system clock, you would have to slow down the ADC clock, so as not to exceed the minimum acquisition time. This won’t be the case, because we are running with the clock as slow as possible. The 100K/33K divider will add 12V/13,3000Ω or 90 µA to the sleep current.
In this project, besides the 5 V regulator and the battery monitor voltage divider across the load, there are also two switching regulators. The MCU will be keeping these LM2575 switching regulators OFF when not needed, but they have standby quiescent currents associated with them. They will consume up to 200 µA while switched OFF.
We’ve cut down the 5 V regulator’s quiescent current, but there are still loads on its 5 V output—the MCU, LEDs and analog loads. As mentioned earlier, the MCU sleep current can vary, depending on the internal peripherals used and any external circuitry attached. In our case, the watchdog timer in sleep mode costs 40 µA, and the output of each LED attached to a power control is ON only when a regulator is on. You can minimize I/O currents and make sure inputs do not float by tying them high or low. The 100 K pot used as an analog input to set the dark level will require 50 µA. The GA1A1S202WP light level sensor requires a maximum of 50 µA.
— ADVERTISMENT—
—Advertise Here—
SLEEPING LIKE A DOG
The watchdog function was designed as a way to reset an MCU should execution get stalled somewhere in code for an excess amount of time. It is a separate timer that runs on its own, so it’s independent of the main oscillator. You can set its timeout period based on your longest routine, plus some safety measure. You would clear the timer periodically—that is, in your Main Loop—which always keeps the WD Timer from overflowing, unless your code gets stuck and doesn’t clear the timer. This might be an RC oscillator or a crystal oscillator if you need better accuracy. The RC accuracy over temperature is +/-20% (-40° to 125° C). I chose to use a 1-second timeout, but this isn’t for protection for stalled code. It’s for sleep duration. The watchdog timer on this MCU can set between 1 ms and 256 s.
This project is designed to wake-up from sleep approximately once a second, do something, and then go back to sleep. The schematic is shown in Figure 1. There are three configuration jumpers associated with this sleep time. These jumpers configure the number of wake-ups, before any further action will take place. The choices for this project are 1 second, 10 seconds, 1 minute, 10 minutes, 1 hour or 10 hours. These can easily be changed to any other delays, because they are just counts based on the 1-second wake-ups. Two LEDs can be enabled in this routine. LED1 can be turned ON upon each wake-up. LED2 can be turned ON upon reaching the configuration count. If the configuration count has not been reached, then the MCU merely goes back to sleep. LEDs 1 and 2 are shut OFF when the MCU goes to sleep. The time it takes the circuit to wake up and run through the counting routine is 300 µs, which is about 0.03% of each sleep period. You want the sleep period as long as possible, to keep the wake-to-sleep ratio as small as possible. Because my minimum time is 1 second, that defines my maximum sleep time.
CHECKING FOR A NEED
The original idea was to be able to turn ON a power-hungry circuit and then go back to sleep periodically. A catch to this was how to know when to turn it OFF. I decided to create an OFF function via an external input. Because this circuit turns ON power to some external device, it only makes sense to allow that external device the ability to signal when it has finished its function. The last function must raise an output, which signals this project that it can remove power and go back to sleep.
There are two possible scenarios that could be used here: go back to sleep immediately, or remain awake until the OFF signal is received. The first works well for when the timeout is short, such as 1 second, but wastes power if the timeout is long because the external device remains powered for a minimum of one timeout period. It seems like a more prudent approach to be able to turn the external device OFF immediately when signaled, so the second approach is used here.
The LM2675 is available with an adjustable output voltage (Figure 2). This means you can set its output to any voltage up to about battery voltage minus 3 V. A feedback input is provided, so the center tap of a voltage divider network will set the output voltage based on the 1.23 V reference voltage across the lower resistor (R1). The typical equation for these adjustable devices is Vout = 1.23 × (1+[R2/R1]). This switching regulator is capable of up to 1 A of current and has over-current and thermal-protective circuitry. Besides the normal external capacitors used with a regulator, a small Schottky diode and inductor are required, along with the two resistors for setting the operational voltage. Fixed output versions can be used, which eliminate the resistor divider. Note: If you’ve designed your circuit for the adjustable regulator and use a fixed-voltage version, a zero-ohm jumper must be installed in place of the upper resistor, tying together the output and feedback input. Power and ground are provided on a three-pin connector that also contains the high enable OFF control input signal.
The idea for this project came while working with the Arduino in last month’s project. I didn’t want the Arduino to draw power while it was just idling. Sleep with an Arduino still requires a good deal of current. I wanted a way to eliminate totally—in a perfect world—all current when an external device had completed its task. For instance, a logging device needs to be powered only to do its “thing” on a periodic basis. Turning it OFF for long periods of time allows battery power to be metered out, ensuring minimum current draw over the long haul.
While designing this circuit, it became clear that a second switching regulator could be added with little additional cost, thereby allowing a second external device to be used for a whole different purpose. Well, not exactly. My lighthouse project integrated a previous project. On the shore at Crystal Lake you’ll find a lighthouse marking the night with a simulated rotating beacon of LEDs (Circuit Cellar 248, March 2011) warning of treacherous coastal obstructions on foggy mornings by playing a foghorn MP3 (Circuit Cellar 339, October 2018).
The method discussed earlier handles the foghorn, while the second switching regulator handles the lighting circuit. We will use a different criterion to determine when the second regulator is ON/OFF. Earlier I mentioned using a voltage divider to determine battery voltage. A total of three analog inputs are monitored by this MCU: battery voltage, pot voltage and an external voltage. The battery voltage is monitored to determine if the battery is of sufficient charge to handle operation of any external devices. Once it drops below a preset discharge level, both switching regulators will remain disabled.
The external voltage input comes from a Sharp Microelectronics GA1A1S202WP light-level sensor. This sensor is logarithmic over a large dynamic range of 3 to 55,000 lux, so it has a lot of sensitivity at low light levels. See Figure 3 for typical light conditions and lux values. The CheckLight() routine compares the light sensor’s reading to that of the adjustable pot’s voltage. You can easily set the pot equal to any level of light, so that the routine will turn ON the second regulator at dusk and OFF at sunrise. Note that the second regulator does not use the OFF control input for this regulator in this instance. Instead, the determination for the state of the second regulator occurs during each periodic wakeup.
VAMPIRING
You can follow the flow chart in Figure 4 of this circuit’s programming written in Assembler. Depending on your needs, this circuit can sleep for 1, 10, 60, 600, 3,600 or 36,000 seconds before actually checking to see if any action is necessary. The configuration jumpers determine which value gets loaded into the 3-byte CountU:L during the initialization. This is the value used to compare with MyCountU:L to determine if it’s time to do some work or just go back to sleep. MyCountU:L is incremented each time the circuit wakes up.
When it’s time to do some work, the battery voltage is checked to make sure it hasn’t been discharged below a safe value. If it is low, it just goes back to sleep. If the battery is OK, then it checks the other two analog inputs, potentiometer and light level. Assuming the potentiometer has been set by the user to an appropriate dusk/dawn level, these analog voltages are compared to determine the state of the dusk flag.
As related earlier, this project uses two different criteria for enabling a switching regulator’s output voltage. The first, REG1, will always enable power output 1 (low), whenever the selected number of wake ups has been reached (once per 10 seconds here). If it’s already ON, that’s fine. Turning it ON again does no harm. Whenever control input 1 is high, power output 1 is disabled (high). In this version, switching regulator 1 remains ON until control input 1 is checked once each time through this code (every 10 seconds). Alternately, you could stall execution here, waiting for the control input to go high.
The second switching regulator uses a local sensor to determine its state (REG2). No control input 2 feedback is used. The power output 2 is merely a slave to the logical outcome of a comparison between light sensor and the potentiometer. I did not implement any hysteresis in this comparison. That said, you may wish to use a bit or two of hysteresis to make sure the output does not flip-flop when the light level is close to the value of the potentiometer.
BLOOD LOSS
Last month’s Arduino project idled at 80 mA to 90 mA. This month’s project is an attempt to reduce idle current by creating a lower-power circuit that can automatically turn a device—such as the Arduino or any other piece of external equipment—ON and OFF at periodic intervals. The current saved will be the ratio of how long the equipment stays ON to OFF.
— ADVERTISMENT—
—Advertise Here—
So, what is the vampire current draw while sleeping? Let’s look at Table 1, showing the worst case scenario for the loads on this project (Figure 5).
The goal for the project was getting to less than 1 mA. So, while this may not be under worst-case conditions, the goal seems to have been met with a rather large safety margin. Your application may require some modification to this code depending on what you are trying to do, but it looks like this circuit can successfully implement reduced sleep currents. And your savings will be most evident when your application need execute only once an hour or even just daily.
Don’t get me wrong—this won’t save a project that draws heavy currents for prolonged periods of time—but it will give your batteries a breather and allow them time to recharge between work periods. 
RESOURCES
PIC16F1823: Flash Microcontroller with XLP Technology
Microchip Technology, www.microchip.com
LM2576: SIMPLE SWITCHER, a 3-A Step-Down Voltage Regulator
Texas Instruments, www.ti.com
MC78LCxx: Micropower Voltage Regulator
ON Semiconductor, www.onsemi.com
GA1A12S202: Log-scale Analog Light Sensor
Adafruit, www.adafruit.com
Microchip Technology | www.microchip.com
Sharp Microelectronics | www.sharpsma.com
Texas Instruments | www.ti.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • NOVEMBER 2018 #340 – Get a PDF of the issue
Sponsor this Article
Jeff Bachiochi (pronounced BAH-key-AH-key) has been writing for Circuit Cellar since 1988. His background includes product design and manufacturing. You can reach him at: jeff.bachiochi@imaginethatnow.com or at: www.imaginethatnow.com.
