Werner Almesberger | 21 Jun 21:19 2015

Anelok: new logo !

A few weeks ago, I proudly showed my Anelok to Martin De Luca, a
designer friend of mine. He was duly impressed by all the technology
but hated the logo. So he made a new one.

I added a few tweaks to make it look good on the real hardware, and
here is the result, in simulator and "live":


I love the clean modern simplicity of the font and how cleverly he
added the padlock symbol. While the padlock was his own idea, I had
though of having that element, too, but could never figure out how
to do this nicely.

The concept has a few degrees of freedom. Below are a few slight
variations. First, the same design, this time black on white:

A slight variation: the E has its usual backbone:

- the lock is more centered, between "walls" on both sides,
- easier to read (due to familiarity),

- more boring (due to familiarity).

Another variation: this one makes lines and gaps the same width,
(Continue reading)

Marcus Moeller | 13 Jun 19:27 2015

Supertux Performance

Hi all,

I am trying to play Supertux on the current OpenWRT based build. Sadly 
it's very slow and most often the first level does not even start. Is 
there a way to improve this behaviour? I have tried to play around with 
the overclocking settings in the gmenu configuration, but it does not 
seem to change anything.


Attachment (smime.p7s): application/pkcs7-signature, 5069 bytes
Hi all,

I am trying to play Supertux on the current OpenWRT based build. Sadly 
it's very slow and most often the first level does not even start. Is 
there a way to improve this behaviour? I have tried to play around with 
the overclocking settings in the gmenu configuration, but it does not 
seem to change anything.


Werner Almesberger | 30 May 19:49 2015

Anelok: refining the wedge

I added a few internal components to the CAD drawing. This is
what the current design looks like:


