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 <[email protected]>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): [email protected] > Subscribe or Unsubscribe: > http://lists.en.qi-hardware.com/mailman/listinfo/discussion >
_______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
