Werner Almesberger | 19 Aug 03:42 2014
Picon

Anelok: user interface simulator

To make user interface development a bit faster, I've written a simulator
that provides "touch" input (from the X pointer) and displays the result
in an SDL window.

To run it, do this (main prerequisites: SDL, SDL_gfx):

git clone git://gitorious.org/anelok/anelok.git
cd anelok/sim
make
./sim

Now a little (128 x 64 pixels) black window should appear. Left-clicking
corresponds to a press on the touch slider. A small bar on the right edge
of the window indicates the current position. The X position of the mouse
doesn't matter.

To "switch on" the device, place the mouse roughly in the middle and
press the left button. After a brief pause the text "ANELOK" will appear.
Now release the mouse button. A trinary login screen will appear.

To log in, draw a "V" by clicking briefly on the top, the middle, the
bottom, the middle, and the top again. The screen should now look like
this:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/sim-login.png

Now click on the bottom. Hold until the "enter" symbol highlights, then
release the mouse button. You now get an ugly list of accounts.

That's all the demo does so far. You can return to the beginning with the
(Continue reading)

Werner Almesberger | 18 Aug 09:50 2014
Picon

Anelok: board coming along

The new prototype is coming along nicely. I've now placed most of
the components. Besides rfkill acting as system-kill, the design
seems to be free from embarrassing mistakes so far.

Top view, without OLED:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-top-0818.jpg

Top view, with OLED:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-oled-0818.jpg

Bottom view:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-bot-0818.jpg

Cheat mode alert: the memory card holder isn't soldered. There are
a number of traces that pass underneath it and I'm a bit concerned
that it may short them. If that happens, fixing it would be somewhat
messy. So I'll keep that experiment for later.

The ugly mess of colored wires should of course disappear.

Side view:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-side-0818.jpg

Note that the two boards (main and battery) will not be at the same
height, so there won't be the sort of huge empty space this picture
suggests. 

You may wonder why it's taking me so long to put together the board
this time. After all, this is something that should take a day or
two, not weeks. The reason is that I'm also measuring the system's
(Continue reading)

Werner Almesberger | 13 Aug 20:53 2014
Picon

Anelok: a bit of eye-candy

I made an "artistic" drawing of the Analok device, for future addition
of hoverable descriptions:

http://anelok.com/

It shows the outside of the case with holes for lanyard and USB, windows
for OLED and LED, and I also marked the area of the capacitive slider.

On the inside, there are the two PCBs, the two MCUs, the battery, USB
connector, rfkill switch, OLED, LED, and memory card holder.

While this drawing isn't based on CAD data for making the case, most of
the geometry should be accurate. You can also view the model in 3D by
checking out the Anelok repo and then running the script that draws the
model with gnuplot:

git clone https://gitorious.org/anelok/anelok.git
cd anelok/web/dwg
./p3d

The model can be rotated by left-clicking in the image and dragging.

- Werner

Werner Almesberger | 10 Aug 14:22 2014
Picon

Statistics: July 2014

IRC traffic on #qi-hardware and #m-labs:

http://downloads.qi-hardware.com/people/werner/stat/irc-qihw-1407.png

The mailing lists:

http://downloads.qi-hardware.com/people/werner/stat/ml-qihw-1407.png

July saw an extended downtime of the Qi-Hardware server, which led to
the loss of some of the #qi-hardware logs and may also have affected
the mailing list, though the latter seems less likely. M-Labs runs on
other infrastructure and wasn't affected by the server problem.

On the mailing lists, M-Labs showed steady growth while Qi-Hardware
kept on dozing at the level of the previous month. On IRC, #m-labs
was a bit less busy than June and #qi-hardware kinda crashed.

Since Wolfgang brought the server back up and put it on new hardware,
things should return to normal this month, and the frequent short
interruptions we've seen for a long while should stop as well.
Thanks, Wolfgang !

- Werner

