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.

Bluetooth dual-mode and central/peripheral limitations?

Other Parts Discussed in Thread: CC2540, CC2564

Hey all -

I'm having trouble understanding where the limitations are for a device having the following four pieces of functionality:

  1. Bluetooth Classic 
  2. Bluetooth Low Energy
  3. Peripheral Role
  4. Central Role

My current understanding on parts (1) and (2) is that the transceiver itself is what determines if the device is capable of being a dual-mode device, but from what I'm reading it doesn't seem  to be a PHY layer limitation. Isn't Bluetooth Classic (not EDR) a 2.4GHz GFSK modulation scheme the same as Bluetooth Low Energy? I understand that EDR uses a different modulation scheme and therefore the transceiver hardware obviously has to be different to support it, but I'm wondering about classic Bluetooth. How is it the cc2564 can be dual-mode but the cc2540's RF portion cannot be?

On issues (3) and (4) it seems to be based on the limitations of the bluetooth stack. While the cc2540 (a single mode BLE SoC) can act as both central and peripheral, the nRF51822 (also a single mode BLE SoC but using the nordic stack) seems to only be capable of performing the peripheral role. So is that strictly a software/firmware limitation of the stack provided by Nordic Semiconductor or is there something in the hardware of the cc2540 that allows it to perform both roles?

Thanks in advance for any information.

  • Hi ,

    CC2564 is much more than a transceiver, it includes the BT MAC (which is much more complicated than the BLE). The limitation is not on the RF domain but on the SW/HW MAC portion.

    The limitation of nRF51822 is probably SW/FW related (it can also be memory/resource related).

     

    Regards,

    Dotan

  • HI,

    The Nordic part uses a 'soft device'. This is hex code implementing the stack and api functions. Your app talks to the separately installed soft device using Cortex SVC interrupts. Using this mechanism the soft device is totally isolated from the app. Up to now the soft device (S110) was device only functions. There is now a beta soft device (S120) which implements controller functions - however it is only beta and as such there is no real documentation support for it yet. I am not sure if the S120 will also allow device functions - if so I suspect these will be limited - making the TI parts the more useful part if you need device and controller type functions.

    Hope this helps

    Regards  SimonT