DIY ATmega328 Clock - improved power saving

I built a clock as fun and training project two years ago. There is always room for improvement - first I had a 7 segment LED which I multiplexed at 1kHz and used the time in between to sleep the µC. I tested several RTCs, from DS1302 over 1307 to the DS3231. The DS3231 is in place with a Nokia5110 display now for half a year and led to significant better time keeping and less power usage.

ATmega328 based DIY Clock.

Several further sensors are attached - the Si7021 measures temperature and humidity. Cool thing about the IC is that it does its measurement and goes to sleep immediatly, consuming less than 1µA.
Another sensor is a BH1750 which is used for only activating the display when there is enough light to read it. As soon as it is dark, the display gets disabled, further dropping the current drawn.

Today I added two further improvements to bring the power consumption down a little more. For one, I modified the Wire-library of the Arduino GUI to not activate the I2C pullup resistors. On those sensors, there are Pullups in place already.
Find your arduino-directory, go to hardware\arduino\avr\libraries\Wire\src\utility and open twi.c - there you can search for "pullup" and comment out both lines where the SDA/SCL pins are set to 1 (which enables the pullup resistor on an input pin).

Power consumption via 1R shunt on the oscilloscope.

This led to the current drop to 0µA every now and then.
So I decided that 100kHz I2C speed may be a little slow and keep the µC awake longer than necessary. So I added the line
TWBR=12
at the end of the setup()-routine.

This value fits for 16MHz µCs and results in 400kHz I2C speed. Looking at he graph it can be seen that the I2C reading is now taking only a short fragment of a second instead of nearly half of it as it did before. The values are close to 1mV for 1mA, but with such low values, this setup is distorted by noise a lot and doesn't show the precise load values. The multimeter shows peaks of ~3mA and sleep periods with real 0µA.
Before these changes, with a proper low-quiescient-current ultra-low-dropout regulator like the MCP1700, the LiIon battery with 2400mAh lasted for exactly three months. Let's see how long the new battery will last this time! I'll update the article when the battery is empty.

Power supply for µCs via LDOs

There are plenty of LDOs on the market - some cheap, some expensive, some with only three terminals, other with 5 or more. So how to decide upon a good LDO (Low DropOut regulator)? And why use a LDO when it literally burns energy within it's pass transistor? A switching regulator feels way more efficient as it only takes as much energy from the source as is needed on the output?

This all depends on your usecase. If you have no constraints in your power supply scheme like when using a USB power supply or a 12V switching power supply, you may use a switching regulator. It has a little ripple on the output voltage which may be disturbing in some cases, for example if you want to use an ADC. But it won't get too hot, and 12V down to 5V or 3.3V can be done quite efficient for medium loads.

Here's the point: It depends on your load. A switching regulator won't adapt as fast to changing loads, for example when a µC goes to deep sleep and suddenly wakes up. There the load will jump from a few µA p to 100mA or more. For the time when the µC is sleeping, the quiescient current of the switching regulator is usually many times higher than that of the µC. If the µC is sleeping long time and only wakes up every so often - or your wake-up load is below for example 10mA-, a LDO is the more efficient choice.

For my DIY clock and my mobile ESP8285-based sensor I wanted the most efficient LDO possible. The newest and most promising ICs are in form factors that are nearly impossible to solder by hand. So it had to be SOT23 size ICs. (N.b., old ICs like *7833 or *1117 have a high quiescient current of ~5mA, usually making then unusable with battery driven gear.)

Most efficient LDOs for DIY use.

For the 3.3V with a load of 250mAh and even more I found several ICs:
- HT73xx (7µA Iq)
- HT78xx (8µA Iq)
- XC6206 (2µA Iq)
- MCP1700 (2µA Iq)


I built up small PCBs which I could solder in front of my Clock and ESP.

They all delivered the load and voltage as expected. Differences became obvious, though.
The XC6206 is the cheapest of all those ICs. Unfortunately, it has a dropout voltage of max. 680mV at 200mA load. While this is great when your power comes from a USB supply, it means that a LiIon battery can be used only down to 4.0V! Also, the XC6206 becomes unstable very soon when driven by a LiIon battery with a voltage range of 3.0-4.2V. It is very sensible to load changes as well and starts to swing easily. I needed to provide a polarity protection as even short reverse polarization leads to a burnt chip.

Power consumption with different LDOs.

While the HT78xx (500mA max) and HT73xx (250mA max) also seemed to give stable performance, they didn't cope well with the load profile of sleeping 290s at <25 µA and then wake up for ~600ms at 70mA with short spikes of 250mA and more. Same behaviour shows with the clock which constantly switches between ~2mA and ~100µA. The datasheet has no graphs or values for the supply current with loads bigger than 40mA. The reason seems to be that the load on the battery significantly increases. The battery lost more than 15mV per day with these ICs. They're great when there is a wall plug involved or a huge battery and other big power hungry components, but for the ultra low current consumption I need they just don't cut it.

So the MCP1700 is the most stable and real economical LDO in this test field. Battery voltage drops about 5mV per day, leading to a runtime of roundabout half a year with my 900mAh LiIon battery.

My next tests are with lowering the voltage to 3.0V. The HT7330 showed the same behaviour as the HT78xx/HT73XX with 3.3V before and put a too big load on the battery. Interesting effect - after a runtime of more than one day, the HT78xx became much more stable and reduced the power consumption to values close to the MCP1700 ICs. I'm still waiting for MCP1700-302, I hope to shave off even more µAs to prolong the runtime with them.