anelok: revisiting Bluetooth, summing it up

Werner Almesberger werner at almesberger.net
Sat Nov 23 04:28:47 EST 2013


In Anelok the radio chip does more than just talk to the aether.
I already mentioned the clock sharing. That is optional (we could
just give the MCU its own crystal, at the price of one of the
somewhat scarce interrupt-capable GPIOs and increased board
crowding) but desirable.

There is also the option of reversing the roles and sending a clock
from the MCU to the radio chip. Once upon a long ago I tried to do
that with atben, hoping to need no new crystal at all. The result
was a disastrously dirty spectrum since some minor impurities in the
clock signal caused the RF chip to radiate also outside the intended
channel.

That struggle has been recorded for posteriority. The results of
various attempts of eliminating potential sources of contamination
and of "smoothing" the clock signal can be seen here:

http://downloads.qi-hardware.com/people/werner/wpan/rework-20110112/
http://downloads.qi-hardware.com/people/werner/wpan/rework-20110113/

After accepting the utter futility of my resistance and adding a
crystal to atben, I got this:

http://downloads.qi-hardware.com/people/werner/wpan/redesign-xtal/

In the case of Anelok we may be able to output the bus clock which
is 48/n MHz with 2 <= n <= 8. That would cost us another GPIO. The
bus clock is currently at its maximum, 24 MHz, but it probably
wouldn't hurt to run it a bit slower. Given the atben experience, I
wouldn't have a lot of hope for this yielding an acceptable result,
though.


More importantly, the AT86RF232 also has a random number generator.
We need a source of high-quality randomness for the cryptography.
Of the BTLE candidates I looked at, only the CC2543 has a true
random number generator (based on receiving RF noise, which may make
it susceptible to tampering.)

Another thing to consider are export restrictions. Some of the
chips have built-in AES support, but - according to Digi-Key - it
seems that Uncle Sam thinks they're all harmless enough to let us
play with them. (I couldn't check the CYRF8935, though.)


Summary so far:

Chip		Package Clock   RNG	Export  Unit @ 1000	Comments
---------------	-------	-------	----	-------	-----------	-------
A7105		20-QFN	yes     no	-	1.48
ADF7242		32-QFN	no      no	ok	3.05	also 802.15.4
AT86RF231	32-QFN	yes     yes	ok	2.75	802.15.4 only
AT86RF232	32-QFN	(yes)	yes	ok	2.03-2.30  idem      
CC2540F128	40-QFN  no?	no	ok	2.81	BTLE, 2 x xtal, USB
CC2543		32-QFN  no	yes	ok	2.52    
CYRF8935	24-QFN  (no)	no	?	1.22	unbalanced output
TRC104		24-QFN  no?	no	ok	1.80	"naked" bitstream

I've also included the AT86RF23x chips for comparison purposes.
The AT86RF232 has two prices at Digi-Key with the "tray" version
being a little cheaper (and "Non-Stock") than the "cut tape"
version.

"(yes)" means that the chip doesn't officially support a suitable
clock output but that the ones I have do implement the
corresponding setting.

"(no)" means that the CYRF8935 has a clock output pad ... but only
on the bare die, not bonded in the package. Duh.

"no?" means that I haven't found anything but didn't spend enough
time with the data sheet to be sure that there wouldn't be some
clock output option.


Of these chips, I would drop the CC2540F128 because it's not open,
and the TRC104 because having to work at the bit level is a bit too
hardcore even for my taste. This leaves four candidates, each with a
unique strength:

- A7105: small yet has clock output
- ADF7242: most flexible RF which includes 802.15.4
- CC2543: popular and has a true random number generator
- CYRF8935: small and has the simplest RF circuit (I hate baluns.
  The integrated ones are expensive and a latent sourcing risk. The
  discrete ones - if you can get the design information - are a
  component zoo.)

A lot of fun can be had with a flexible RF interface, as can be seen
here:

http://www.remote-exploit.org/articles/keykeriki_v2_0__8211_2_4ghz/index.html

They use an A7125 (and others). The slides of the CanSecWest 2010
talk are worth reading.

Going back to the possibility of using the MCU clock (instead of a
local crystal) for a moment, the clocking options of the four
survivors are:

- A7105: seems to be pretty flexible and all the supported
  frequencies (6, 8, 12, 16, and 24 MHz) can be generated by our
  KL25. The data sheet explicitly mentions the possibility of using
  an external clock generator. (Note: the AT86RF23x manuals do,
  too. And we know how that went.)

- ADF7242: requires 26 MHz (which is a frequency we can't provide)
  and the data sheet doesn't even mention the possibility of using
  a digital clock.

- C2543: requires 32 MHz (which we can't provide either) and no
  mention of not using a crystal.

- CYRF8935: uses 12 MHz (which we can provide) but the data sheet
  doesn't mention using anything but a crystal and doesn't specify
  the crystal input voltage.

Next: tentative roadmap. (Would that be a "toadmap" ?)

- Werner



More information about the discussion mailing list


interactive