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

Werner Almesberger | 31 May 02:17 2014

Anelok security model

I drew a little diagram of the security model I plan to use in Anelok:

The "trusted core" is the MCU, in our case a Freescale Kinetis KL26.
It has protection against altering the Flash (including a bulk erase)
and against reading any memories or running the chip under a debugger.

It communicates with the various entities in the system. The MCU and
the RF SoC are also sealed against physical tampering in some way,
e.g., with the transparent silicone plus paint seal we discussed

The MCU contains the (trusted) code and the master keys. The master
keys are weakly encrypted with the user's PIN and there's also a
retry limit against brute-force attacks.

The master keys unlock the encryption of objects in the password
database on the memory card. The memory card also contains trusted
code updates and maybe some large data (fonts, etc.), which is
signed. The corresponding credentials (not shown) are also stored in
the MCU.

The various communication channels - Bluetooth LE or USB - are all
usually be encrypted but there may also be some insecure modes. In
the case of Bluetooth, the encrypted channel would terminate in the
MCU and not, as is commonly done, in the insecure RF SoC.

The code in the RF SoC is weakly trusted, so it would still be signed
on the memory card, but a reasonably determined attacker could alter
(Continue reading)

marmorine | 27 May 23:29 2014

end of life, and I'm just beginning to live?

I started slow with the Nanonote, it was a bit of a plunge for me at
the beginning, but it just kept getting better and better, learned a
lot, did some programming, and even bought a second one.

So to me things are just getting interesting, but I am also aware that
the project itself has been idle for some time now, and so I was a bit
worried about that, especially about the website.

What is the status there, is there any danger that the website will be
taken down and/or retired in the near future?

Werner Almesberger | 26 May 18:17 2014

Anelok: still need to take care of business

I wrote:
> I know very little of these business things but enough to know that
> half-knowledge is worse than ignorance, so someone else has to help
> there.

No reactions so far :-(

Without a business structure, the project can't organize funding, and
without funding, all I'll ever be able to make (eventually) may be a
couple of units for my own use, and that'll be it.

Regarding funding, I was thinking of trying a form that combines
kickstarter-style preorders with investment. The traditional preorder
format works well for mature designs but to get there, you either
have to make promises you don't know you can keep, or find some other

I'd rather not take the dubious promises approach, which leaves:

a) financing all the R&D myself. I was hoping I could do that, but I
   got stuck in the "daytime" project that I had hoped would feed me
   while working on Anelok. So that won't provide the reserves needed
   to do the next step.

b) find a vulture capitalist / sugar daddy / ... (or a small group of
   them) to invest in the R&D (and possibly beyond). Alas, I don't
   know anyone well enough who might do such a thing.

c) idem, but the investor(s) be a company or a group of companies.
   Again there's the problem that I should spend less time in the
(Continue reading)