anelok: revisiting Bluetooth, summing it up
Ron K. Jeffries
rjeffries at gmail.com
Sat Nov 23 10:54:59 EST 2013
If [when?] you solve the bluetooth on Anelok challenge, a major benefit
will be the added utility and ease of use with smartphones.
Semi-unrelated: where do you stand on Anelok's MCU pin utilization? Are
there any unused i/o pins?
Ron K. Jeffries
On Sat, Nov 23, 2013 at 1:28 AM, Werner Almesberger
<werner at almesberger.net>wrote:
> 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
> 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:
> After accepting the utter futility of my resistance and adding a
> crystal to atben, I got this:
> 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,
> 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"
> "(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
> 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
> Qi Hardware Discussion List
> Mail to list (members only): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discussion