anelok: battery measurements
Ron K. Jeffries
rjeffries at gmail.com
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
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  No-(anelok)-usage days (rare, but it will happen during holidays or
no internet access
B  Light anelok usage: one time per 120 minutes, over 10 hour day
C  Moderate usage: one time per 60 minutes over 10 hour day
D  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 almesberger.net>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 lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discussion