Wireless Modules Operating in the Sub-GHz Bands Offer a Simpler Route to Market for Sensor Networks


In a bid to be more efficient in the way we live, the industrialized world is becoming more automated. As well as having financial implications, improved efficiency can have a positive impact on the environment, as we use fewer natural resources and produce fewer pollutants.

Automation is underpinned by closed-loop control systems that require input in the form of data. That data is produced through monitoring the processes involved using a vast array of sensors. In the IoT era, everything is a potential source of data. Getting that data into the control loop is where connectivity comes in. The connected world offers a wealth of valuable information.

Arguably the most versatile connectivity medium is wireless as it can require little or no infrastructure beyond a pair of transceivers within range of each other. Internationally agreed licensing restrictions have created a market for solutions that focus on the license-free bandwidths. Wi-Fi and Bluetooth operating in the 2.4 GHz band are perhaps the most popular.

However, for applications such as sensor networks operating over long distances, sub-GHz technologies are hard to beat. They provide greater range than technologies based on 2.4 GHz, and while that may come at the cost of data rate, this isn’t normally a problem for sensor networks. Figure 1 shows how sub-GHz technologies fit into the spectrum.

Image of wireless technologies being applied in the IoT

Figure 1: A comparison of wireless technologies being applied in the IoT.

Pre-certified solutions

For many engineers, RF remains a challenging design domain that can demand years of experience to master. The proliferation of highly integrated wireless solutions is helping in this regard, particularly for technologies in the ISM (industrial, scientific and medical) license-free bands, such as Wi-Fi, Bluetooth, ZigBee, and others. In general, any wireless product, even those operating in the ISM bands, needs to comply with the relevant regulatory requirements of any region in which they are distributed. This normally involves putting the product through qualification and certification tests carried out by a recognized and authorized test laboratory. Most semiconductor manufacturers offering integrated circuits for use in wireless applications can help in this regard, but it is still a necessary and potentially costly process for the OEM.

A popular alternative to developing at the chip level is to use a pre-certified module. In this case, the vast majority of the design effort has already been completed by the manufacturer, including the regulatory and certification processes. It’s important to note, however, that the certification only applies to the module when used under the same operating conditions (choice of antenna, modulation scheme) employed during certification. Further testing of the final product will likely be necessary, but because the module has been pre-certified, the cost, time and effort is significantly reduced.

The use of pre-certified modules can make it as simple as possible to add wireless connectivity in a range of applications, including long-range sensor networks. To support this particular application area, a number of wireless technologies have emerged in recent years, including industry standards such as LoRaWAN, as well as proprietary technologies such as Sigfox, Tinymesh and Whisker.io.

Examples of LoRa modules include the RN2483 from Microchip and the CMWX1ZZABZ-078 from Murata Electronics North America. The RC1692HP-SIG is a Sigfox module from Radiocrafts AS, which also supplies the RC1191HP-TM module, which employs the company’s proprietary protocol, Tinymesh. Another example of a proprietary solution is the Whisker.IO Engine from Digital Six Labs. The remainder of this article will look at these modules and their protocols in more detail, and explore how they may be used in long-range wireless sensor networks.

Low power, wide area

The emergence of various low-power wireless technologies intended to operate over long distances (many kilometers) provided the incentive needed for the industry to create the LoRa Alliance and the LoRaWAN protocol. It uses a star-of-stars network topology and is intended to make it easier for manufacturers to create their own networks using interoperable solutions, while not needing to rely on network providers. Private networks are also available, in which gateways can often coexist with cellular base stations and make use of spare capacity for the backhaul.

The RN2483 module from Microchip is intended for use in end devices in a network, such as a sensor node or actuator. Featuring a range of more than 15 km and 10+ year battery life, the module is R&TTE certified for use in Europe. With 14 general purpose I/O available, the module is able to interface with many sensors and actuators, while the integrated UART port provides an interface to a host microcontroller. The module can operate at 433 MHz or 868 MHz, and is configured by the host MCU using ASCII commands sent over the UART interface (Figure 2 shows a block diagram of the module).

Diagram of RN2483 LoRa module from Microchip

Figure 2: The RN2483 LoRa module from Microchip.

The CMWX1ZZABZ LoRa module integrates the SX1276 transceiver from Semtech with an STM32L0 Series MCU from STMicroelectronics (ST) running the LoRa protocol. The pre-certified module complies with both 868 MHz and 915 MHz transmissions. Application code can be added to the MCU using ST’s LoRaWAN SDK. It is also supported by the Keil MDK for STM32L0.

Unlike LoRaWAN, Sigfox is a proprietary protocol running across private networks, operated locally by Sigfox partners. A unique aspect of this protocol is that the need to negotiate a connection has been removed. The node simply transmits its payload and the data is made available to subscribers through cloud connectivity. In this respect it offers perhaps the simplest way to connect a sensor to the internet. The RC1692HP-SIG is a pre-certified Sigfox module from Radiocrafts operating in the 902 - 928 MHz band that supports both network modes: uplink-only and uplink/downlink. The former might be used in a sensor node that is simply providing data, while the latter could be used to include some form of actuation in the node.

