Introduction to Multi-PHY and Multiprotocol#

To get the most out of this article, some familiarity with the radio configurator is required, and it's also recommended that you understand the basics of radio protocol stacks (i.e. the OSI model).

With a customizable radio, the Wireless Gecko is a great option to support any radio configuration you need. You can set it up for standard IEEE 802.15.4, Bluetooth Low Energy, WMBus, or even the protocol used by your garage door opener. However, what if you need more than one of those standards? With single protocol radios, this requires a distinct 15.4 radio chip, a Bluetooth chip, and so on for each supported standard. Alternatively, with a single Wireless Gecko, you can store multiple "setups" in your device and switch between them. The only limitation is that it's still a single radio - you can't use multiple "setups" on the radio at the same time.

The best way to manage the sharing of this single radio resource depends on the particular use case targeted by your application. We provide different solutions (discussed below) to help you identify an optimal approach for your design.

Channel-based Multi-PHY#

The most common use case in proprietary wireless is the need to support different PHY configurations. For example:

You always handle received packets the same way, but you have to receive at multiple bitrates
You have an asymmetric protocol, i.e. the Rx configuration is not the same as the Tx configuration
You need wider bandwidth for CSMA/CA than your normal Rx mode to pass regulatory standards
You have to handle different packet formats, but not at the same time: the upper layers of the stack decide which one to use
Although the PHYs are technically the same, there is a power limitation on a given channel to pass regulatory standards
The PHYs are technically the same, but the channel map is uneven - it's not possible to configure it using channel spacing

In these cases, Channel-based Multi-PHY is the best solution. It's called Channel-based, because in RAIL, you only need to change the channel to change the PHY. Channel-based Multi-PHY setups can be tested with RAILtest by selecting the channel with the setChannel serial command.

Protocol-based Multi-PHY#

This is not as widely used as Channel-based Multi-PHY, but it's the next logical step. The typical use cases:

DMP applications.
Your device will support multiple regions, and you choose one during configuration, but the device will rarely switch between those.
Your device will support multiple protocols, but the device will rarely switch between those.

For these, we recommend Protocol-based Multi-PHY. In this case, you can switch between protocols by calling RAIL_ConfigChannels() , which will load the whole configuration.

You can test your Protocol-based Multi-PHY setup using RAILtest. You can change between protocols using the setConfigIndex serial command.

Channel Change Performance#

We generally recommend the Channel-based multi-PHY approach, especially when quick channel switch time is required.

If you have significant differences between channel groups, channel changing that involves a channel group change will take somewhat longer. In most cases, this is not too significant, but you should measure and calculate with it if you need short channel switch times (PRS channels can be used for measuring this time, see the document about debugging).

Also, if you have 3 channel groups, and only a single field is different between A and B, but C is very different compared to the other two, channel change between A and B will take the same time as channel change between C and A or C and B. This is because the radio configurator searches the common config between all 3 channel groups, and the remaining will be loaded on each channel group change.

If you have a lot of channel groups in the protocol, this could also cause a small but measurable delay during channel change. It takes some time for RAIL to look up the channel group which includes the requested channel. This is because RAIL does a simple search from the first channel group on every channel group change, for historical reason.

All of these delays are a result of the implementation in RAIL. See the Understanding RAIL config files article for more details.

You can find a setup guide for some of the mentioned Multi-PHY solution use cases in the Multi-PHY Use cases and Examples article.

Dynamic Multiprotocol (DMP) between RAIL-based Protocols#

If you have full protocol stacks that are completely independent, it makes sense to develop the PHY and Link layer independently as well. These layers communicate with RAIL, and the cleanest solution to this problem is Dynamic Multiprotocol. Typical use case:

One protocol is used to communicate with key fobs, while another is used to communicate in a home automation network

In Dynamic Multiprotocol, the RAIL scheduler decides which protocol is active.

Dynamic Multiprotocol is more capable than Multi-PHY, but also more complex, so it has some drawbacks when compared to Multi-PHY:

Protocol change takes 450us on EFR32xG1x. This is a fixed worst-case delay, because the RAIL scheduler must plan time-sharing of the radio resource using calculations on a known sufficient time span in order to accommodate protocol switches. The time differs on Series 2 parts, but in general, longer than even protocol-based Multi-PHY, since it is set for worst case.
It requires the multiprotocol version of the RAIL library, which has a bigger memory footprint (both RAM and code) than the single protocol version.

Dynamic Multiprotocol between RAIL-based and other Silicon Labs Stack Protocols#

The use case for this is straightforward:

If you need Bluetooth and a RAIL-based protocol in the same application

At the moment, Silicon Labs only provides such a DMP solution based on the Bluetooth stack and RAIL. You can access it by installing the Bluetooth SDK and starting one of the DMP applications. See AN1134.