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
805-567-4670






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
> 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
>
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
> http://lists.en.qi-hardware.com/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20131123/889c2a3b/attachment-0001.htm>


More information about the discussion mailing list


interactive