This is the current consumption for an entire usage session: http://downloads.qi-hardware.com/people/werner/anelok/tmp/current-session.png
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 https://gitlab.com/anelok/anelok/tree/master/meas/session/ - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
