Werner Almesberger | 31 Jul 01:55 2014

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:


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:


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

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

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:


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:


(Continue reading)

Delbert Franz | 14 Jul 19:37 2014

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

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)


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)

Werner Almesberger | 11 Jul 08:10 2014

Statistics: May and June 2014

The statistics department is back, with the World Cup Special Double
Pack of statistics not only for May but for June as well:

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


The mailing lists:


As you've probably guessed, I'm quite busy these days and didn't even
have time to read much of what's been happening on the M-Labs side.

That's of course also in part because the M-Labs list had a very busy
month in June, only to be topped in the last year by the November to
January bulge.

Meanwhile, the Qi-Hardware list fell silent during June, with only
very few posts.

Both IRC channels continued their drop from the peaks earlier this
year but proved to be remarkably stable from May to June, to the
point that I had to look twice to be sure that I hadn't accidently
used the May data twice :)

- Werner

(Continue reading)

Delbert Franz | 10 Jul 16:55 2014
Is this list still alive?  Apparently this link 


and others like it are no longer alive.  I did manage to get 
copies of the software onto one of my computers but have not 
been able to get everything to work yet.  The compiled 
images are also no longer on line.  Fortunately, I 
downloaded the latest ones just a day or two before the 
qi-hardware.com site went down.  

Have not seen a post for a few days to this mailing list.  
If this does not appear, I assume it is down as well.  

It is just so sad that enough traction did not appear to 
make the Nanonote a success.  I use mine every day.  
But then I am not a "normal" user:-)  

                             Delbert Franz

Apelete Seketeli | 6 Jul 00:15 2014

Qi-kernel rebase: jz-3.15 branch released


Last release announce was for jz-3.12, this time around I'm pleased to
announce the availability of jz-3.15 for those following development
of the qi-kernel.

The jz-3.15 branch is a rebase of the Qi Hardware community
non-upstream patches onto Linux kernel 3.15.

Apart from jz-3.13 silently pushed out some months ago, things have
been pretty quiet since jz-3.12.

The following patches which are now upstream have been dropped since

Apelete Seketeli (4):
  mips: qi_lb60: update defconfig for the Ben NanoNote
  usb: musb: fix setting JZ4740 gadget periphal mode on reset
  usb: musb_gadget: use is_otg flag to set gadget peripheral mode on reset
  usb: musb: add support for JZ4740 usb device controller

Lars-Peter Clausen (4):
  Add defconfig for the Ben NanoNote
  pwm: jz4740: Pass device to clk_get
  drivers/rtc/rtc-jz4740.c: Use managed resources
  ASoC: jz4740: Use the generic dmaengine PCM driver

Paul Cercueil (1):
  MMC: JZ4740: Fix handling of read errors.

(Continue reading)

Werner Almesberger | 3 Jun 15:13 2014

Anelok: battery holder comparison

Here's the battery holder story I promised.

For those who just tuned in, this is what a MPD LP2032SM battery
holder looked like after just a small number of battery insertions:


Also the similar MPD BLP2032SM, which would have been a "plan B",
has the same problem and it's even worse there:


More details:

I mailed MPD about this problem two weeks ago but didn't get a response
so far. Well, there's more fish in the sea ...

I experimented quite a lot with CR2032 batteries during the last few
years and have a collection of holders. These two are somewhat similar:
MPD BA2032SM and Keystone 1060:


For comparison, here are all four:


(Continue reading)

Werner Almesberger | 2 Jun 04:30 2014

Anelok: oscillator choices

The original design had only one crystal, on the RF chip. The RF chip
would then generate a clock signal for the SoC. The Soc needs a
precise clock for two purposes:

- for USB, and
- for timekeeping.

Since it would be wasteful to run the RF chip all the time just to
provide the clock (*), the idea was to calibrate the low-power RC
oscillator in the KL26 with it, and then keep time based on that,
with occasional wakeup and recalibration.

(*) The AT86RF232 draws about 330 uA when idle. The CC2543 draws
    about 3.1 mA in the lowest power mode in which the 32 MHz crystal
    oscillator runs.

If we want to have a "hard" rfkill switch that shorts the RF SoC's
power supply to ground, the KL26 also has to be able to run without
the RF SoC. It therefore needs a local crystal.

The KL26 offers two choices: a high-frequency crystal that draws
between 200 uA and 4 mA just for the oscillator, depending on speed
and configuration, or a low-frequency crystal (32.768 kHz) that can
work with as little as 0.5 uA (25 uA in high gain mode).

0.5 uA is interesting. This is low enough that the crystal oscillator
could run continuously, providing very accurate timekeeping.

Since I have a few small 32.768 kHz crystals lying around, I tought
I'd give it a try in the next board version.
(Continue reading)

Werner Almesberger | 2 Jun 04:16 2014

Anelok: the journey towards V1

I'm working towards the V1 board which will, among smaller changes,
replace the wheel with a capacitive sensor and the AT86RF231 with the

I tried a few different component placements for this. An overview
drawing can be found here:

First, I tried the approach where the CC2543 helps the KL26 with its
GPIOs, so that a smaller package with fewer pins can be used with the
KL26. This is in the branch "puppet". The memory card would be
ejected into the battery compartment.

This is nice and compact, but routing the control signals from the RF
SoC promises to be difficult. I also had second thoughts about having
the two chips interact so tightly, especially since the CC2543 would
not only have to handle control outputs (power on, etc.), but also
some interrupt lines.

I then tried to see what would happen if I just adapted the version 0
design. I also gave the KL26 its own crystal (more about this in a
separate post).

A first try - branch "large" - looked somewhat promising but I ended
up with very long traces and a few problems with the pin assignment.

Next was a more radical attempt to put all major components on the
top layer, to avoid vias. This is in the "coplanar" branch. It looked
pretty good, with one problem: with components as tall as about 2-2.5
mm on the top, the FPC of the OLED would get bent quite a bit.
(Continue reading)