Anelok: saving more power (2/2)

Felix sucotronic at
Thu Apr 30 11:51:20 UTC 2015

Wow, 55uA is pretty impressive taking in account that you're using the RC
oscilator :P I'm sure that with the crystal you can get it to the nA range

I was curious about total power usage, so with raw data and a bit of awk:

  cat | awk 'T=0; {SUM += $2*($1-T)} END {print SUM}'
  > 8.72312e+10

¡8.7 uW!

On Thu, Apr 30, 2015 at 12:20 AM, Werner Almesberger <werner at
> wrote:

> 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
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at
> Subscribe or Unsubscribe:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the discussion mailing list