This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zigbee Coordinator and Bluetooth Central co-existence

I'm looking for the best option if I need ZB Coordinator role, and BLE central on my custom board. It is still in evaluation phase.

The ZB Coordinator should be able to handle max 50 direct children and max 200 devices within the whole network. It is the preferred functionality.

The BLE Central should be working parallel with the ZBC, with constant RX and occasional TX:

  • constant RX because it should be able capture advertising packets from nearby BT devices
  • occasionally (once/twice per hour) it will send L2CAP_ECHO_REQ to specific device(s) and receive L2CAP_ECHO_RSP. (It needs to be able to handle these kind of functionality!)
  • occasionally (random) it will communicate with BLE peripherials (reading/writing some characteristics): during this time once BLE is connected it shall be the preferred, but ZB network must not collapse!

I can use two fully separated SoCs with separated antennas. That would be the "brute-force" way. It might work as board design lets me keep good distance from those 2 antennas (at least lambda).

I know there are SoftDevices which provides BLE Central functionality, but can the Device act as a ZBC in parallel?

What do you recommend, if I prefer stability (vs cost/size-cutting)?

Thank you

  • Hi,

    We offer multiprotocol support for Zigbee and BLE in our nRF6 SDK for Thread and Zigbee v4.1.0. It is possible to implement BLE central role using dynamic multiprotocol support, but because this method requires concurrent radio access (each radio protocol requests a timeslot prior to any radio operation) you will need to set the scanning interval and scanning period as small as possible for the BLE central to ensure that Zigbee traffic is not blocked.

    Since BLE scanning perform by central devices requires a lot of time to process BLE traffic and thus blocks 802.15.4 traffic, it is only recommended to implement scanning/central devices together with the Sleepy End Device role for Zigbee applications as a general rule.

    The problematic part of BLE central is BLE scanning. If BLE is during scanning process it will disrupt ZB coordinator connectivity. If you want to use BLE central without scanning (or minimize scanning to device initialization before ZB is enabled) then the BLE central/ZB coordinator setup could work.

    I don't recommend having different radio SoCs in the same PCB because of interference. When one of them sends data it will block the other one from receiving data.

    You can read more about Dynamic multiprocotol support in the infocenter pages:  https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/ble_154_multiprotocol.html?cp=7_3_4_0_1#ble_154_multiprotocol_dynamic

    The BLE Thingy and Zigbee Color light bulb example demonstrate an example of dynamic multiprotocol using a BLE central/ZED  device: https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/zigbee_multi_dynamic_color_light_sed_thingy_master.html

    Best regards,

    Marjeris

  • Hi,

    Thank you very much.

    I've seen this links, but one thing I don't get:

    With multiprotocol SoCs they need one antenna that's cool. But they have only a single radio unit?

    I.e.: is it possible that when the antenna is used for RX, both BLE and ZB can receive datas from different channels?

    Unfortunately these two requirements are mandatory:

    -BLE beacon scanning and

    -ZB Coordinator functionality

    I don't recommend having different radio SoCs in the same PCB because of interference. When one of them sends data it will block the other one from receiving data.

    I understand, but as I know both BLE and ZB have multiple channels to choose from. Even if one stack is transmitting, the other stack can immediately jump to another channel and then there will be no interference, or am I wrong here? 

    If you want to use BLE central without scanning (or minimize scanning to device initialization before ZB is enabled)

    That's problematic, I think if I minimize BLE scans, I increase the chance that there can be beacons I will never receive.

    To conclude, you say that BLE central with beacon scanning and Zigbee coordinator can not be implemented on one board efficiently?

    Thank you!

  • danergo said:
    With multiprotocol SoCs they need one antenna that's cool. But they have only a single radio unit?

     Yes, the radio is share by assigning a timeslot for each protocol. The radio peripheral will do a short reinitialization in-between the protocl switching, so it can for example change frequency, modulation, etc, needed for each protocol.

    danergo said:
    I.e.: is it possible that when the antenna is used for RX, both BLE and ZB can receive datas from different channels?

     The radio peripheral will switch the channel and modulation each time it switches between BLE and Zigbee, so yes you can receive data from different channels.


    danergo said:
    I understand, but as I know both BLE and ZB have multiple channels to choose from. Even if one stack is transmitting, the other stack can immediately jump to another channel and then there will be no interference, or am I wrong here? 

     I may have oversimplified my ealier explanation  There will still be co-channel interference and if you want to send and receive at the same time you will need a very strong RX signal, take a closer look at the RX selectivity numbers in the PS here.

    If the ouput power is +4dBm, a typical loss (isolation) value between the antennas of ~ -10, and C/I1M,±6MHz = -50 dB adjacent interference you receiving signal would need to be >+4 - 10 -~50 = -64dBm (best case) in order to be received.

    The strength of the RX signal will depend on how close your devices are from each other. A -50dBm signal is a very close signal, while a realistic value will be -80dBm and lower...

    Best regards,

    Marjeris

  • Thank you, this is very nice information.

    One more thing I'm missing: do you have parts which supports both BLE and Classical Bluetooth?

    Because I believe what I asked in my original question:

    "send L2CAP_ECHO_REQ to specific device(s) and receive L2CAP_ECHO_RSP." it needs Bluetooth Classic functionality.

  • Hi,

    Sorry for the late reply. No, we don't have parts that support Classical Bluetooth. I am not sure about if it's possible to send L2CAP_ECHO_REQ with a BLE device, but L2CAP layer is still present in BLE, see https://devzone.nordicsemi.com/f/nordic-q-a/10786/l2cap-oriented-connection

    Best regards,

    Marjeris

Related