Zigbee Coordinator and Bluetooth Central co-existence

[danergo]

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

[Marjeris Romero]

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

[Lipeng Yang]

I'm sorry to bother you so late. However, when I was learning the Example of BLE Thingy and Zigbee Color Light Bulb, I had a big confusion. Please help me, thank you.

In this case, you should use dynamic multiprocotol. But I don't see any code for this, that is, for the radio scheduler. Nor is the call to the function found in void main(), such as scheduler_init().

Maybe I didn't study carefully enough, but I really couldn't solve this puzzle by myself. Please help me, thanks again.