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:
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)?
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
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
msromero said: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?
msromero said: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?
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...
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.