Anelok: energy efficiency, first steps

Werner Almesberger werner at almesberger.net
Thu Mar 26 23:03:01 UTC 2015


After the not-so-good-looking power consumption I measured after
the rework, I now tried to bring it down a little by improving the
firmware. What follows are a few easy modifications.

To see the effect of a change, I ran a script that powers
Anelok, lets it boot and enter "standby" mode, then cuts power
again. During all this, it measures the current consumption with
a multimeter.

The multimeter (Fluke 8845A) is not nearly as fast as an
oscilloscope, so the time resolution is limited and short spikes
may appear smaller than they really are.

The script repeats each test five times. Here are the results:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/current-reduction-1.png

Step 0: the lay of the land
---------------------------

"git ac435a21": is the situation with the original code. Let's
examine a typical sequence:

8.1 s: power from the lab supply is switched on. The supply
  (Hola DP-1805A) is set to 2.4 V, current limited to 100 mA.
  The switching is done by labsw (using relays).

  The boot loader waits for USB to appear. It is not every
  power-efficient at this (it busy-waits) and draws about 9.1 mA.
  Eventually, it gives up and ...

11.2 s: the application starts. It immediately activates the boost
  converter,

11.5 s: activates the display panel (with all pixels black),
  calibrates the slider (the about 100 ms of constant current
  after the spike from display activation), and

11.6 s: enters "standby". In standby, the display is dark and
  Anelok checks for slider input. As one can see, it is quite busy
  doing nothing, at an average cost of about 17-18 mA.

13.4 s: power is cut and the battery supply is shorted to ground
  to discharge capacitors.

The following things are troublesome with this picture:

- overall current consumption is sky-high, considering that the
  display is dark throughout all this and that there is no major
  computation,

- nasty spikes in battery current demand when turning on the boost
  converter and when turning on the display. Such spikes cause
  battery voltage to drop, which can destabilize the boost
  converter and cause the system voltage to drop too low.

The very first spike in each cycle, when powering on, is less of a
concern because the MCU can just reset at this point and try again.
So as long a any progress towards stable operation (e.g., a
capacitor gets charged a little more) is made in such a cycle, the
system will eventually come up fine.


Step 1: reducing base current
-----------------------------

"CC off": first, I realized that the RF chip (CC2543) is probably
  running wild through all this, since the boot loader releases it
  from reset before starting the application, I probably haven't
  loaded any firmware into it that would teach it better manners,
  and the Anelok application doesn't do anything to stop it either.

  The "CC off" plot shows what happens if the application resets
  the radio chip and holds it in reset: overall current consumption
  drops by about 7-8 mA.

"1000 ms break": to further clean up base current consumption, I
  added a one second sleep early in application start. Current at
  that point is 1.1 mA.

"disable USB regulator": the next thing to turn off was the USB
  regulator. If it is on but there is no power coming from USB, it
  will draw a bit of current. Turning it off brought base current
  consumption down to 700 uA.

"rfkill": the radio chip still consumes a bit of power when held in
  reset. I could have uploaded firmware that puts it into a deep
  sleep, but being lazy, I just threw the rfkill switch.

  We're now down to something like 10 uA (i.e., the measurement
  resolution selected for these experiments). Good enough.

  Note that rfkill also lowers the current drawn while in the boot
  loader. It's now about 6.8 mA.

"revert 1000 ms break": since we're done with lowering the base
  current, I removed the sleep. Things already look a little
  friendlier, but we can do better.


Step 2: taming the spikes
-------------------------

"step boost converter activation": to fight the current pulse when
  activating the boost converter, I added 100 ms sleeps before and
  after it, giving the system time to charge all the capacitors,
  and also reducing MCU current consumption.

  This doesn't make the spike go away completely, but things are
  definitely looking better.

  A quick calculation shows that the boost converter seems to
  perform roughly as expected: the boot loader, i.e., with the MCU
  running all the time and with the boost converter inactive,
  draws some 6.8 mA (see above).

  After coming out of the sleep at the end of boost converter
  activation, Anelok draws some 10.5 mA when busy-waiting.

  The boost converter converts 2.4 V to 3.3 V. If we assume that
  the MCU draws the same current in either case, a perfect boost
  converter would need 6.8 mA / 2.4 V * 3.3 V = 9.35 mA.

  The AAT1217 has a nominal efficiency of about 80% under these
  conditions, which would mean about 11.7 mA. 10.5 mA would be an
  efficiency of 89%. Close enough :)

"use msleep in power_3v3": there is a tiny little mdelay(1) after
  switching on the boost converter. mdelay busy-waits while msleep
  enters a low-power mode while waiting.

  Changing the mdelay to msleep seems to further reduce the spike.

"use msleep in display.c": there are plenty more large mdelays in
  display activation, before the final spike. Changing them didn't
  make any spikes go away but it removed that 10.5 mA step.

"activate display in steps": the OLED panel is brought up in
  several steps. Instead of doing them all at virtually the same
  time, I added 100 ms sleeps between them, to give the system
  time to settle.

  It seems that this helped to further improve the spike situation.


Step 3: lowering standby current
--------------------------------

"display off in ui_off": this is the last improvement for now.
  I changed ui_off to turn off the (dark) panel while waiting.

  This reduced average current in standby to about 6.7 mA.

  One drawback of this change is that it moves all the delays we
  now have in display activation into the time between pressing
  the slider and Anelok either accepting or rejecting the
  activation. In practice, this means that the visual feedback is
  too slow and one has to guess the correct timing.

  This should be easy to improve by reducing these 100 ms delays
  that are deliberately on the excessive side.

Now, 6.7 mA means that Anelok in standby (!) may last for a day on
battery power. That's still quite far from acceptable performance.


However, standby can be improved a lot. E.g., since there is
almost nothing to do, we could even turn off the boost converter.
Doing this will require reducing the now very long sleeps to more
reasonable values, preferably based on measurements of how much
time the system really needs to settle.

But even when leaving the boost converter on, there are still busy
waits in the touch sensor driver. These are the next issue to
attack.

Last but not least, getting rid of the spikes will probably
require additional capacitors, with the general idea being that
each switch that leads to a "downstream" capacitor of significant
size will have a larger capacitor on the "upstream" side.

"Upstream" capacitance can usually be bundled, so the design
changes may not be too large in the end.

To be continued ...

- Werner



More information about the discussion mailing list


interactive