Issue link: https://resources.mouser.com/i/1442793
Digi ® XBee ™ Cellular LTE Cat 1 SUB-GHz, 2.4GHz, AND BLUETOOTH MULTIBAND WIRELESS STARTER KIT LEARN MORE 4 12 If the transmission time for a Zigbee packet exceeds what was expected, perhaps due to backoffs or clear channel assessment, the scheduler can interrupt that transmission and switch to Bluetooth. To the Zigbee stack, this looks like a failed attempt, so it retries the transmission, and this time it succeeds, as shown in Figure 2. Similarly, if a remote Zigbee node attempts to send a packet to the device while it is in the middle of a Bluetooth connection or beacon, the device cannot receive the packet, but the sending device will retry (IEEE 802.15.4 MAC retry), and the packet will be received on the second attempt. Also, if the device is in the middle of receiving a Zigbee packet when a Bluetooth connection or beacon is due, the scheduler can interrupt the packet reception, and the sending device will not receive an acknowledgement. As a result, it will retry the transmission and succeed on the second attempt. Figure 3 shows both scenarios. The radio scheduler must handle a variety of scenarios to manage conflicts between wireless protocols, but the individual protocol stacks do not have any awareness of one another, only that they must request access to the radio and whether their transmission or reception has been successful. For additional radio scheduling examples please refer to the Dynamic Multiprotocol Users Guide Evaluating Dynamic Multiprotocol Performance In order to understand device behavior when running multiple protocols, it is important to measure and compare performance under multiple configurations. For the case of Zigbee and Bluetooth running on the same SoC and single radio the scenarios may include: - Zigbee throughput vs Bluetooth connection(s) and/or advertisement intervals - Zigbee latency vs Bluetooth connection(s) and/or advertisement intervals - Zigbee throughput or latency vs varying Bluetooth packet types and sizes - Zigbee retries and network behavior for varying Bluetooth connections and/or advertisements Using the test setup outlined in Figure 4 a sample test executed on a Silicon Labs Wireless Gecko STK board using a radiated test setup gives the following results: For the results displayed 802.15.4 MAC and Zigbee NWK layer retries were enabled while Zigbee APS layer retries were not. The device was configured to transmit 70 bytes of payload across one hop while the Bluetooth connection was maintained with a keepalive at the noted connection interval. Figure 2: Bluetooth connection interrupts Zigbee transmission Figure 3: Both scheduling scenarios Figure 4: Dynamic Multiprotocol Test Setup • Includes support for Bluetooth low energy (LE), sub-GHz, 2.4GHz, and multiband multiprotocol • Ideal kit to develop applications that simultaneously support sub-GHZ and Bluetooth on single chip • Wide array of peripherals and sensors to test application capabilities