It does all the right things to start off in low-power mode and puts the ATmega to sleep, even as the LED blinks!
The LED is a normal red LED with a forward voltage of about 1.6V and with a 470 Ω series resistor. The result:
(lots of noise because I’m using the default 1:10 probe and the scope at its most sensitive 1 mV/div setting)
Voltage over the 100 µF reservoir cap in blue, current consumption in yellow. You can see the startup dip when the cap reaches about 6V, then the 2s wait, and then the LED blink at about 2 Hz with a 10% duty cycle. There’s not much energy to spare – the reservoir cap doesn’t even get a chance to fully re-charge between blinks.
After about 4 seconds, I turned off the power to find out what would happen. Yet there’s still enough energy left to get two more full blinks, and then an aborted blink as the reservoir cap voltage drops below 3V.
Note how the power consumption is just 3 mA while the LED is turned on. The ATmega itself is hardly ever running (the very brief 10 mA peaks got filtered out in this scope capture).
It can even be made to flash with a 26 mA LED current (omitting the resistor) for 16 ms @ 2 Hz. In this case the reservoir cap voltage varied from 9.4 to 4.4 V, again leaving very little energy to spare. Maybe one day this can be refined to drive a TRIAC, which needs very frequent but brief pulses (a BT137, BTA312, or L6004L3?).
But there’s actually something extra-ordinary going on with that power-up sequence – let’s investigate:
The BIG surprise? This is running on a standard JeeNode with standard bootstrap – no power-up troubles at all!
Let me try and interpret everything happening in that last image:
- the initial very high blip (over 25 mA) is the JeeNode’s on-board 10 µF capacitor charging up
- the 65 ms @ 3.2 mA is the clock startup delay, as defined by the default fuse setting
- up to this point, the reservoir cap has lost some 2V of its charge
- the next blip is the boot loader passing control immediately to the sketch (!)
- then there’s the 32 ms loseSomeTime() call in setup(), with the ATmega finally powered down
- the last blip at the right-end side of the screen puts the RFM12B into low-power sleep mode
So what’s going on, and above all why is the boot loader problem gone, after all that trouble it gave me before?
The only explanation I can think of lies in the one change I made since then: I’m now using OptiBoot v4.4 … and it probably does the right thing, in that it skips the boot loader on power-up and only goes through a boot-loader sequence on reset. This is the well known ladyada fix. I guess my previous boot loader setup wasn’t using that.
This is really good news. It means you just need a recently-flashed ATmega and you can continue to use the normal FTDI upload mechanism while fooling around with this ultra low-power stuff. Even the 10 µF cap and regulator on the JeeNode can be left in when powering it from the new Low-power supply.