Anelok: saving more power (2/2)

Werner Almesberger werner at
Wed Apr 29 22:20:03 UTC 2015

This is the current consumption for an entire usage session:

Please note that the y axis (current) uses logarithmic scale. For
clarity, I'll write power management states in upper case.

We begin with the power off. Then the lab power supply is turned on and
provides a constant 2.4 V. First, the boot loader runs. Current
consumption is high while in the boot loader because I haven't taught
it any power-saving tricks yet.

Then the Anelok application goes through its initialization procedure
and at about 6.9 seconds, it enters STANDBY (more about this later),
from which I awaken it at around 9.2 s.

Anelok then activates all its subsystems (ACTIVE), briefly displays the
banner, and then proceeds to the login dialog. There I enter the usual
"V".  One can see the brief spikes of activity when I enter one more
position. Also, since the number of active pixels increases with the
number of positions, the overall current slowly increases.

At about 15.2 s I finish logging in and Anelok begins decrypting the
account database. First it calculates the shared key, then it decrypts
the content of records as it draws the account selection list. All this
takes about 2 seconds and Anelok draws 22 mA.

The last state of the login screen is shown through all this. If using
a more optimize implementation of the key agreement won't significantly
reduce the run time, it would make sense to clear the screen to lower
the current demand.

Then the account selection list is shown and Anelok waits for the user
to do something. I did nothing, so it timed out after ten seconds,
cleared the display, and entered DARK1.

I said "ten seconds", so why is the account selection only shown for
eight seconds ? The answer is that the idle time is measured since
entering the access code, so the two seconds of decrypting also count
as idle time.

Anelok sits in DARK1 for ten seconds, still ready to instantly fill the
display with content again. One can see little spikes there, and the
spikes continue also in the following states. This is the LED flashing
for 1 ms every two seconds, to indicate that the device is still
unlocked. Not all the flashes are visible in the current measurements
because there can be gaps of dozens of milliseconds between samples.

At about 35.1 s Anelok decides that I'm not in a hurry to use it and
drops to DARK2, powering down the OLED. The little spike is caused by
my bit-banging SPI driver.

Current in DARK2 is 700 uA but Anelok stays there only for one second,
long enough for everything to stabilize (okay, a few milliseconds
would probably be enough, but who is counting ?)

Then it performs the delicate transition into READY. When it turns off
the boost converter, the system's supply voltage drops from 3.3 V to
the battery voltage, 2.4 V in this case. Since many capacitors are
still charged to 3.3 V, it will not draw any power from the battery for
a few milliseconds.

Then it settles into READY by re-calibrating the touch sensor and waits
some more. I set this timeout to a nominal 60 s, but maybe that could
be shorter.

At about 95 s, Anelok reduces the frequency at which is samples the
touch sensor. This is STANDBY, the lowest power state.

I then awakened the device from its nap and pressed the (virtual) off
button long enough for Anelok to turn off again and "zap" the previous
authentication. Therefore there are no further LED spikes.

To summarize, all looks quite the way it should.

By the way, the raw data and the script to plot the data set are in

- Werner

More information about the discussion mailing list