The antenna gets all of the left side. I thickened the slider PCB
to 1.6 mm so that it can act as lateral stop for the OLED (1.45

I also added a board-to-board connector to firmly attach it to
the main PCB. (That should be the end of the flimsy wires going
from board to board, whose mysterious failure modes have been
giving me much joy lately.)

The LED moves from the main PCB to the top end of the slider PCB,
eliminating the need for a dodgy improvised light pipe. 

USB Micro B and memory card are mounted under the main PCB. The
switch goes above USB. That's not the nicest place for it, since
it may be difficult to reach if something is connected to USB,
but I like the idea of also using it as a support for the slider
board. We'll have to see how the idea pans out in real life.

The switch is also 1 mm from the PCB edge, so there would be
1.0 mm + 0.2 mm (gap) + 1.5 mm (wall) for adding a slider with a
proper knob.

That's all for now. I don't know yet whether this design would
actually fit, but some on-going experiments look encouraging.

(Continue reading)

Werner Almesberger | 26 May 18:34 2015

FYI: Kinetis L series 32-pin cheat sheet

I made a cheat sheet for the pin assignment of Kinetis KL1x and KL2x
MCUs in 32-QFN packages. It is for the KLx4, KLx5, KLx6, and KLx7
variants. This may be useful also for projects beyond Anelok.


A quick summary of the main feature differences I found:

Feature			KL1x	KL24/25/26	KL27
-----------------------	-------	--------------	------
USB			no	OTG (dev/host)	device
Voltage regulator	no	y		y

Feature			KLx4	KLx5	KLx6	KLx7
-----------------------	-------	-------	-------	-------
Interrupts on ports	A,C	A,C	A,C,D	A,C,D
Pull up/down		up	up	up/dn	up/dn
High current drive pins	4	4	4	6
ADC differential inputs	-	y	y	y
12 bit DAC		-	y	y	y
TSI (touch)		-	y	y	-
FlexIO			-	-	-	y
Max kB Flash in 32-QFN	128	128	128	256
Max kB RAM in 32-QFN	16	16	16	32

There are some other small differences, such as KL25 and KL26 having
a different register layout (so they're almost source-compatible but
not binary-compatible), some clock generation variations, etc.

(Continue reading)

Werner Almesberger | 24 May 02:00 2015

Anelok: a dummy case for AAA (2/2)

This all looks nice so far. However, the path to get there turned out
to be a lot stonier than I had expected. The problem is that my mill
is acting up badly along the Z axis, reducing the depth by up to
almost half of what the CAD model says.

Here is an example. This is what the slices look like in FreeCAD:


And this is what came out:


The nominal thickness of 17.5 mm yielded pieces between 9.3 and 10.3 mm.
The jump from ~10 to ~9 mm may have been caused by setting the depth of
the bottom such that the mill would cut well below the floor of the upper
MDF block. By the way, double-sided adhesive tape and MDF form an
amazingly strong bond, making it quite an effort to pick the slices from
the block after milling.

The depths of the cut-outs for screw heads are even more puzzling:

Nominal		Measured	Factor
--------------- --------------- ---------------
 5 mm		3.7-4.0 mm	74-80%
 8 mm		 5.0 mm		63%
10 mm		5.6-6.3 mm	56-63%

Just weird.

(Continue reading)

Werner Almesberger | 24 May 01:39 2015

Anelok: a dummy case for AAA (1/2)

I decided to give the YZ slices a try, to find out what the new form
factor would feel like. This is my mill, after making a mess:


This is what it produced, with the sawdust shaken off, not sanded:


After a bit of sanding, the slices already looked a lot more civilized:


These are the pieces I made:


The big hole is for the battery, the small holes are for 1/8" screws.
Some of the pieces on the left side also have larger partial holes
for the screw head or a nut. That way, I can use the screws I have at
home, which would be a bit too short to span the entire width. And it's
also neater if no parts of the screws protrude.

Here is a size check of the assembled package:


This is what it looks like compared to the CR2032 case design:

(Continue reading)

Werner Almesberger | 18 May 20:59 2015

Anelok: exploring the deep end

TL;DR: boost converter happy with AAA-type input, after all

A while ago, I tested how Anelok behaved at low batter voltages:

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
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

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.
(Continue reading)

Werner Almesberger | 30 Apr 00:20 2015

Anelok: saving more power (2/2)

This is the current consumption for an entire usage session:


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
(Continue reading)

Werner Almesberger | 29 Apr 19:28 2015

Anelok: saving more power (1/2)

Revisiting the "empty" battery

First an update on how deeply Anelok discharged its battery during
the first "solo" run, about a month ago:

I put it to the usual discharge test, discharging into a 15 kOhm
resistor. This is the result:


For comparison, this is the result of the original test from February
and March, with a new battery:


Both batteries were 7 years old Sony cells, so one can compare the
results directly. The initially new battery crashed through 2.4 V
after about 1030 hours, while the one that had spent a productive if
short life in Anelok reached that point after about 500 hours.

So this means that Anelok could use more than half of the battery's
energy content. And that's still before optimizing any capacitors.


So far, so good. But it's still not nice that Anelok is merrily
suckling 0.7 mA (board #2) to 0.9 mA (board #1) from the battery
while doing absolutely nothing useful. 
(Continue reading)

Werner Almesberger | 28 Apr 18:59 2015

Anelok: using NaCl

I implemented a first proof of concept prototype of encryption, based
on NaCl's crypto_box [1] using the TweetNaCl implementation [2].

The this proof-of-concept is quite crude: there is only one reader,
keys and encrypted data and kept in memory forever, the account
database is linked into the code, and the only way to create or edit
accounts is by running a scary collection of programs on the Linux

Code size

Nevertheless, this exercises more than half of the crypto system and
provides a realistic workload. Code size comparison:

	   text    data     bss     dec     hex filename
Base	  24676    1416    4200   30292    7654 anelok-2014.elf
Dynamic	  25484    1200    4200   30884    78a4 anelok-2014.elf
Decrypt	  29180    1200    4200   34580    8714 anelok-2014.elf

"Base" is the version before all the crypto work, where the account
database was not encrypted and just hard-coded.

"Dynamic" changes various APIs to work with account information that
is not available at build time. As a consequence of one of the API
changes, the account database could now be "const" and thus moved
from "data" to "text".

"Decrypt" then adds TweetNaCl and decryption. The code size increase
is quite moderate, which means that we still have a lot of room for
(Continue reading)

Werner Almesberger | 19 Apr 16:10 2015

Anelok: first try at crypto: for further study (4/3)

My last few mails may have made the topic of cryptography in Anelok
look trivial and boring. But don't worry, there is more:

- structuring of information: I already mentioned one aspect in the 
  second mail: there may be one block of key data for each account 
  record or multiple records could share a block. What makes the most
  sense ?

  There are also other issues, like how we represent directories and
  different access levels.

- what part of the account information should be  encrypted and what
  not ? Encrypting everything may be the safest choice, but are there
  major drawbacks ? Does computational overhead go through the roof ?

- management of the list of authorized readers and writers. How does
  a device learn about changes in the list ? How are the changes
  validated ? And how many such lists are there anyway - just one per 
  user (shared and synchronized among all the user's devices) or
  multiple ?

- what algorithms to use ? I'm pretty much set on Curve25519 [1] for
  ECDH, but what for symmetric encryption, what for hashing, what
  key derivation function ? We'd also want algorithms that are
  reasonably compatible in what data they expect and produce, and
  how they stretch or lose entropy.

- last but not least, what implementations ? There are quite a lot of
  implementations for ECDH alone [2, 3, 4, 5, 6, 7] (and that's just
  the smaller packages) and there are more when we consider ECDSA as
(Continue reading)