Werner, 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. Mumbling... 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 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 805-567-4670 On Mon, Jan 6, 2014 at 6:23 AM, Werner Almesberger <[email protected]>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: > > http://downloads.qi-hardware.com/people/werner/anelok/tmp/bat-test-rig.jpg > > 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: > > > http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd0-display-on.jpg > > 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: > > > http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd0-display-on-drop.jpg > > 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): [email protected] > Subscribe or Unsubscribe: > http://lists.en.qi-hardware.com/mailman/listinfo/discussion >
_______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
