anelok: battery measurements

Ron K. Jeffries rjeffries at
Mon Jan 6 11:59:17 EST 2014


Strictly intended to stimulate discussion in the community.

What is your design target for battery life when anelok is used as a
password safe?

For wide adoption, I think anelok battery replacement cycle of every three
months is a reasonable lower bound. Six months would be better; once a year
(New Year's eve? ;) would be ideal.


I'm wondering how many times per day a "normal" anelok user will use it to
insert a password?
Thinking about this, here are some numbers. YMMV

First number in square brackets for each use case below is number of times
anelok is used per 24 hours

A [0]  No-(anelok)-usage days (rare, but it will happen during holidays or
no internet access
B [5]  Light anelok usage: one time per 120 minutes, over 10 hour day
C [10] Moderate usage: one time per 60 minutes over 10 hour day
D [40] Heavy usage: anelok used once every 15 minutes over 10 hour day

parameters are a WAG, to be be modified for sensitivity analysis yada yada

10 hour "active at computer" day-length  (above) was for ease of
computation in my head.
for many users a better number might be 16 hours

Taking the 16 hour period, and thinking about varying patterns during my
day, and how often I am signing into services, (and including all my mobile
usage) my guess for me is:

40 (per day) "anelok ON" (to provide password) events x 80 pct of days

10 (per day) "anelok ON" x 10 pct of days

5 (per day) "anelok ON" x 7 pct of days

0 (per day) "anelok ON" x 3 pct of days (one day a month)

doing the math, these estimates suggest 36 "anelok ON" events per day,
using 10 hour days

32     0.8 * 40
1        0.1 * 10
3.5     0.7 * 5
0.0    0.3 * 0

This pattern obviously ignores need to add new passwords or other data.
That will be much less frequent, but will also require considerably longer "
anelok ON" and consuming a]power in active state.

Ron K Jeffries

Ron K. Jeffries

On Mon, Jan 6, 2014 at 6:23 AM, Werner Almesberger
<werner at>wrote:

> One of the big questions I still aim to answer with the first board
> is whether a) the CR2032 battery is up to the task and b) if there
> are any changes that should be made to improve power consumption.
> I built a little test rig that tests a real battery:
> The aligator clips go to a multimeter to measure static current,
> the two probes are for battery voltage and the LED which acts as
> trigger/marker signal.
> The signals captured look like this:
> This shows the response to pressing the button:
> - the MCU detects the button press and very briefly flashes the LED
>   (about 8-9 mA, causes a slight drop in battery voltage), then
> - resets the display (the prolonged drop of about 300 mV is caused
>   by the display reset function busy-looping in mdelay instead of
>   waiting in msleep. Need to change this.)
> - after the reset, the display is activated. This causes a sharp
>   drop of almost 1 V that could reset the device if it was a little
>   deeper and/or if the battery was a little weaker.
> - after that, the display is erased, I generate another LED flash
>   to indicate that display_on has returned, display the "-" PIN
>   entry prompt, and wait for further user input.
> The drop seems to be caused by inrush current of the display's
> DC-DC converter. This is what it looks like when zooming in:
> This should be fixable by adding a hopefully not too large
> capacitor on Vsys.
> The screenshots show something else: my scope has lost the ability
> to make digital screendumps :-( This may be related to the USB
> excinction event that killed two powered hubs last year. I'm still
> not sure what did it and how.
> Without proper screenshots, analyzing battery behaviour and
> especially documenting it will be messy. So I'm trying to resove
> the half-dead scope situation first ...
> - 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