anelok: revisiting Bluetooth, tentative roadmap 1/2
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
- 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
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
I already discussed clocking options at length in the last post. For
the random number generator, we basically have the following
- 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
- 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)
More information about the discussion