Develop with LoRa for low-rate, long-range IoT applications

Develop with LoRa for low-rate, long-range IoT applications

Technology News |
Designers have a wide variety of wireless technologies to connect a product to the Internet of Things (IoT). Each technology suits different applications, requiring designers to carefully consider factors such as range and data rate, cost, power consumption, volume, and form factor. This article will introduce the LoRa protocol, compare its advantages to other protocols, and discuss several products and development kits that enable engineers to get started quickly developing LoRa-based systems.
By Jean-Pierre Joosting


Wireless IoT tradeoff considerations

Each wireless technology has both strong and weak points. Standard Wi-Fi, for example, can transmit large amounts of data at high speeds, but it has a limited range. A cellular network combines high speed and long range, but it’s power hungry.

IoT applications such as remote data acquisition, urban lighting control, weather monitoring, and agriculture, each have a different set of priorities. The quantities being measured or controlled in these applications such as weather conditions, soil moisture levels, or streetlights, all change very slowly over an extended period of time.

In addition, the sensor nodes are often miles apart and are battery powered, so the optimum wireless protocol must be able to send small data packets efficiently over long distances with minimum power consumption. The LoRa protocol was designed for exactly these requirements.


Overview of LoRa technology

LoRa is targeted at low power, wide area network (LPWAN) applications. It has a range of over 15 kilometers, and a capacity of up to 1 million nodes. The combination of low power and long range limits the maximum data rate to 50 kilobits per second (Kbps).

LoRa is a proprietary technology owned and patented by Semtech Corporation, operating in the ISM band. The frequency allocation and regulatory requirements for ISM vary by region (Figure 1). The two most popular frequencies are 868 MHz used in Europe, and 915 MHz used in North America. Other regions, notably Asia, have different requirements.

Figure 1: A comparison of LoRa specifications for Europe and the US, two regions where ISM bands are widely used. (Image source: LoRa Alliance)

The LoRa physical layer uses spread spectrum modulation (SSM) (Figure 2). SSM encodes the base signal with a higher frequency sequence, which deliberately spreads the base signal over a wider bandwidth, reduces power consumption, and increases resistance to electromagnetic interference.

Figure 2: A spread spectrum system multiplies the input data by a much faster code sequence that spreads the signal bandwidth. (Image source: Semtech Corporation)

The spreading factor (SF) of the base signal is variable and represents a tradeoff. For a given available bandwidth, a larger spreading factor reduces the bit rate, but also reduces the battery life by increasing the transmission time.

A specified spreading factor (SF) and bandwidth (BW) will give a bit rate defined by:

Bit Rate = SF x BW/2SF

LoRa allows for six spreading factors (SF7 – SF12) and three different bandwidths (125 kHz, 250 kHz, 500 kHz). The allowable spreading factors and bandwidths are defined by the regional regulatory agencies. North America, for example, specifies a 500 kHz bandwidth and spreading factors of 7 to 10.

Due to the spread spectrum technology, messages with different data rates are orthogonal and do not interfere with each other by creating a set of “virtual” channels, increasing the capacity of the gateway.

The LoRa scheme is based on a variant of SSM called chirp spread spectrum (CSS) modulation (Figure 3). CSS encodes the data with a “chirp,” which is essentially a wideband frequency modulated sinusoidal signal that increases or decreases over time.

Figure 3: A CSS “upchirp” can either follow a polynomial expression for frequency vs. time, or exhibit a linear relationship as shown here. (Image source: Wikipedia)

CSS is well suited for low data rate (<1 Mb/s) applications requiring low power usage. IEEE 802.15.4a, another low rate standard, specifies it as a technique for use in wireless personal area networks (LR-WPAN). CSS has been used for many years to provide long-range, robust communication in military and space applications, but LoRa is the first low-cost commercial implementation.

LoRaWAN and the LoRa network architecture
The LoRaWAN specification defines the media access control (MAC) layer for LPWAN. LoRaWAN is implemented on top of the LoRa physical layer and specifies the communication protocol and network architecture. These functions have a high degree of influence over several performance parameters, including:

  • The battery lifetime of a node
  • Network capacity
  • Network security
  • The applications served

