Anelok: exploring the deep end
Ron K. Jeffries
rjeffries at gmail.com
Tue May 19 20:25:41 UTC 2015
Wener,
My sense is you are close to a decision that CR2032 will not support anelok
operation for a long enough period of elapsed calendar time. I've argued
that "elapsed days between battery swap" period should be stipulated as a
design objective, but that's just me. I will not revisit that subject.
Honest.
Have you considered a case mod that would allow say 2xAAA batteries?
ron j
---
Ron K. Jeffries
805-567-4670
On Tue, May 19, 2015 at 12:48 PM, Dave Ball <qi-hardware at daveball.org.uk>
wrote:
> Another excellent and enlightening writeup Werner!
>
> Dave
>
>
> On 18/05/15 19:59, Werner Almesberger wrote:
>
>> TL;DR: boost converter happy with AAA-type input, after all
>>
>> A while ago, I tested how Anelok behaved at low batter voltages:
>>
>> http://lists.en.qi-hardware.com/pipermail/discussion/2015-March/010832.html
>>
>> The result was that it did reasonably well at anything we could expect
>> from a CR2032 cell, but would become unstable at 1.4 V, which is
>> uncomfortably close to the best-case voltage an AAA cell would provide.
>>
>> I couldn't quite explain why this was so, given that the boost
>> converter is specified for operation with a battery voltage as low as
>> 0.8 V.
>>
>> While I lay sleepless last night, it finally hit me: it's Q1 again !
>>
>> Let's look at
>> http://downloads.qi-hardware.com/people/werner/anelok/tmp/power-tree.pdf
>> to see what's going on:
>>
>> The battery voltage is applied before Q1. The purpose of Q1 is to
>> disconnect the battery if USB provides power. Q1 is a FET with a gate
>> threshold voltage of about 1.0 V. If the battery voltage is at or below
>> that gate threshold voltage, the FET will not conduct at all. If the
>> battery voltage is only a little higher, it will conduct, but
>> reluctantly.
>>
>> According to the data sheet [1], we need at least 1.2 V before it will
>> admit the sort of current the boost converter needs at such a voltage.
>> Worse, at that point it still has a resistance of > 1 Ohm, so we will
>> need an even higher voltage before things can work.
>>
>> So I re-ran the experiment, with the current firmware, which may behave
>> slightly differently than the March version. Again, I let Anelok boot,
>> then turned it on, and entered the login-setup screen. The results are
>> pretty much like the previous ones:
>>
>> Vbat Ibat Pbat Comment
>> (V) (mA) (mW)
>> ------- ------- ------- -------------------------------------------------
>> 2.4 14.6 35.0 Lab reference condition
>> 2.3 15.4 35.4
>> 2.2 16.3 35.9
>> 2.1 17.3 36.3
>> 2.0 18.4 36.8 Boot at 2.1 V, then lower
>> 1.9 19.6 37.2
>> 1.8 21.1 38.0
>> 1.7 22.8 38.8
>> 1.6 25.0 40.0
>> 1.5 30 45
>> 1.4 50 70
>> 1.3 33 42.9 display is noticeably dim
>> 1.2 - - turns off
>>
>> At 2.0 V and lower, Anelok would no longer boot. This is the work of
>> the battery-guzzling boot loader that doesn't (yet) have the decency
>> of at least turning on the boost converter. The fix for this is to boot
>> at 2.1 V, proceed to the setup menu (the boost converter is now
>> active), then dial the voltage down.
>>
>> That way, I made it down to 1.4 V without visible issues, but with the
>> power consumption already going through the roof - a bad omen.
>>
>> At 1.3 V the display got quite dim (also, notice the current
>> drop - this is the boost converter losing control of the situation).
>> I didn't test to what extent the device would be able to do anything
>> else but display that list, e.g., decrypt keys, scroll, etc.
>>
>> So this confirms the old measurements. Then I moved my "battery" past
>> Q1, so that it would directly feed the boost converter. Again, the
>> same ritual:
>>
>> Vbat Ibat Pbat Comment
>> (V) (mA) (mW)
>> ------- ------- ------- -------------------------------------------------
>> 2.1 17.2 36.1
>> 2.0 18.2 36.4 Boot at 2.1 V, then lower
>> 1.9 19.4 36.9
>> 1.8 20.7 37.3
>> 1.7 22.2 37.7
>> 1.6 23.9 38.2
>> 1.5 26.0 39.0
>> 1.4 28.3 39.6
>> 1.3 31.3 40.7
>> 1.2 34.9 41.9
>> 1.1 39 43
>> 1.0 46 46
>> 0.9 56 50
>> 0.8 61 49 normal operation, slight flicker when scrolling
>> 0.7 58 41 flickers when scrolling account list
>> 0.6 45 27 display is noticeably dim; dies in crypto
>> 0.5 27 14 display very dim; powers down when interacting
>>
>> Now, that's much nicer, isn't it ? :-) While performance at higher
>> voltages is nearly identical to what we had before, the battery power
>> increases only slowly as the voltage decreases, and the problems only
>> begin at voltages that would signal the imminent death of a real AAA
>> cell anyway.
>>
>> So this means that the boost converter works as expected for simulated
>> AAA-type conditions. Q1 will either have to move to the 3.3 V side of
>> the converter in a AAA-based design, or maybe get replaced with a
>> dedicated switch chip that has generally nicer properties.
>>
>>
>> One quick note about the points at which the device failed at extremely
>> low voltages: while testing the latest power-saving features with a
>> CR2032 cell, I found that, while Anelok would turn on nicely also after
>> several days, it would only make it past decryption in the first few
>> days. The steps are as follows:
>>
>> 1) in standby, screen is dark
>> 2) turn on, logo appears, then the login screen
>> 3) enter "PIN"
>> 4) generate the shared secret key (this is computationally expensive)
>> 5) display the list of accounts. For this, each record is accessed
>> multiple times, and decrypted each time
>> 6) when scrolling the whole display process is repeated frequently,
>> with data transfers to the OLED
>>
>> The battery was strong enough to make it to 4) but then died while
>> calculating the key. I solved this by displaying a progress indicator
>> that consists of only a few pixels, so the display consumes much less
>> power than if I let it show the last state of the login screen.
>>
>> This way, I got all the way to 5), I then still had it fail when
>> scrolling (6). Scrolling the account list is particularly inefficient
>> because many records are decrypted unnecessarily, and the transfer to
>> the display is done by bit-banging GPIOs and busy-waiting between
>> changes.
>>
>> Using the SPI hardware in the chip should allow Anelok to take little
>> naps during display updates, which will probably be enough to make
>> their power consumption quite bearable. This is something further down
>> the to do list.
>>
>> I also tried to improve decryption activity by implementing a kind of
>> lazy evaluation, but to my surprise, this only killed the device
>> faster :-( Well, in the end, Anelok should probably just decrypt the
>> list once and then cache it. Another to do item.
>>
>> - Werner
>>
>> [1] http://www.diodes.com/datasheets/ds31784.pdf
>>
>> _______________________________________________
>> Qi Hardware Discussion List
>> Mail to list (members only): discussion at lists.en.qi-hardware.com
>> Subscribe or Unsubscribe:
>> http://lists.en.qi-hardware.com/mailman/listinfo/discussion
>>
>
>
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
> http://lists.en.qi-hardware.com/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20150519/17aa7781/attachment.html>
More information about the discussion
mailing list
