Supplier eBooks

11 dropping any messages at an application level. This allows us to time-slice Zigbee and Bluetooth communication on the same chip. In addition to Zigbee routing, Silicon Labs dynamic multiprotocol technology supports Bluetooth connections, and Bluetooth beacons. The protocol connection interval is configurable to match application requirements. For Bluetooth beacons, the radio only needs about 1ms to transmit a beacon and the connection interval between beacons is typically no shorter than 100ms. For high speed OTA firmware updates, the device will likely need to be configured to support much longer Bluetooth connection periods. These examples lie on opposite ends of the spectrum; however, with a configurable connection interval, the multiprotocol solution from Silicon Labs provides a flexible framework to meet the unique needs of different applications. To enable effective multiprotocol communication Silicon Labs has made a number of investments in both software and hardware. Wireless protocol stacks from Silicon Labs are architected to share the same low-level radio drivers and libraries (RAIL). Making use of RAIL ensures a consistent application programming interface (API) and interface to share the radio. In addition, the Radio Scheduler manages the requests from protocols for access to the radio while the Micirum OS kernel manages the sharing of resources between the stacks. The multiprotocol scheduling from Silicon Labs takes the protocols being scheduled into account and uses a priority-based scheduling methodology. Bluetooth requires a fixed connection interval for effective operation while Zigbee, with its MAC retry approach is more forgiving. For this reason, for Zigbee and Bluetooth multiprotocol operation, Bluetooth operates at a higher priority. Because of the unified architecture of wireless stacks using RAIL, radio scheduler, and Micirum OS the system is able to use a priority-based scheduling approach to balance Zigbee and Bluetooth operation. Scheduling Requirements for Single Radio Zigbee and Bluetooth Operation A number of scheduling scenarios may be required to enable the correct operation of Zigbee and Bluetooth with a single radio. The scheduler can be configured to make either protocol the higher priority with regards to radio access. However, the most likely configuration would be to make Bluetooth connections and beacons the higher priority and leave the radio in Zigbee receive mode when doing nothing else. In Figure 1, we can see that the low-priority Zigbee receive is the default, but when a Zigbee transmission is required, it interrupts that process. This is normal behavior for a Zigbee device. When a Bluetooth LE connection is scheduled, this takes precedent, and the scheduler switches out of Zigbee receive mode in time to be available for the Bluetooth connection. If the scheduler has a request for a Zigbee transmission that would exceed the time available on the radio before the next Bluetooth connection or beacon, the scheduler will reschedule the Zigbee transmission to occur after the Bluetooth activity has completed. • Ideal for developing low power IoT mesh networking applications including Zigbee and Thread • Multiple radio boards enable developers to create a mesh network and evaluate Mighty Gecko SoCs and Modules • Wide array of peripherals and sensors to test application capabilities Digi ® XBee ™ Cellular LTE Cat 1 MIGHTY GECKO MESH DEVELOPMENT KIT LEARN MORE 4 Figure 1: Zigbee background receive with Bluetooth LE having priority Wireless protocol stacks from Silicon Labs

• Cover