The LoRaWAN network architecture uses a star-of-star topology in which each end node communicates with multiple gateways communicating with the network server.

The LoRa network has four elements (Figure 4):

  • The End Nodes gather sensor data, transmit it upstream, and receive downstream communication from the application server. Endpoint devices use single-hop wireless communication to one or many gateways.
  • The Concentrator/Gateway acts as a transparent bridge and relays bi-directional data between the end nodes and the upstream servers.
  • The Network Server connects to multiple gateways via a secure TCP/IP connection, either wired or wireless; eliminates duplicate messages; decides which gateway should respond to an end node message; and manages end node data rates with an adaptive data rate (ADR) scheme to maximize network capability and extend end node battery life.
  • The Application Server collects and analyzes data from the end nodes and determines end node actions.
Figure 4: A LoRa network has four main blocks and two security layers. (Image source: LoRa Alliance)

Endpoint communication is normally bi-directional, but LoRa also supports multicast operation for functions such as software upgrades. Many competing protocols, such as ZigBee, employ a mesh topology in which individual end nodes receive and retransmit information from other end nodes. This approach increases the range and cell size of the network, but the added communication overhead adds complexity, reduces network capacity, and increases the power consumption of individual nodes.


LoRa end node classifications

There are three classes of end node devices. All three classes allow bi-directional communication and can initiate an uplink to the server via the gateway. They differ in when they accept incoming server messages.

A LoRaWAN Class A device consumes the least power. An end node only allows communication from the server during two short receive windows that open for a short period after an uplink transmission. Messages from the server at any other time must wait until the next scheduled uplink time. A Class A device is asynchronous. An endpoint begins a transmission whenever it has data to send, then waits for a preset time and listens for a response.

A LoRa Class B device provides Class A functionality, but also opens extra receive windows at scheduled times. To synchronize with the network, the Class B node receives a time synchronized beacon from the gateway every 128 seconds. It is assigned a time slot within that 128 seconds that lets the server know when the end device is listening.

A LoRa Class C device provides nearly continuous open receive windows. The windows are only closed during endpoint transmissions. A Class C device is suitable where a large amount of data needs to be received rather than transmitted.

LoRaWAN security

Robust security is a key element of any LPWAN design. LoRaWAN uses AES 128-bit encryption and has two independent layers of security, a Network Session Key (NwkSKey) and an Application Session Key (AppSKey) (Figure 5).

Figure 5: The flow of data from a LoRa end device to the application includes encryption and decryption at the beginning and end of the chain, so only the end node sensor and the application have access to plain text data. (Image source: Microchip Technology)

The network security layer ensures the authenticity of the node in the network, and the application security layer ensures the network operator does not have access to the end user’s application data.

There are two methods to deploy the keys:

  • Activation by Personalization (ABP): Here, LoRaWAN end devices can be factory programmed with the authentication information for a specific LoRaWAN network.
  • Over-the-Air Activation (OTAA): This uses an application ID, a unique device ID, and a network assigned device address to derive the NwkSKey and AppSKey. This method is preferred because the keys are not pre-determined and can be regenerated.

Getting started with LoRa development

Manufacturers offer designers a range of LoRa options with levels of integration ranging from individual devices to full development kits.

Semtech Corporation’s SX1279 single-chip LoRa transceiver can cover both European and North American ISM bands (Figure 6). Depending on the applicable regulations, the device offers channel bandwidths ranging from 7.8 kHz to 500 kHz, and spreading factors ranging from 6 to 12.


Figure 6: The Semtech SX1279 offers effective bit rates from 18 bits/sec to 37.5 kilobits/sec, a wider range than LoRaWAN allows. (Image source: Semtech Corporation)

At the module level, Microchip, a licensee of LoRa IP, offers the RN2483 for 868 MHz European applications and the RN2903 LoRa for North American 915 MHz applications (Figure 7). Both modules contain an application-specific microcontroller with the LoRa protocol stack, a LoRa-compliant radio transceiver, a serial EEPROM that provides the device with a unique EUI-64 identifier, and fourteen input/output (I/O) pins for analog or digital sensor inputs, switches, or status indicators.

