anelok: revisiting Bluetooth, tentative roadmap 1/2

Werner Almesberger werner at almesberger.net
Sat Nov 23 10:25:18 EST 2013


Sorry, this one got a bit too long. So I split it into motivation
and objectives, and then a more hands-on part.

First of all the main premises for looking at BT/BTLE at all: I
assume that, if Anelok supports BT/BTLE radio,

- there will (*) be a keyboard/HID protocol it can implement, that
- is sufficiently secure for wireless password entry,
- does not require special drivers on the PC/tablet/smartphone (like
  USB HID today), and
- is likely to become a "standard" choice on such devices (like USB
  and HID today.)

(*) Could be "a suitable protocol already exists and is in
    widespread use", but also "a suitable protocol has been
    specified and is expected to be widely adopted", or "the usual
    suspects are expected to come up with a protocol that will then
    be widely adopted", etc.

Question to the audience: are these premises correct ?


Some key findings of this research:

- BT technology in general has become easier to source, and while

- the openness of "one stop shopping" solutions (modules, SoCs
  with a full vendor stack, etc.) is still poor,

- there is a number of general-purpose radio chips that could be
  used as the basis for a DIY stack.

- while BT is still the overengineered mess it always was, BTLE
  seems to be much nicer and is rapidly gaining market acceptance.

- BTLE is still evolving and a "standard" solution may not be
  suitable for our needs just yet (e.g., due to poor security).

- while many existing devices have BT support built into them,
  only a few have (also) BTLE. Since the smartappendage (watch,
  pulse sensor, etc.) ecosystem strongly favours BTLE, we can
  expect it to become as much a standard feature as "legacy" BT is
  now.

- BT 1.2 and BTLE radio hardware is nearly identical, so one may
  be able to support both. (Don't know how much of a nightmare
  writing the stacks would be, though.)

Even in the absence of a usable standard let alone implementation,
we could always use a proprietary protocol at the beginning and
switch to proper BTLE later. This is not worse that what we'd do
with a 802.15.4 radio anyway. (I.e., there is not even a
"HID/keyboard" in 802.15.4 to begin with.) This would have the risk
of finding roadblocks long after the hardware in question is
finalized.

Question to the audience: am I making sense this far ?


So I would see value in designing Anelok with BTLE-capable radio
instead of 802.15.4. Implications:

- the RF side of Anelok goes back to the drawing board,

- we can't reuse ATUSB (unless the radio chip also happens to be
  802.15.4-capable) and there would be no reason for making an
  updated ATUSB variant (which is well - the existing ATUSB seems
  to be good enough at doing what it does),

- we would need a new BTLE radio-compatible dongle, especially if
  initially operating with a proprietary protocol.


However, there is more to it. Since the radio of Anelok is also
responsible for providing a clock and the all-important random
number generator, any replacement has to address these issues as
well.

I already discussed clocking options at length in the last post. For
the random number generator, we basically have the following
choices:

- use a chip with a built-in RNG, i.e., the CC2543 (and hope it's
  good enough. Note that also the RNG of the AT86RF23x hasn't been
  properly evaluated yet.),

- use an MCU with a built-in RNG. The Freescale Kinetis L series
  doesn't have this but the ST STM32F2 and above do. However, the
  STM32F2 are larger chips that wouldn't fit unless we generously
  enlarge the PCB or switch the design to BGA and a multi-layer PCB.
  They're also more expensive and need an external regulator for
  operating at USB voltage (5 V).

- use an external dedicated RNG device. What little I've seen so far
  isn't very convincing and is likely to drive up the BOM cost
  considerably.

- figure out a creative way for using the available sources of
  natural entropy to make our own RNG, similar to how Linux does
  /dev/random. I'd love that. Can we do it ?


If we need to have a dedicated RNG in the transceiver then the TI
CC2543 is the only choice. On the MCU side (KL25) this would mean
that the MCU has to get its own crystal.

If we can do without a dedicated RNG in the transceiver I'd favour
the Amiccom A7105 because of its variety of clocking options. It
would be worthwhile to try clocking it from the MCU because this
would allow operating the MCU on USB without activating the radio
at all, permitting a "hard" RF kill.

The CYRF8935 would be a close second with its simple RF circuit.

If an MCU-based clock leads to an RF disaster the crystal would go
to the radio and the MCU would have to turn it on when it needs a
stable clock, much like things are at present.

Next: tentative roadmap part 2/2 (implementation)

- Werner



More information about the discussion mailing list


interactive