The potential for proprietary protocols remains high in the sub-GHz part of the spectrum, where they have traditionally been very strong, even before the IoT. The RC1191HP-TM, also from Radiocrafts, implements its own proprietary protocol, Tinymesh. Unlike LoRa and Sigfox, this protocol is based on a mesh network, and as such, works best when many modules are deployed in one area and become interconnected in a ‘mesh’ formation. This helps ensure robustness in the network as payloads have multiple potential paths back to a gateway. The Tinymesh protocol stack comprises a set of multi-hop protocols that enable devices to exchange data with an embedded application layer that can remove the need for a host MCU in many cases. The network contains end-points, gateways and routers. Any Tinymesh enabled device can be configured to perform one of these functions. The Tinymesh proposition is complemented by cloud-based services offered by Tiny Mesh AS.

By combining LoRa modulation with a proprietary protocol, Digital Six Labs has developed products to create an entire IoT network infrastructure including gateway and end-points. At the heart of its solution is the Whisker.IO Engine, which can be connected to sensors and actuators, and achieve transmission ranges of up to 40 miles.

Protocols

The right sub-GHz technology for a given application will depend on many things, such as the physical size of the network (or distance between nodes) and the amount of data to be sent/received.

A wireless sensor network intended to monitor conditions in an agricultural environment, for example, may require relatively small payloads sent just several times a day. A food production plant may require more information to be sent more frequently, across smaller distances.

The LoRaWAN protocol supports a variable payload based on the data rate, which can range from 51 bytes for the slowest rate to 222 bytes for the highest (this is also subject to the regional specification/limitations). Digital Six Labs’ technology, based on LoRa, is able to send a maximum of 32 bytes per message, while networks based on the Sigfox protocol can support messages of 12 bytes, sent at 100 bits/s.

Getting connected

Wireless modules are intended to be largely ‘plug and play’, and although some do support the application code running on the module itself, they will invariably be used with a host MCU connected over a serial interface. The reason for this is partly to protect the pre-certification of the module, as any changes to the module could mean going through the certification process again.

All of the modules covered here can be controlled by a host MCU. For example, the RN2483 LoRa module from Microchip is compliant with the LoRaWAN Class A protocol, the lowest power of all three LoRaWAN protocols. This means the end point initiates uplinks of payloads and sets a time to receive payloads. All of the configuration settings for the module are controlled through three types of commands, as shown in Figure 3.

Image of command interface of the RN2483 LoRa module from Microchip

Figure 3: The command interface of the RN2483 LoRa module from Microchip.

The mac commands are used to for the Class A configuration and control commands. The host MCU communicates with the module through the UART interface using ASCII. An example would include:

mac tx <type> <portno> <data>

The tx command initiates the transmission of data, the <type> variable specifies whether the payload is confirmed (cnf) or unconfirmed (uncnf), the <portno> represents the port (1 to 223), and the <data> is the payload in hexadecimal. A number of responses may be received after the transmission, including an error message if the transmission was not successful or if any of the parameters were incorrect.

The RC1692HP-SIG Sigfox module is also intended for use with a host MCU equipped with a UART interface, as shown in Figure 4a. All data and configuration is sent to and received from the module through the UART interface. The configuration of the module is initiated and completed by the host MCU, as depicted in Figure 4b.

Diagram of UART interface of the RC1692HP-SIG Sigfox module from Radiocrafts

Figure 4a: The UART interface of the RC1692HP-SIG Sigfox module from Radiocrafts.

Flow diagram of configuration mode of the RC1692HP-SIG module from Radiocrafts

Figure 4b: This flow diagram depicts the configuration mode of the RC1692HP-SIG module from Radiocrafts.

The module can be put into a sleep mode using the UART interface as well as automatically; however, it must also be woken up through the same interface by the host MCU, and no messages will be received when it is in sleep mode.

The module includes a temperature sensor that can be read using a dedicated command, returning a single byte representing the temperature in degrees Celsius, with an accuracy of ±2°C.

The Whisker.IO Engine modules have been designed with sensors in mind, integrating two 10-bit inputs, as well as two digital inputs and one digital output. A UART interface and an I2C port can be used to expand the functionality through the addition of ADCs, DACs and other sensors equipped with a serial interface (such as MEMS sensors).

Digital Six Labs claims that setting up a wireless sensor network using the Whisker.IO Engine is most easily achieved using the Whisker Network Manager, however, the modules can also be managed at a lower level using AT commands.

Example application using the Whisker.IO Engine from Digital Six Labs

Figure 5: An example application using the Whisker.IO Engine from Digital Six Labs.

Figure 5 shows an example of a simple application, the AT commands that would be used to configure the application are:

ATTM01EE32092C

ATMA

ATTM12E5AA33

ATMA

ATTM73233CBA1

ATMA

Once configured, reading the inputs of module EE32092C would require the following commands:

ATTM01EE32092C

            Response: OK

ATRA03

            Response: OK

            Response: RMRA03014ac0

The first command initiates communications between the master and the module EE32092C, followed by the command to request a reading from analogue channel 3. The second response contains the data value 0x014a, or decimal 330, which shows that the battery level is 3.3 V.

Conclusion

The use of pre-certified modules to create wireless sensor networks operating in the sub-GHz bands offers many benefits. It removes the design challenge of developing in the RF domain, and provides a much faster and cost effective route to market.

Demand for wireless sensor networks is growing as manufacturers see the benefits of collecting data about their products and the environment. The ease with which a wireless sensor network can be designed, implemented and administered is now simpler than ever thanks to the wide proliferation of pre-certified wireless modules.

Supplier