These modules are designed for Class A use and achieve long-range operation with an integrated +18.5 decibel-milliwatts (dBm) output high-efficiency power amplifier (+14 dBm in the RN2483), coupled with a receiver sensitivity of -146 dBm.

Figure 7: A typical RN2903 end node can include both input and output functions. The optional ICSP port can be used to update the firmware. (Image source: Microchip Technology)

At the board level, Microchip offers the DM164139 Mote, a Class A end device based on the RN2903 LoRa modem. The Mote is a standalone battery powered node that provides a convenient demonstration platform for the long-range capabilities of the RN2903.

The Mote includes light and temperature sensors. The data transmission can be initiated by a button press, or transmitted on a fixed schedule. An LCD displays information such as connection status, sensor values, or downlink data.

The board connects to a computer via a USB 2.0 micro-B connector that provides access to the RN2903’s UART interface. The UART allows rapid setup and control of the on-board LoRaWAN protocol stack via a high level ASCII command set.

The RN2483 modem has its own Mote board, the DM164138.

Finally, the DV164140-2 LoRa Network Evaluation Kit, also from Microchip, includes two RN2903 Mote boards and a gateway board (Figure 8). This makes it easy for designers to evaluate the capability of a complete 915 MHz LoRa system. A sister kit, the DV164140-1, covers 868 MHz applications.

Figure 8: Microchip’s DV164140-2 (915MHz) and DV164140-1 (868 MHz) LoRa Evaluation Kits include two Mote boards, the gateway core board, and the radio board (left to right). (Image source: Microchip Technology)

The gateway board consists of a Core board and an attached Radio board. It includes an LCD screen, an SD Card for Config Data, an Ethernet connection, an antenna, and full-band capture radios.

The gateway board interfaces to the host PC through a USB cable that supplies both power and communication. Additionally, an Ethernet cable is connected between the Core board and the PC’s local area network (LAN) connector for communication between the gateway and server.

The Mote development board is connected to the host computer through its own USB connection.


Network evaluation kit software

The evaluation kit software consists of Microchip’s LoRa Development suite, which can be downloaded free from Digi-Key’s DV164140-2 product page. Available for Mac, Windows, or Linux machines, the suite sets up a local version of the LoRaWAN network server that runs under the host OS without an external network connection. The development suite creates a self-contained demonstration network that makes testing the LoRa network quick and easy.

Internally, the LoRa development suite makes use of Docker, an open-source development platform for running containerized applications. Docker allows the Oracle Virtual Machine (VM) to operate in a Windows, Mac, or Linux environment (Figure 9). The VM hosts the Docker Engine that in turn runs the LoRa evaluation server. The evaluation server communicates with the gateway board via the Ethernet port, which relays data to the RN module via the LoRa link.

Figure 9: The LoRa network evaluation kit implements an evaluation LoRa server that runs under the host computer’s OS. (Image source: Microchip Technology)

The LoRa Development Utility runs within the Java Runtime Environment (JRE), a set of software tools that allows the development of Java applications. The utility allows the user to perform a range of tasks such as: scan the network for new end devices; grant them access to the network; create a new Application Server; and configure the network (Figure 10).

Figure 10: The LoRa Development Utility that can be downloaded from the Evaluation Kits’ product page controls many LoRa Evaluation Kit functions, including network configuration. (Image source: Microchip Technology)


The LoRa protocol satisfies an important IoT need for long-range, low-power, low data rate communications. This article has discussed the LoRa physical layer and LoRaWAN specifications that make this possible, and highlighted a range of devices and kits that help designers quickly evaluate LoRa’s performance in a range of target applications.


About the Author

Rich Miron, Applications Engineer at Digi-Key Electronics, has been in the Technical Content group since 2007 with primary responsibility for writing and editing articles, blogs and Product Training Modules. Prior to Digi-Key, he tested and qualified instrumentation and control systems for nuclear submarines. Rich holds a degree in electrical and electronics engineering from North Dakota State University in Fargo, ND.

Linked Articles
eeNews Wireless