Multiprotocol wireless connectivity can deliver a better consumer experience, enable designs to service multiple regions, and support field upgrades to meet evolving market needs. Take advantage of a multiprotocol software and wireless SoCs with an integrated Arm® Cortex®-M4 MCU to introduce Bluetooth® low energy technology (BLE), Zigbee, Thread, and proprietary wireless connectivity to get to production faster.
Multiprotocol SoC Families
|Family||Zigbee||Thread||Bluetooth||Proprietary 2.4 GHz||Sub-GHz||Multiprotocol Zigbee BLE||Multiprotocol Sub-GHz BLE||MCU||Flash (kB)||RAM (kB)|
|Mighty Gecko||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Arm Cortex-M4||256 - 1024||32 - 256|
|Blue Gecko||No||No||Yes||Yes||Yes||No||Yes||Arm Cortex-M4||128 - 1024||16 - 256|
|Flex Gecko||No||No||No||Yes||Yes||No||No||Arm Cortex-M4||32 - 1024||8 - 256|
EFR32 Wireless Gecko SoCs provide enough memory and offer features including over-the-air software updates to support application enhancements and evolving protocol needs in the field. With Silicon Labs' multi-protocol software and hardware you can design a single product that supports multiple wireless connectivity protocols. This can be the same device that is capable of connectivity to multiple protocols in the field or a device that can be configured in the field or factory to one of a number of different wireless protocols. By using the same SoC that supports multiple protocols, or pin compatible SoCs for specific protocols, you have flexibility in your go-to-market approach. With a secure update mechanism you are also in a position to update devices in the field to add additional functionality or to react to any changes in the market such as surge in popularity of a specific ecosystem that requires a specific mesh technology.
Here's a brief look at the different types of multiprotocol connectivity and their benefits.
Programmable multiprotocol support entails having a chipset that, when programmed with the right software stack, can run any number of wireless protocols. Being able to program a chip in production to support Bluetooth low energy, Zigbee, Thread or a proprietary protocol means you can streamline your hardware design and quickly address different markets. A chip platform that supports multiple protocols via different software images is a fundamental prerequisite for all other multiprotocol use cases.
Switched multiprotocol enables your connected device to change which wireless protocol is being used by bootloading a new firmware image when the device is already deployed in the field. The consumers experience of settting up or comissioing your product can be greatly improved my making use of smartphone connectivity to swtich between Bluetooth low energy securely onto Zigbee, Thread and other wireless networks. With the addition of over-the-air (OTA) updates devices can also be updated in the field to evolve to changing market needs.
Ultimately, any multiprotocol solution must address the possibility of simultaneously running multiple wireless protocols together on one chip, using a time-slicing mechanism to share the radio. This approach opens up even more use cases, especially when combining Bluetooth low energy with other wireless protocols. The simplest of these use cases involves the periodic use of Bluetooth beacons in retail environments from a device that normally operates on Zigbee, Thread, or a sub-GHz wireless protocol.
Dedicated operation of multiple protocols without any trade-offs, especially where different radio frequencies are used by different protocols, requires two radios. There is a lot of value in an application and networking stack that can operate across two radios that perhaps even utilize two completely different frequency ranges. One example of this is smart metering in Great Britain, where the government will deploy dual PHY Zigbee communications hubs in 30 million households and businesses by 2020. This effort is to enable a Home Area Network that contains both 2.4 GHz Zigbee devices and sub-GHz Zigbee devices (operating in the 868 MHz band), maintained on the same logical PAN with the communications hub routing traffic between devices on different radio frequencies.
|Performance||Bandwidth shared across multiple protocols; potential increased latency and missed packets||No compromises|