anelok: revisiting Bluetooth, chips (TI)

Werner Almesberger werner at
Fri Nov 22 18:36:02 EST 2013

When looking around, one can see the following tendencies for this
class of RF chips:

- they often come in families with similar properties,

- characteristics that tend to vary are

  a) the modulation, which can be FSK or GFSK, sometimes also some
     simpler modulation (e.g., OOK which is "AM"), rarely a more
     sophisticated modulation.

  b) the data rate, which sometimes includes 1 Mbps, sometimes not.

- some are "dumb" while others have some CPU core one can program.
  For our purpose, the dumber the better, not only because it tends
  to make the chip cheaper and smaller but also those cores tend to
  be some nasty architecture (8051 or worse) that would require yet
  another toolchain, etc.

- all the modern ones seem to have a low number of external
  components, similar power consumption, and operate in the voltage
  range Anelok is designed for (2.0-3.3 V).

- the manufacturers usually don't mention any potential BT
  capability. Not sure why. Could be a trademark issue, could be
  them trying to steer customers to more expensive chips.

It's important to keep these parameters in mind when researching a
chip family because there is often not just a linear progression
from weak to stronger but the whole feature set can get reshuffled.

For example, TI list the CC2500 [1] as the successor of the CC2400.
While it looks nice at first glance (20-QFN 4x4 mm, USD 1.53 @
1000, in the prime of its product life), there is the nasty
surprise that its maximum data rate is only 500 kbps - too slow for

Looking for other chips from TI that may be suitable, the next one
that comes up is the CC2540. That one is even explicitly advertized
for "Bluetooth(R) low energy". Obviously, this has to be a great

Well ... some things about it are not so sexy. For example, it
comes in a 40-QFN package, which is still a bit on the large side.
Then it has an 8051 core with 128 kB Flash. But if you can't get
enough of 8051 joy, you can also have it with 256 kB Flash. All that
computing power does of course come at a price: the CC2540F128 [2]
costs USD 2.81 @ 1000 units. That's still fairly reasonable for
what it does. Oh, and it has USB device, too.

However, when digging a little deeper, I found this in the User's
Guide [3]:

"On the CC2540/41 radio operation is controlled by the Bluetooth low 
 energy stack. The application is not allowed to access the radio 
 directly. The application interacts with the radio by sending API
 commands to the stack."

Okay, so let's not do this. On #ubertooth, they mentioned that they
were considering the CC2540 as a possible CC2400 successor but they
don't like it so much either after discovering this :)

The User's Guide does mention the CC2541 (without USB) which has a
"raw" mode that could be suitable for our needs. However, that seems
to be basically identical to what the CC2543 [4] has to offer on the
radio side, and the CC2543 ...

- comes in a 32-QFN 5x5 mm package (just as small as the AT86RF23x),
- still has an 8051 but with only 32 kB of Flash and no USB,
- also supports MSK, a close cousin of O-QPSK of 802.15.4 fame, but
  unfortunately not close enough (*) to make the chip
  802.15.4-capable (**), and
- is a little cheaper at USD 2.52 @ 1000.

So it looks like a potential candidate. I also checked whether it is
under any export restrictions (it has a - useless for us - AES
engine) and it seems to be okay.

(*) MSK could communicate with O-QPSK, but 802.15.4 transmits each
    "symbol" (4 bits) as a "chip" of 32 bits, so the 250 kbps data
    stream "accelerates" to 2 Mbps before O-QPSK modulation.
    Unfortunately, the chip's fastest MSK rate is 500 kbps, so it's
    too slow for 802.15.4.

(**) Having a radio interface that does not only do BT/BTLE but also
     802.15.4 would offer a nice migration path from "proven"
     technology (AT86RF232) to the new BTLE. More about this later.

Conclusion so far: TI CC2541 and CC2543 both look like potential
candidates for implementing BTLE.

Next: Don't want no ...

- Werner


More information about the discussion mailing list