• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 51 subscribers
  • Views 2892 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2541 as dual mode BLE/Bluetooth 2.1 + EDR?

Greenja
Guru 22270 points
Other Parts Discussed in Thread: CC2541, CC2540, CC2564

Since the CC2541 supports proprietary as well as BLE and the radio uses GFSK modulation, could a Bluetooth EDR stack be ported to this chip?

The proprietary and BLE modes are switchable on the fly by turning off the radio and setting the LLE_MODE_SEL bit.  There appears to be enough configuration options in the modulation format for this to work.  I don't know enough about the packet types, but I would think that the FIFO Tx and Rx could be set up to match the HW packets for EDR.

Such asACL: DM1, DM3, DM5, DH1, DH3, DH5, 2- DH1, 2-DH3, 2-DH5, 3-DH1, 3-DH3, 3-DH5–  SCO: HV1, HV3 and DV–  eSCO: EV3, EV4, EV5, 2-EV3, 2-EV5, 3-EV3, 3-EV5 

Has anyone done this, or is it possible?
  • 0
    TI__Genius 10955 points

    This is not possible. See this thread (the limitations for CC2540 apply to CC2541 as well): http://e2e.ti.com/support/low_power_rf/f/538/t/151057.aspx

  • 0 in reply to hec
    Guru 22270 points

    Hello hec,

    I looked at the post, but many of the reasons do not apply to the CC2541.

    The preamble and synch are programmable for 1-16 bits. 

    The only limitation that seems valid is the memory and I would think you could offload some of that, or even build a lightweight Bluetooth stack similar to the light weight Ethernet stacks. Not all the functionality of EDR are required, nor the high speed data rate.  I'm thinking that it  doesn't need any greater throughput than the BLE, it just has to able to connect to EDR and send some bytes of data.

    Also, with complete access to timer 2, at the very least you could make a matching packet that conformed to any header configuration.

  • 0 in reply to Greenja
    TI__Genius 10955 points

    greenja said:
    The preamble and synch are programmable for 1-16 bits. 

    No, the preamble is programmable from 1-16 bytes (8-128 bits), and the sync word from 16-32 bits.

    greenja said:
    The only limitation that seems valid is the memory and I would think you could offload some of that, or even build a lightweight Bluetooth stack similar to the light weight Ethernet stacks. Not all the functionality of EDR are required, nor the high speed data rate.  I'm thinking that it  doesn't need any greater throughput than the BLE, it just has to able to connect to EDR and send some bytes of data.

    EDR (enhanced data rate) is out of the question immediately, as CC2541 does not support pi/4-DQPSK. BR (basic rate) could seem possible at first glance, but isn't. One of the reasons is the preamble, as mentioned in the other thread. Another reason is the the RF parameters do not comply to the Bluetooth spec, for instance the interference performance (Vol. 2, Part A, Section 4.1.2 of the Bluetooth spec - compare to CC2541 data sheet). And if you look at the packet formats you need to support, you will find that the CC2541 is not capable of decoding lots of them, when it comes to finding the length, processing the longest possible packets, etc. Even if you offload the more complex tasks to an external microcontroller, you will see as you read though Part B of the Bluetooth spec that you find one thing after another that you can't  support with CC2541. Legacy Bluetooth is unfortunately quite complex, even with minimum functionality, which is one of the reasons that Bluetooth LE was created.

    If you want to do Bluetooth BR/EDR, you have to use a device that is made for the purpose, such as TI's CC256x products. I would strongly advice you not to waste your time on trying to implement Bluetooth BR/EDR on an integrated radio solution that is not already certified for it.

  • 0 in reply to hec
    Guru 22270 points

    Hello hec,

    Thanks for the clarification.  The problem with the CC256x solution is the price.  It is nearly 4 times more!  It would be more economical to have two CC2541 with one running BLE and the other BR.

    Also, I've wasted my time on many things that people have said couldn't be done.  Encoding/decoding packets should be possible with Timer2.  The interference issue will require some investigating.  At the very least, an exercise (in futility) like this will help in the better understanding of both protocols.

  • 0 in reply to hec
    Expert 1940 points

    hec,

    Thank you very much for your detailed and specific response on this matter.

    We are also using a CC2541 and recently discovered that we need to implement BR/EDR instead of BLE (mainly to be compatible with most of the Android phones currently on the market, which seem largely limited to BR/EDR).

    Can you suggest an alternate chip that is as close as possible to the CC2541 in form factor and function that will run the BR/EDR stack?

    Our main concern is PCB size. We were using the CC2541 mainly because it is small and we could use the integrated processor for our application specific functions, which are mainly to read data over I2C from an external device.

    Any help or pointers would be greatly appreciated.

    --Randy

  • 0 in reply to Randy Yates
    Guru 22270 points

    Now what a difference a mere 8 months can make!  My argument back then was futile to say the least.  Hec handled my ignorance quite well!

    Since then, I have learned more about the CC254x family and I'm still learning.  Also, the CC2564 dual mode Bluetooth/BLE controller was released at a price point that makes it affordable.

    Coupling the CC2564 with a MSP430 or Tiva running the BT Stack is a solution for interfacing with BR/EDR and BLE devices.