Werner Almesberger | 23 Apr 12:04 2014

Anelok: design evolution overview

I made a little doogle about the some of the design aspects of Anelok,
things discarded, things being evaluated, and also some idea for a
possible future:


Most of it should be self-explaining. The little "post-it" boxes list
characteristics and benefits in black, disadvantages or issues in red.

There's one new item in that diagram: the Nordic nRF51822 BTLE chip.
Openly available documentation: [1]. What Google finds: [2, 3]
A quick comparison:

TI CC2543 (this is what's currently in the Y-Box):
  - does not officially support BTLE
  - should be able to do BTLE, with a bit of hacking
  - 8051 core
  - RF-based RNG
  - documentation openly available
  - small (32-QFN), USD 2.52  <at>  1000
TI CC2541:
  - officially supports BTLE
  - closed vendor stack uses secret knowledge to enable BTLE features
  - 8051 core
  - RF-based RNG
  - documentation openly available
  - large (48-QFN), USD 2.72  <at>  1000
Nordic nRF51822:
  - officially supports BTLE
  - hardware seems to be properly documented
(Continue reading)

Werner Almesberger | 22 Apr 01:29 2014

Y-Box: sending a constant wave

The long weekend's haul is that, apart from some infrastructure work, I
got Y-Box to send something on its RF interface. For now, it's just a
constant wave, not useful data, but it's nice to see that the RF side
appears to be in good shape as well.

Pictures or it didn't happen ? Alright, alright, here it is, even with
moving pictures:


By the way, I'm not sure what audio format works best with WebM. I
just used Vorbis. Does this work for the players that need WebM ?

Regarding future things to test, while I think I don't need to
implement full BTLE reception or transmission just now, there is one
detail that needs examining: the data sheet of the CC2543 is somewhat
vague on the RX-TX and TX-RX turn-around time. BTLE requires 150 us.

So I'll have to cook up some tests that let me measure these
turn-around times before I can be sure that the chip's RF circuit is
fast enough for BTLE.

- Werner

Werner Almesberger | 5 Apr 03:23 2014

Statistics: March 2014

March statistics have arrived:

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


The mailing lists:


The mailing lists had their most quiet month in the last half
year, with posts on "the usual suspects", migen fixes and NetBSD
on M-Labs, and Y-Box progress on Qi-Hardware. On the 31st, also
the Nanonote EOL discussion flared up again.

On IRC, #qi-hardware traffic dropped - as I predicted last month -
by about a third but was still rather busy.

And I need to correct the last results for #m-labs: that supposed
vow of silence I observed last month was me not updating the right
files. It has in fact maintained a fairly constant level of
activity for over half a year now. Usually much less than on
#qi-hardware, but more steady.

- Werner

fantomid | 4 Apr 09:36 2014

Re: Nanonote End of life

Hello everybody,

Regarding news around Ingenic MIPS SOC, you could check this link http://linuxgizmos.com/mips-based-newton-module-takes-on-intels-edison-in-wearables/
May give some ideas.

Guillaume GASNIER

Werner Almesberger | 1 Apr 00:55 2014

Y-Box: more DFU, and beyond

I wrote:
> This boot loader only handles the KL25/26 so far. For the CC2543,
> I'll have to add a function that flashes it via the debug interface


> and teach my DFU implementation to support alternative settings.

Done as well, even with names (which are a messy to implement,
given the way USB handles strings):

# dfu-util -l
Found DFU: [20b7:ae71] devnum=0, cfg=1, intf=0, alt=0, name="KL26"
Found DFU: [20b7:ae71] devnum=0, cfg=1, intf=0, alt=1, name="CC2543"

Now I can flash the firmware of both chips conveniently via DFU
and will need the test fixture (for SWD or the CC2xxx debug
protocol) only for boot loader changes (or for new prototypes.)

I also wrote a simple implementation of the communication between
the two chips (one-way for now), found a bug in my handshake
protocol (improvised around it), and can now control either LED
with a user-space utility over USB.

Next: make the protocol bi-directional and enable it to send more
than just one byte. And then it'll be time to actually put the
radio to use.

I'm not quite sure yet how far I want to go with the radio at the
(Continue reading)

lee jones | 31 Mar 19:43 2014

Nanonote End of life

Quite sad btw to hear about the nanonote's end of life btw. Really
quite a useful device for something so small! Though I guess now
really instead of looking to the past it is time to look to the
future. If there is to be any sort of nanonote successor - or even
something completely different what could that be? What device is it?
What does it look like?

I read through the individual posts in feburary ("Nanonote End of
life"). I think one thing that struck me and I apologise as I'm about
to go off topic is something that I went through a little while ago,
namely with trying to buy a new 'phone.

It's really hard (if not impossible) to find a open/free phone to use!
Can discount microsoft and apple straight away as they are totally
closed. Android is partly closed. The hardware in android's case more
than likely needs binary blobs as well.

That leaves a few others -- firefox os, ubuntu touch, Neo900 and
soforth. Though even these have their problems. Neo900 looks good but
I can't see it selling much with a price tag in the order of E500-700
(That's what about $600-800?). That then leaves firefox and ubuntu --
though who knows how open and free their hardware is? And if the
hardware is, the software might not be -- Firefox OS if you try to
root it you loose your warranty on your phone (
https://support.mozilla.org/en-US/questions/967076 ) . Plus firefox os
supports advertising (*yuk*) and "in-app" advertising (*double-yuk*).
Not sure about ubuntu touch though what if they do the same? Where
does it end? Spyware in ubuntu touch and Firefox OS because of ad$?

I apologise about that mini rant. But I guess what I'm trying to say
(Continue reading)

Werner Almesberger | 23 Mar 17:14 2014

Y-Box: DFU and boot loader (KL26)

Good news: DFU and boot loader finally work.

Here's a video to prove it:

Detailed timeline:

00:02 Y-Box in test fixture
00:06 Push Y-Box onto the contacts of the test fixture
00:08 I flash the boot loader via SWD from the Ben
00:10 First pass: writing the code to Flash
00:11 Second pass: verification
00:15 The Y-Box now contains the boot loader but no application
00:20 Connect USB
00:21 Red LED: waiting for enumeration
00:22 Both LEDs: enumerated, now waiting for DFU. This wait normally
      ends after 1-2 seconds but is "forever" if there is no
00:25 Run dfu-util on the PC to Flash an application
00:29 The boot loader now sees a valid application and starts it.
      In this example, the application simply flashes the green LED.
00:32 Let's do it again (but without flashing, since we already have
      an application in Flash)
00:35 Red LED: waiting for enumeration
00:36 Wait for DFU
00:38 Time out and start the application

This will be the standard way of flashing the firmware of the Y-Box.
A similar boot loader can also be made for Anelok. I don't plan to
have DFU on Anelok for regular use, but during development it's
(Continue reading)

Werner Almesberger | 13 Mar 19:21 2014

EOL strikes again

Digi-Key informed me that the Molex 0482580001 and 0482580002 went
End-of-Life (EOL), with a Last-Buy-Date (LBD) of 2014-09-01.

That's the nice mid-mounted USB A receptacle I use in the new Y-Box.
Alas, there's no direct substitute for it. The TE 1746311 would be
a similar-yet-not-identical emergency replacement, but then I'd
really have exhausted all choices. So let's not go there.

This means:

- have to go back to using a top-mounted USB receptacle, which makes
  the device considerably thicker (mid-mounted has about the height
  of the USB connector without much going above or below it while
  top-mounted has "claws" going through the PCB and deep under it,
  adding some 3-4 mm)

- can't design a new case just yet (but the new one will then just
  be a variant of the original one, since the vertical stacking now
  won't change)

- there'll be lots of room under the receptacle, so I can at least
  put a couple of the large test points there, maybe more.

Grrr. That's what I get for talking myself into using a part that
has no identical replacement from a different manufacturer.

General status: trying to get DFU to work. I can read the Flash but
the USB driver doesn't want to accept data for writing. I also
started defining the protocol between the two MCUs, now mainly the
handshake to ensure the master only starts an SPI transfer if the
(Continue reading)

Werner Almesberger | 1 Mar 20:00 2014

Statistics: February 2014

Statistics for this year's shortest month:

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


The mailing lists:


The mailing lists maintained roughly the traffic level of the
last few months, with M-Labs (former Milkymist) being more quiet
with mainly a bit of discussion about putting the MMU to good use.

The Qi-Hardware list flared up after Christoph Pulster, last
Nanonote distributor in the West, announced that he'll soon run
out of these amazing devices.

Meanwhile, on IRC, #qi-hardware put on the booster rockets while
#m-labs took a vow of silence. The discussion on #qi-hardware was
a bit unusual since it mainly centered on Joerg (DocScrutinizer)
and me encouraging Peter (whitequark) to try new ideas for making
his life dangerously interesting, and he - with the excuse of
trying to make PCBs - exploring all the kinds of chemicals he can
mail-order from the notoriously circumspect and safety-conscious
suppliers in Russia.

I don't really expect #qi-hardware to stay at that level of
intensity for very long, so my prognosis is that it'll drop to
something like half or a third of the present level before too
(Continue reading)

Werner Almesberger | 26 Feb 05:27 2014

Y-Box block diagram

Y-Box now has a block diagram, too:


Nothing really new there, but it may be a little easier to read
than the schematics and we can later turn it into a clickable
image map with links to data sheets and such.

- Werner

Werner Almesberger | 25 Feb 19:07 2014

Y-Box LED indications

Y-Box has several operational and error states that are worth
indicating. It has two LEDs, a red one attached to the CC2543
(RF) and a green one attached to the KL26 (USB), to do this.

How about the following scheme ?


The normal use sequence would be:

- unplugged: no lights

- plug into PC: red LED goes on

- after about 1 second USB enumeration finishes and the green LED
  goes on as well

- Y-Box waits 1-2 seconds for DFU (firmware updates). If it doesn't
  see any requests, it turns off both LEDs and starts RF dongle

- on RF activity, the red LED briefly flashes.

If the rfkill switch is set, i.e., if the Y-Box is used only to
connect Anelok to some USB device, the CC2543 is completely shut down
and the KL26 cannot communicate over USB (because it needs the CC2543
as clock source. Of course, even if it could talk on USB, it
wouldn't have much to say ...) In this case, the green LED would
stay on until rfkill is disabled (if ever).

(Continue reading)