Werner Almesberger | 10 Aug 03:55 2014
Picon

Anelok: first capacitive sensor results

I merged the firmware trees for Anelok 2013, Anelok 2014, and Y-Box,
got USB device to work on Anelok 2014, and added full DFU support
(boot loader and reset-to-DFU in the application) for Anelok 2014.
The merge is messy and needs some more thinking and cleanup, but
it'll do for now.

USB didn't yield easily and I tought the FLL jitter may be just too
big for it to work, but in the end it seems to be fine. Still need
to have a closer look at that jitter, though - it does look pretty
wild:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/jitter-fll-xtal.png

This shows the 24 MHz bus block 2 us (i.e., 24 Full-Speed USB bit
times) after the trigger.

I also found another mystery: when DFU'ing, the received data is
passed with size 0. But the full 64 bytes are there. Strange. I
wonder if that's my punishment for having started to use
--gc-sections ...

With DFU, updating the firmware is very easy. I put this to good use
and added capacitive sensing. This is a first result, without any
tuning (using the parameters from the experiments on Y-Box) and with
idle plates floating:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/cap-20140809.png

The red and green curves show the two channels, the blue curve their
difference. The five patterns are, from left to right:
(Continue reading)

Werner Almesberger | 2 Aug 05:39 2014
Picon

my current measuring tools

My current measuring tools may be of interest also for other people.
Here is a brief description of the process.

Lab setup
---------

This image shows the lab setup:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/isys-lab.jpg

The lab power supply provides the voltage, with the current limited
to something circuit and multimeter can handle. The negative terminal
(ground) is connected directly to the test circuit (black arc).

The positive terminal is connected to the multimeter (small red arc).
From there, the current goes to the test circuit (large red arc). The
arrows indicate the direction in which the current flows.

The multimeter is set to operate in the lowest range in which the
current measured during the test fits. This is important because
measurements can become quite inaccurate if the meter is operating at
too high a range.

Data collection
---------------

The meter is connected to the PC and the PC continuously requests
measurements. The script that does this is here:

https://gitorious.org/anelok/anelok/source/meas/isys/m.py
(Continue reading)

Werner Almesberger | 31 Jul 01:55 2014
Picon

Anelok: temperature vs. current

Speaking of the effect of temperature: my test setup is as follows: the
Anelok board is supplied with 3.0 V into Vsys from a lab power supply.
The firmware running on the KL26 turns on the LED for 1 s, then turns it
off and enters LLS mode for 29 seconds. During this time I measure the
current that flows into the board.

Now, it's not a flat line but looks more like this:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-idle-20140729-2311-0005.png

This was from around last midnight. The interval begins with the first
measurements showing a current below 100 uA and ends with the last sample
before the MCU wakes up again and repeats the cycle. I trimmed the graph
a bit since there's inevitably some noise at the edges of the interval.

The black dots are the actual samples. The grey lines are some pretty
bezier curves gnuplot uses for smoothing the graph. The thick red line is
a function of the type f(x) = A+B/x^C where gnuplot determined values of
A, B, and C suitable for the data set.

Now, that looks all very nice, doesn't it ? Well, I did a bit more
hacking and then took a nap. When I got back to the lab at 8 am, I made
another set of runs. This time, I got this:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-idle-20140730-0801-0814.png

Did the elves sneak into my lab and optimized power consumption while I
was asleep ? By almost 1.6%, no less ? No, it's just that my lab had
cooled down and current dropped accordingly.

(Continue reading)

Werner Almesberger | 30 Jul 16:53 2014
Picon

Anelok: MCU idle current down to 2.0-2.1 uA

Found the culprit: it was the USB voltage regulator that burned 500 uA
while idling. Turning it off brought current in LSS (low-leakage stop)
mode down to about 2.0-2.1 uA.

