Wanted to check a few things w.r.t. current consumption of a JeeNode. The old way of doing this was a bit inconvenient, so I made a new test setup:
(old one on the left, new one on the right)
Sturdier, no need to disconnect the multimeter to short it out, and most importantly: high-side current sensing! That’s quite important, because multimeters can add a small voltage drop when used in current measurement mode, and that voltage drop will affect the serial I/O on the FTDI pins when placed in the GND line. Silly me, should have been on the PWR line all along!
The back side of the new connector is trivial:
The multimeter attaches to the top pins, bent apart for easy connection. The jumper shorts it out so this contraption can still be used when the multimeter is turned off.
Ok, time for some simple measurements:
- ATmega full speed, doing nothing: 6.84 mA
- ATmega full speed, with the RFM12B receiver on: 18.42 mA
- ATmega powered down, only the RFM12B receiver on: 11.53 mA
- ATmega full speed, with the RFM12B tranmitter on: 29.92 mA
Idle mode is a simple way to reduce power consumption without changing the logic of the code. It turns the MPU off until an interrupt occurs. Basically, you’re telling it “I’ve got nothing to do until something new happens”. It’s a pretty safe change, and well worth doing in any idle loop which isn’t directly polling I/O pins. The ATmega’s current consumption is slashed by more than half:
- ATmega in idle mode, doing nothing: 2.80 mA
Another way to reduce power consumption, is to slow down the clock at which everything takes place, by setting the “clock pre-scaler”:
- ATmega @ 16 MHz, doing nothing: 6.84 mA (as before)
- ATmega @ 8 MHz, doing nothing: 4.35 mA
- ATmega @ 4 MHz, doing nothing: 2.96 mA
- ATmega @ 2 MHz, doing nothing: 2.02 mA
- ATmega @ 1 MHz, doing nothing: 1.55 mA
- ATmega @ 500 KHz, doing nothing: 1.28 mA
- ATmega @ 250 KHz, doing nothing: 1.16 mA
- ATmega @ 125 KHz, doing nothing: 1.09 mA
- ATmega @ 62.5 KHz, doing nothing: 1.06 mA
Diminishing returns, clearly. Note that lowering the system clock in this way is not necessarily the best choice – getting something done N times faster and then powering down completely might be more efficient (see below).
One thing to watch out for: don’t go below 4 Mhz if you want to be able to use the RFM12B, or the processor will be too slow to process each byte.
When combining this, we get:
- ATmega @ 4 MHz in idle mode, doing nothing: 1.48 mA
- ATmega @ 62.5 KHz in idle mode, doing nothing: 1.03 mA
The advantage of this approach is that the clock is still running on the 16 MHz resonator (which probably draws most of that remaining current), so you’re still able to keep track of time – just more slowly.
A different approach is to go into real low power mode, and use the watchdog to get back out of this comatose state. The watch dog timer is less accurate, but depending on your application that may not be an issue.
Here’s the current consumption with the ATmega alternately in full speed and in power down mode:
- ATmega 16 ms @ 16 MHz / 16 ms powered down, doing nothing: 3.49 mA
- ATmega 8 ms @ 16 MHz / 16 ms powered down, doing nothing: 2.31 mA
- ATmega 4 ms @ 16 MHz / 16 ms powered down, doing nothing: 1.39 mA
- ATmega 2 ms @ 16 MHz / 16 ms powered down, doing nothing: 0.80 mA
- ATmega 1 ms @ 16 MHz / 16 ms powered down, doing nothing: 0.46 mA
That last one does about the same amount of work as when running constantly @ 1 MHz, but with a third of the power consumption. Here is the corresponding sketch:
And it will continues to scale downward:
- ATmega 100 µs @ 16 MHz / 16 ms powered down, doing nothing: 90.4 µA
Which still represents 100,000 active processor cycles per second…
And lastly, let’s take it into power down and run for just 1 ms per second, i.e. 0.1% of the time. I can’t measure this with the multimeter, because the power use jumps up every second, but the comatose period draws a mere 6.8 µA, which is consistent with what has been reported several times before (the watchdog is still active, and so is the brown-out detector).