Computing stuff tied to the physical world


Low-power blink test

In Hardware, Software on Jan 8, 2012 at 00:01

Here is a new snoozeBlink sketch which can run off the new experimental 12 mW Low-power Supply:

Screen Shot 2011 12 28 at 14 48 03

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:

SCR03

(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:

SCR04

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.

  1. Fascinating results! Note interesting benign side-effects here. The LED on state persists even with the processor put to sleep at bitSet(PORTD,LED);Sleepy::loseSomeTime(PULSE);

    This is because sleeping is stopping the clock, but not removing the power or reseting the chip. So any internal latches (in this case, the PORTxn latch) keep their state at least until the clock restarts after sleep. Any change requests are then executed at some subsequent clock tick. Since the latched value is wired to the corresponding pin through a buffer (still powered on and not connected to the clock) the pin driven state persists; the LED remains lit.

    This also gives some clues to power saving techniques. Any hungry item (e.g. an enabled and loaded pull up resistor) is a candidate for disabling before sleeping – if that makes sense from its function.

    Note also the two LDO’s, effectively in series, aimed at the same output value! Well, the first will do some work (removing the ripple and reduce the reservoir output towards the target 3.3v. The second, hardwired on the Jeenode board, can’t regulate any more (its input is already at the target output value) so “drops out”. For a well designed LDO, this means only that it drops out of the regulation loop, but still continues to pass through input to output as best it can.

    The onboard LP2950 has a PNP series pass transistor that remains saturated, so at 30mA load, loses about 250mV. Since the chip is amazingly tolerant of weak Vcc, operation at lower clock speeds continues normally.

    martynj 8 January 2012 at 10am

    • Nice analysis. There could some trouble with the on-board LOD though (it’s an MCP1702, not an LP2950) – see this post. I need to re-check that with the scope. Pretty amazing, how many things it helps with – though now I’d love to have a programmable power supply to ramp voltages in a controlled manner – it never stops!

      jcw 8 January 2012 at 12pm

  2. Oops, my bad. I took the part number from [here] (https://jeelabs.net/projects/hardware/wiki/JeeNode_specs) instead of looking. So for the explanation above, delete LP2950.. PNP…. about 250mV. and replace by MCP1702 FET continues to conduct.

    The MCP1702 spec sheet contains no useful transfer curves to pin this down – curious.

    A possible mod is to sit the Low-Power LDO on top of an (optional) forward-biased diode in its ground lead (preferably a Schottky) – that won’t shift the SHDN operating point much and gives the JeeNode LDO ~400mV to chew on.

    martynj 8 January 2012 at 2pm

Comments are closed.