Before finding the high leakage of the voltage regulator, I had suspected
and removed the boost converter. So I'll have to put that one back later.
The system consisted basically just of the KL26 for these tests - the
CC2543 is not connected to power, all GPIOs are disabled (so the CC2543
does't get powered by leak currents either), and most of the other
components are still not placed.

LLS is the "nicest" low-power mode: the core sleeps, the 32.767 kHz
oscillator is running, capacitative sensing should still be possible (the
Touch Sense Input module can run autonomously, but I still have to get to
this) and the chip wakes up either from the low-power timer (LPTMR) or
from a low-leakage wakeup (LLW) interrupt.

In LLS, the core should draw some 1.7 uA at 25 C. The crystal oscillator
should add 490 nA, so 1.7 + 0.49 = 2.19 uA while measurements yield 2.0
to 2.1 uA. My office is a bit cooler than 25 C most of the time (it's
still winter here), which may explain the difference.

- Werner

Werner Almesberger | 28 Jul 08:15 2014
Picon

Anelok: 2014 edition, first results

I started building the next version of the Anelok board. While my
approach with the first board was to put everything together as
quickly as possible and then see what happens, I'm doing things more
incrementally this time, measuring the system's performance as I go.

This is a view of the partially populated top of the board:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-top-0728.jpg

The two MCUs are already there but only the KL26 is currently powered.

I had some fun with its clock circuit, which is now based on a 32.768
kHz crystal. It turns out that 1) the crystal oscillator runs a bit
faster than theory would suggest - not sure if this is "normal" or due
to some mistake I made, and 2) that the FLL (Frequency-Locked Loop)
that generates the (up to) 48 MHz system clock systematically runs 558
ppm slow.

For a Full-Speed USB host, the tolerance is only +/- 500 ppm. But by
deliberately detuning the crystal oscillator and making it run even
faster, I can reduce the error to 330 ppm - good enough.

This means that any RTC based on the 32.768 kHz clock will have to be
corrected by software, but besides this it seems that this clock setup
will work.

A look at the bottom side:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-bot-0728.jpg

(Continue reading)

Delbert Franz | 14 Jul 19:37 2014
Picon

Getting a plot to work on Octave using the latest image from the website.

I am testing Octave with a simple plot.  When I run
the test, I get aresponse that says:

Requested device xwin not available

followed by a menu of options.  The only ones that
seem to work are those for "ps" and 'psc".  However, the 
Nanonote has no Postscript viewer that I can find.

I'm using the latest image from the website.  

Octave also claims that: Use PLplot: on

Is there something I can do to get a plot out of Octave
on the Nanonote or is there a way to view a Postscript file. 
Nupdf gets locked with a never ending display that 
says: "Loading...".

Thanks for any pointers on this.

                     Delbert Franz

Werner Almesberger | 12 Jul 11:42 2014
Picon

Anelok: next board version is stirring

I haven't made much noise about Anelok lately, but that doesn't mean
that things aren't moving.

I had a good long look at the design for the next board revision - and
promptly discovered two nasty little flaws in the battery / USB
switching circuit, which would probably not have worked very well, if
at all.

For the following explanation, you may want to look at the old (buggy)
schematics:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-20140603.pdf

The idea is as follows: when USB is connected, we have 5 V on USB_VBUS,
which then drives the p-FET Q1 that cuts off the battery. When USB is
disconnected, the resistor R10 pulls the p-FET's gate to ground and
battery current can flow.

So far, so good. Now there are two problems: the first one is that FETs
Q1 and Q2 can leak up to a few uA through the gate. With a pull-down of
1 MOhm, that would already raise the gate voltage by a volt or two. But
that's the smaller of the two issues.

The worse one is that current can flow out of the input of the MCU's
voltage regulator (VREGIN). That's nothing uncommon since regulators
are often designed to work mainly in one direction and not worry about
the opposite direction. I have known that VREGIN behaves like that for
a while, which is why there is diode D1.

However, I didn't realize that this would also upset my little battery
(Continue reading)


Gmane