Channel scanning is a receiver side feature. Scanning usually means that a receiver switches its center frequency regularly to be able receiving packets in more frequency bands.
Most of the protocols Silicon Labs RF Software stacks support (BLE, Zigbee, Wi-Fi, Connect) use channel scanning, therefore it is important to get to know more about this topic. The usefulness of this feature is shown through the wide variety of applications, but in this article we will focus only on one type presenting the design steps and showing up several implementation tradeoffs.
First it need to be cleared, what channel does mean in context of Channel scanning. Channel is a medium between the transmitter and receiver side, characterized with physical layer parameters (carrier frequency, modulation type, bitrate, etc.). Mostly two channel differ in center frequency in a concrete protocol. This article will focus on these cases.
We should say some words about the transmitter's side. There may be more transmitter in the same network, all working on its own frequency channel or one which switches between channels (call it as Channel hopping) reducing the chance of interference with other transmitters. Channel hopping implies that one particular channel will be used less than if every packet would be sent on the same channel. Hopping may coexist with LBT and CSMA features also, further decreasing the chance of interference.
Channel hopping and so the scanning can be done either in synchronous way - as FHSS (Frequency Hopping Spread Spectrum) does - or in asynchronous way. Here the synchrony means prior experience at the receiver side. The topic of this article is the asynchronous scanning, when we only known what frequency bands are used by the transmitter(s), but nothing about the time frames, when the channel will be occupied. Our example will show how a Channel scanner can be designed to get every packet.
There is a strong relation between LDC and asynchronous Channel scanning, particularly in the sense of realization. Both has the main concept of detecting empty channel as fast as possible at the receiver side. The purpose of LDC is energy saving in a sparse network, while the purpose of the Channel scanning is rather the better frequency allocation in a dense network, so channel scanning infer a more active receiver with no sleep state.
The goal of this section is to show how to build an asynchronous channel scanning application from the beginning assuming ideal transmitter side. We should first define (or get from the standard) the channels with their center frequency. Take care of the false detection on the image frequencies.
In a Channel scanning application the task may not only be to detect the presence of a transmitter but the detection of the lack of any packet in the channel, aiding to switch channel more quickly, raising the chance to capturing a packet (and reducing both sides' power consumption). If it is desired to receive every packet on every channel, some timing consideration should be taken into account.
Since the receiver don't have prior experience about the transmitter, the application should be created with a presumption that every channel will be used with the same chance. In general the receiver scans over a hop table, which tells in what order are the channels scanned.
There are several ways to trigger a channel-switching at the receiver side. These triggers can be used together as backup mechanisms as well, to avoid false detection. This is an incomplete list of the possible trigger events:
Not all features described above are available for every Silicon Labs radios, see the relevant documentation for the possibilities!
In this article we target to use Preamble detection timeout as trigger event. Let's suppose that the transmitter is optimal. This means it transmits long enough packets (most part of the packet is the preamble) on every channel to ensure reception. To quantify this timing requirement the following variables need to introduce:
T_ri and T_detecti can be determined empirically and theoretically, respectively.
The former may differ depending on what are the differences between the two channels and how the channel switching functionality is implemented. Therefore it should be measured after defining the hop table.
The latter is described more depth in the LDC KBA at the preamble detection threshold section. The less the configured detection time, the worse the sensitivity, and the accuracy of the detection, but the lower the necessary transmit time as well.
The turnaround time (T_ta), which shows how often will the receiver listen in the same channel, can be calculated by summing T_ri and T_detecti values for all channels.
In a typical channel scanning application the transmitter transmits relatively long preambles. To ensure detection at the receiver side, the preamble should be on the air at least for one turnaround time. This is true for every channel.
Knowing the data rate at channel i (DR_i, [bit/s]) the preamble length (L_preami, [bit]) can be calculated as follows:
L_preami = T_ta * DR_i.
The channel transition time at the receiver may vary with the implementation: how much time the radio module needs to get the setting parameters (from the host) for channel switching and set those up.
EZRadioPRO supports channel scanning without host MCU control. The
RX_HOP property group has a 64 entry RX hop table for predefining channels. Each of the entries hold a channel number corresponding to the channel offset (channel number * channel spacing) from the base frequency, so the channels are placed next to each other by distance of channel spacing. Enabling this "automatic RX Hop" feature the host MCU can switch to sleep state, while the receiver scans all those channels and wakes-up the MCU only when an incoming packet detected (or received).
Other kind of implementation called as "Manual frequency Hopping" is also available on EZRadioPRO devices. The
RX_HOP command sets a new listening frequency (usually issued in RX state). With this command channel hop is faster but it needs permanently awake host MCU for scanning.
There are two examples ("Auto frequency hop RX" and "Manual frequency hop RX") among the WDS example projects implementing Auto and Manual hopping applications. We recommend using WDS to generate radio configuration for a manual as well as an automatic RX Channel scanner application, due to the property setting's complexity.
The current hopping application example (RAIL Simple TRX MultiPHY) implements frequency hopping with
RAIL_StartRx(). It had been developed exactly the same manner as we described above, but its channel configuration has a subGHz and a 2.4 GHz channel with different data rates.
Flex SDK supports also Automatic RX-side channel hopping with APIs
RAIL_EnableRxChannelHopping(). These API's cannot be called when the radio is on. We have an article on how to use those APIs and how to configure the
RAIL_RxChannelHoppingConfig_t structure. Note that RX Channel Hopping APIs work on EFR32xG12 and newer parts, but not supported with multiprotocol.
The RAIL API supports to define unlimited number of channels (limited only by the available RAM), and one channel can be defined multiple times, even with different scan times. What's more, RAIL supports more flexible channel definition, so not only the frequency but other Physical layer settings can be defined per channel. After configuring hopping parameters calling
RAIL_StartRx() starts on the first channel. There is no need to call other API, the radio automatically hops over the predefined channels. If a packet is received, the radio returns to the idle state (or to the state defined in the auto state transition configuration).