Data transfer Range Extender using LoRa Repeater

ABSTRACT

The LoRaWAN technology, an example of Low Power Wide Area Network, is considered a
possible IoT-derived solution for realizing private cellular (single-hop) communications in the
industrial domain. However, despite LoRaWAN promises long range and dense environments
with many obstacles (as the industrial ones), it may suffer from coverage issue. Additionally,
the inverse relationship between data rates and range may be unacceptable for many
industrial applications. In this paper, an innovative LoRaWAN range extender (based on an
enhanced LoRaWAN node) is described, and its integration in the infrastructure of IIoT-
enabled industrial wireless networks is presented. A frame relay strategy is suggested, thus
avoiding to trade-off the highest data rates against an increased sensitivity. The feasibility of
the solution is formally verified and the features of the realized proof-of-concept prototype,
based on commercially available hardware, are discussed. The experimental results, obtained
with a purposely designed test bench, show the effectiveness of the proposed approach. In
particular, the range extender is transparent for legacy LoRaWAN networks as confirmed by
correct relaying of uplink and downlink for different types of LoRaWAN message.

Electric power Internet of Things (IoT) is a network system that can meet multiple
requirements of the power grid, such as infrastructure, environment recognition,
interconnection, perception and control. Long Range Radio Wide Area Network (LoRaWAN)
with the advantages of ultra-long transmission and ultra-low power consumption, becomes
the most widely used protocol in the electric power IoT. However, its extremely simple star
topology also leads to several problems. When most of terminals depend on one or several
gateways for communication, the gateways with heavier communication tasks have poorer
communication quality. The load of each gateway is unbalanced, which is hardly conducive to
a long-term network operation. At the same time, in the electric power IoT environment,
there are some features such as complex terminal deployment environment, wide coverage,
and large interference. These characteristics can lead to more vulnerable links and even
interruptions in communication services. Therefore, this paper proposes an adaptive link-
level recovery mechanism based on link adjustment for LoRaWAN. When a communication
link fails, multiple candidate links are selected based on Quality of Service (QoS)
requirements, the distribution of LoRaWAN gateways and repeaters. The final adopted link is
selected from multiple candidate links using the following method. Considering network load
balancing, a Link Recovery Adaptive algorithm based on the Kuhn-Munkras algorithm
(LRAKM) is designed from the perspective of fault tolerance. This method is to adaptively
adjust some communication tasks to the sub-optimal communication link. One or more
gateways on the optimal communication link of these communication tasks are overloaded.
This adaptive adjustment can make the network load more balanced. The simulation result
shows that LRAKM has a higher link recovery rate. It also shows that the whole network is
more balanced in both sparse and dense environments. Furthermore, when the network load
is heavier, LRAKM also has a better effect on balancing the network load and improving the
link recovery rate.

INTRODUCTION
IoT is a rapidly developing technology that has made great achievements in smart cities, smart
agriculture, and smart medical care in recent years. The deployment of IoT requires low
energy consumption, low cost, and low complexity terminal equipment to complete long-
distance transmission. Power IoT sensing networks are characterized by diverse sensing
services, distinct network structure differentiation, and the need to carry large-scale data
volumes. LoRa, a Low-Power Wide-Area Network (LPWAN) technology, has become an ideal
choice in power IoT sensing network reasoning that it could support massive sensing
terminals and meet all those requirements.

LoRa is a new chip released by Semtech based on the ultra-long-range low power data
transmission technology below 1GHz. LoRa technology utilizes advanced spread-spectrum
modulation technology and advanced Forward Error Correction (FEC) codec technology,
which expands the coverage of wireless communication links. Meanwhile, currently, there
are some other communication methods to achieve data transfer, such as Power Line
Communication (PLC) or Zigbee in a short distance, or use GPRS to connect directly to each
meter. A LoRa gateway can connect hundreds or even thousands of terminals under different
usage conditions. Communication between terminals and LoRa gateways can be transmitted
through different channels and coding rates. The coding rate mainly depends on the
communication range and duration. The communication between different coding rates does
not interfere with each other. By adjusting the Spreading Factor (SF) and error Correction
Rate (CR), a better balance can be achieved among signal bandwidth occupation, data rate,
link budget improvement, and anti-interference. LoRaWAN also provides a scheme called
Adaptive Data Rate (ADR), which is used to control the transmission parameter settings of the
uplink from terminals and LoRa gateway.

Compared with the mesh network topology, LoRaWAN using star network topology has the
simplest network structure with the lowest latency. However, this simple structure also raises
many problems. In a scenario where there are too many terminals accessed by a single
gateway, it is prone to the consequences of packet collision. In addition, power IoT terminals
are mostly deployed outdoors and in the wild. The deployment environment is complex,
harsh, and changeable. Terminals and communication links are susceptible to the external
environment. Frequent failures lead to communication interruption, which is not conducive
to power IoT sensing continuous and effective operation of the network.

In order to solve the above problems, an adaptive mechanism for link failure recovery is
proposed in this paper. The main contributions of this paper are listed as follows.

We propose an adaptive link-level recovery mechanism from the perspective of fault

tolerance. This mechanism with repeaters as backup links aims to eliminate critical nodes and
ensure network load balancing.

We propose a system for quantitatively scoring gateways by QoS, latency, duty cycle, and
distance from the terminal. We propose a complementary virtual node model to match
terminals with gateways or repeaters.

The rest of this paper is organized as follows. Section II introduces the related work and LoRa
application in power scenarios. Section III describes the network model we are using to define
the scenario. We proposed a KM-based link recovery adaptive algorithm in Section IV. Section
V shows the simulation results of the link failure recovery rate in two different scenarios.
Section VI summarizes this paper.

2 Related Work
In recent years, due to the rapid development of low-power wide area networks, more and
more improvements have been made to it. In order to improve LoRa coverage and stability,
many pieces of research have introduced multi-hop structures into LoRa.

Reference developed a multi-hop network combining LoRa and concurrent transmission,

which can significantly improve network efficiency. This paper proposed the offset-CT method
to preventing the timing offset from diverging over the multi-hop network. Reference
presents the prototype design and testing of a long-range, self-powered IoT devices. The
coverage area and range can be extended significantly by deploying the devices in a multi-
hop network topology. Reference used multi-hop LoRa configurations to extend the range
and increase the energy efficiency of the network. They also consider the optimal repeater
placement in two or three hops. Reference reports signal strength measurements for inter-
building LoRa links and provides insights on factors that affect signal quality such as the
spreading factor. Reference develops a new receiver structure that enables the superposed
LoRa signals with different odd/even SFs to be demodulated simultaneously based on the
capture effect. Simulations verify that, through utilizing the capture effect, the proposed
protocol can partly tackle the collisions due to numerous access attempts, which results in
enhancing the throughput compared to LoRaWAN.

In addition, in order to increase the transmission rate and throughput of LoRa, there are many
papers proposing a hybrid structure of Lora with other communication protocols to
compensate for the structural deficiencies of LoRa and applying it to the smart grid.

Reference proposes an energy-efficient network topology and an efficient time division

multiple access protocol used in conjunction with LoRa. The on-demand Time Division
Multiple Access (TDMA) protocol provides more efficient broadcast and unicast services for
data transmission, improving the performance of traditional LoRa networks. Reference
proposed a LPWAN communication structure for monitoring distribution networks and
designed a 3G-LoRa-Sigfox hybrid communication architecture. If priority is given to coverage,
use the Sigfox network, and if priority is given to energy consumption, use the LoRa network.
Due to terrestrial structures in urban and suburban environments, the link distance of LoRa
transmissions can be reduced. Reference provides a data-driven comparison between LoRa
and a variant of frequency-hopping based modulation named Telegram Splitting Multiple
Access. Network performance comparison is conducted through system level simulations
using multiple IoT applications. It is to satisfy the precise needs of heterogeneous applications
and network deployments. Reference introduces the application of LoRa technology in IoT
scenarios, discusses its advantages over efficiency, effectiveness, and architectural design
over established models, especially for typical smart city applications. Reference checked the
wireless access method of both NB-IoT and LoRa for the novel IoT smart grid application
requirements. Reference proposed a communication architecture based on LoRaWAN Class
B to assess its feasibility for modern power grid.

3 Network Model:

Figure 1: Architecture Logic Diagram

shows the logical structure of the scene set in this paper. Terminals are directly connected to
LoRa gateway. The repeater is used as a backup link. It could be another functional device
with a LoRa module. The network is a highly redundant network. Many repeaters or LoRa
gateways will receive data from the same terminals. Only one repeater or LoRa gateway will
continue to process these data. When the current link fails, the alternate set is all the
gateways (or repeaters) that receive the redundant data. This network model makes full use
of existing equipment and improves the stability of the network.
A network consistent with a finite number of N terminals, R repeaters and 2 LoRa gateways
are considered in this paper. Let k denote the failure probability. For model tractability, each
terminal sends a data packet with a length of payload at random moments in each period T.
In each period, all the terminals involved in the N k links need to be adjusted.
4 KM-Based Link Recovery Adaptive Algorithm
The process of the KM-based link recovery adaptive algorithm proposed in this paper is as
follows.
we calculate the duty cycle of each gateway or repeater in order to determine how busy each
gateway or repeater is. It determines the set of alternatives through other gateways or
repeaters that receive redundant data, which in turn discovers all available communication
links. The candidate links are screened from the aspects of delay, energy consumption,
adaptive rate attributes of the communication link and the QoS requirements of the
transmission. The links that meet the conditions are sorted according to the communication
quality. After considering the selection of all other concurrent communication links, the best
communication link is adaptively and precisely matched to recover the network failure based
on the ranking result.
4.1 Scoring System for Candidate Links
This paper quantifies and scores the QoS requirements of the terminal (upstream and
downstream data flow requirements, delay, bandwidth, etc.). Let the function

be the final score of each gateway or repeater for terminal n. The higher
the score, the busier the gateway or repeater.

where represents the load rate of the gateway/repeater r on the channel with
the spreading factor SF. There are 6 different channels, which do not affect each other. SF

value ranges from 7 to 12. indicates the distance from terminal n to gateway or
repeater r. indicates the transmission time between r and terminal (using ADR). Delay and
bandwidth are reflected in the transmission time. For other constraints such as upstream and
downstream data flow requirements, jitter, etc., when a link does not meet these conditions,
the mark value of the path is set to positive infinity.
This paper sets the spreading factor (SF) by calculating the distance between the terminal and
the repeater or LoRa gateway. In general, adjusting the adaptive rate is limited to the
terminals are moving, but in this paper, although the position of the terminal is fixed, due to
the change of the link, the relative position of the LoRa gateway or repeater and the terminal
changes. Therefore, the rate needs to be adjusted to match the current link conditions. The
value depends on the distance,

The adaptive symbol rate ADR is

According to the characteristics of LoRa, when the bandwidth and code rate are fixed, the
transmission rate of LoRa is determined by the spreading factor.
LoRa packet time is equal to the sum of preamble time, packet transmission time, and the
length of the preamble can be calculated by the following formula:

where

represents preamble length, represents the number of symbols

transmitted per unit time. H represents the header, if there is a header, H equals 0. if there is
not, H equals 1. PL represents the number of payload bytes.
LoRa uses pure ALOHA for transmission. If two data packets collide, then the total time taken
by the two data packets is the time when the next data packet ends and the time when the
previous data packet starts to be sent. The load factor (P) formula is

4.2 Complementary Matching Model

Kuhn-Munkras algorithm can be used to find maximum-weight matchings in bipartite graphs
[22]. It is based on the Hungarian algorithm. Traditional KM algorithm can only deal with
complete graph problems. However, in this scenario, the number of sensors and gateways is
unequal. Multiple sensors can correspond to the same gateway. Based on these new features,
the improved model proposed in this paper adds virtual nodes on the gateway side and the
sensor side. If the terminal sensor node cannot be connected to the gateway, the weight of
the connected side is positive infinity. The mark value of the remaining side is the weight of
that side. At the same time, edges’ weights between virtual terminal sensor node and any of
the gateway nodes are all zero.
 Figure 2: Sketch map of adding a virtual node
When adding virtual nodes, this paper first considers the nodes on the gateway and the
repeater side, because a gateway with a lower duty cycle has more positions to connect to
new terminals. In the complementary matching model, the number of nodes corresponding
to the gateway is the number of remaining positions of the gateway. When these gateway-
side virtual nodes correspond to the same terminal-side node, all edge weights are the same.
For each gateway r,

Then the number of virtual nodes to be added at the terminal is

Let represents the complementary matching model. It is a bipartite graph, and

, is the weighted of , is node v’s label. a node labeling ,

when , ( represents the weight of
edge ), is called a feasible vertex label. If is a feasible vertex label,
, calls an equal subgraph of feasible
vertex label . Kuhn-Munkras has proved that if contains a perfect match , then
is the maximum weight perfect match of G.
1, select one initial vertex label , construct graph . Choose one matching M in ；
2, if all the node in X are covered by M, stop and M is the perfect match. Otherwise, .
3, if ，go to 4；otherwise ，take

where

4, choose a node y from ，if y is covered by M, and , then do

,go to 3；otherwise, choose M’s augmenting path from .
，go to 2. (“ ” represents symmetrical difference).
A matrix is used to represent the result. If the two elements are matched, the corresponding
value in the matrix is one. The rest are zero. After all terminals are matched, the weight of
the matching edge is checked. If it is positive infinity, it means this terminal could not be
recovered.
5 Simulation Results and Discussion
In the power IoT scenario, a LoRa gateway often connects hundreds or even thousands of
terminals. Packet transmission rate varies from one to two hundred packets per day. The
specific number of connections for one LoRa gateway is closely related to the packet
transmission rate. In the electric power IoT environment, supervisors need to quickly sense
the current power environment and make rapid adjustments to the transformation.

Figure 3: Real scene diagram

Fig. 3 above shows the actual scenario in electric power IoT. The red line indicates that the
repeater is connected to the gateway.
Two different scenarios are defined in this paper. In cities, there is a large number of existing
power equipment that can be modified to have repeater functionality to increase the
network’s fault tolerance. This scenario corresponds to the scenario where the repeaters are
denser. In areas with harsher natural conditions, such as wilderness or mountainous areas,
where the original power infrastructure is relatively poor, it is more difficult to add new
dedicated repeater equipment. This situation corresponds to the sparser repeater scenario.

Figure 4: Schematic diagram of repeater distribution with different densities

The first scenario is the sparse situation. In the initial state, all terminals are connected to the
LoRa gateway. When a terminal connection fails, if this terminal is directly connected to the
gateway, first find out whether other LoRa gateways can be connected. If it can be connected,
all channels with an SF value greater than or equal to the current SF will be considered. If they
do not meet the requirements, look for a repeater.
In the sparse repeater model set in this paper, there are two LoRa gateways, six repeaters. All
terminals are evenly distributed in a rectangular area of 16 km 20 km. The period is 3600
seconds/packet, that is, each terminal sends a data packet every hour. The payload is 9.
Fig. 5 shows the link recovery rate in the case of 1000 to 8000 terminals. The upper three
curves in the Fig. 5 are a group, showing the impact of three different recovery strategies on
the link recovery rate when the failure rate is 0.01 (lower). As the number of terminals
increases, the recovery rate gradually decreases. The lower three curves in Fig. 5 are a group,
showing the impact of three different recovery strategies on the link recovery rate when the
failure rate is 0.03 (higher). The LRAKM algorithm has the most obvious advantage when the
terminal scale is 2000 to 7000. When it is less than 2000 terminals, the network load is light.
When it is greater than 7000 terminals, network load is too heavy. Each gateway has reached
the load limit, so the improvement of the algorithm is not ideal.
 Figure 5: Link Recovery Rate in sparse

Figure 6: Energy consumption of each repeater

Fig. 6 shows the proportion of energy consumed by each repeater. LRAKM algorithm has a
significant improvement in load balancing compared to the distance-first algorithm.
In the case of dense repeaters, in the initial state, all terminals are connected to the LoRa
gateway. When a link fails, first find out whether other LoRa gateways can be connected. If it
can be connected, all channels with SF value greater than or equal to the current SF will be
considered (the distance between new gateway and terminal will not be significantly less than
the original). If all SF channels of other gateways do not meet the requirements, the
mechanism will look for a repeater.
In denser repeater model, there are two LoRa gateways and twenty-four repeaters. All
terminals are evenly distributed in a rectangular area of 16 km 20 km. It is set that 1%
(upper three curves in Fig. 7) or 3% (lower three curves in Fig. 7) links fail. The period is 3600
seconds/packet. The payload is 9. Fig. 7 shows the link recovery rate in the case of dense
repeaters. It can be seen that the link recovery rate of the mechanism using the LRAKM
algorithm is higher than that of the other two algorithms. The link recovery rate of all
algorithms is maintained above 90%.
 Figure 7: Link Recovery Rate in dense
This paper studies the scenarios with heavier network load to test whether the mechanism
can be applied to such scenarios. It is set that 1% (the upper three curves in Fig. 8) or 3% (the
lower three curves in Fig. 8) of the link fails, with a period of 1800 seconds/packet, that is,
each node sends a data packet every half hour. The payload is 9.

Figure 8: Link Recovery Rate in dense in heavy load

HARDWARE EQUIPMENT

NodeMCU (ESP8266):
NodeMCU ESP8266 Pinout:

NodeMCU is an open-source Lua based firmware and development board specially targeted
for IoT based Applications. It includes firmware that runs on the ESP8266 Wi-Fi SoC from
Espressif Systems, and hardware which is based on the ESP-12 module.

NodeMCU Development Board Pinout Configuration

Pin Category Name Description
Power Micro-USB, 3.3V, GND, Vin Micro-USB: NodeMCU can
be powered through the
USB port
 3.3V: Regulated 3.3V can be
supplied to this pin to
power the board

GND: Ground pins

Vin: External Power Supply

Control Pins EN, RST The pin and the button
resets the microcontroller
Analog Pin A0 Used to measure analog
voltage in the range of 0-
3.3V
GPIO Pins GPIO1 to GPIO16 NodeMCU has 16 general
purpose input-output pins
on its board
SPI Pins SD1, CMD, SD0, CLK NodeMCU has four pins
available for SPI
communication.
UART Pins TXD0, RXD0, TXD2, RXD2 NodeMCU has two UART
interfaces, UART0 (RXD0 &
TXD0) and UART1 (RXD1 &
TXD1). UART1 is used to
upload the
firmware/program.
I2C Pins NodeMCU has I2C
functionality support but
due to the internal
functionality of these pins,
you have to find which pin is
I2C.
NodeMCU ESP8266 Specifications & Features
• Microcontroller: Tensilica 32-bit RISC CPU Xtensa LX106
• Operating Voltage: 3.3V
• Input Voltage: 7-12V
• Digital I/O Pins (DIO): 16
• Analog Input Pins (ADC): 1
• UARTs: 1
• SPIs: 1
• I2Cs: 1
• Flash Memory: 4 MB
• SRAM: 64 KB
• Clock Speed: 80 MHz
• USB-TTL based on CP2102 is included onboard, Enabling Plug n Play
• PCB Antenna
• Small Sized module to fit smartly inside your IoT projects

Brief data About NodeMCU ESP8266:

The NodeMCU ESP8266 development board comes with the ESP-12E module containing
ESP8266 chip having Tensilica Xtensa 32-bit LX106 RISC microprocessor. This microprocessor
supports RTOS and operates at 80MHz to 160 MHz adjustable clock frequency. NodeMCU has
128 KB RAM and 4MB of Flash memory to store data and programs. Its high processing power
with in-built Wi-Fi / Bluetooth and Deep Sleep Operating features make it ideal for IoT
projects.

NodeMCU can be powered using Micro USB jack and VIN pin (External Supply Pin). It supports
UART, SPI, and I2C interface.

Programming NodeMCU ESP8266 with Arduino IDE:

The NodeMCU Development Board can be easily programmed with Arduino IDE since it is
easy to use.
Programming NodeMCU with the Arduino IDE will hardly take 5-10 minutes. All you need is
the Arduino IDE, a USB cable and the NodeMCU board itself. You can check this Getting
Started Tutorial for NodeMCU to prepare your Arduino IDE for NodeMCU.

Uploading your first program:

Once Arduino IDE is installed on the computer, connect the board with the computer using
the USB cable. Now open the Arduino IDE and choose the correct board by selecting
Tools>Boards>NodeMCU1.0 (ESP-12E Module), and choose the correct Port by selecting
Tools>Port. To get it started with the NodeMCU board and blink the built-in LED, load the
example code by selecting Files>Examples>Basics>Blink. Once the example code is loaded
into your IDE, click on the ‘upload’ button given on the top bar. Once the upload is finished,
you should see the built-in LED of the board blinking.

Applications of NodeMCU
• Prototyping of IoT devices
• Low power battery operated applications
• Network projects
• Projects requiring multiple I/O interfaces with Wi-Fi and Bluetooth functionalities

SX1278 LoRa RF Module

 Lora-SX1278-module

Lora-SX1278-Pinout

Pin Description:

Pin Pin Name Description

Number
1,2,9,16 Ground Ground pin of the Module
3 3.3V Input Supply voltage
4 Reset Resets the Module
5 DIO 0 Digital I/O – 0
6 DIO 1 Digital I/O – 1
7 DIO 2 Digital I/O – 2
 8 DIO 3 Digital I/O – 3
10 DIO 4 Digital I/O – 4
11 DIO 5 Digital I/O – 5
12 SCK SPI – Clock Input
13 MISO SPI – Data Out
14 MOSI SPI – Data In
15 NSS SPI – Chip Select

Features:

• LoRa Modem
• Operating Voltage: 3.3V
• Operating Frequency: 433Mhz
• Half-Duplex SPI communication
• Modulation Technique FSK,GFSK,MSK,GMSK,LoRa
• Packet size: 256 bytes
• Sensitivity: -148db

Setting up LoRa SX1278:

The LoRa SX1278 works with SPI communication protocol so it can be used with any
microcontroller that supports SPI. It is mandatory to use an Ariel (antenna) along with the
module else it might damage the module permanently. The module should be powered only
with 3.3V and the SPI line can be connected to uP/uC as shown in the image below.

To communicate with the module some standard libraries are also available for Arduino like
LoRa by Sandeep and other platforms. The module comes in a surface mount style package
hence care should be taken while soldering. It is also a common practice to solder wires and
pins with the module to use it as through hole module.
Applications:

• IoT Applications
• Home and Building Automation
• Long range communication
• Mesh or star topology networks
• Industrial monitoring and control

DHT11–Temperature and Humidity Sensor

DHT11–Temperature and Humidity Sensor

 DHT11 Sensor Pinout

The DHT11 is a commonly used Temperature and humidity sensor that comes with a
dedicated NTC to measure temperature and an 8-bit microcontroller to output the values of
temperature and humidity as serial data.

DHT11 Pinout Identification and Configuration:

No: Pin Name Description
For DHT11 Sensor
1 Vcc Power supply 3.5V to 5.5V
2 Data Outputs both Temperature
and Humidity through serial
Data
3 NC No Connection and hence
not used
4 Ground Connected to the ground of
the circuit
For DHT11 Sensor module
1 Vcc Power supply 3.5V to 5.5V
2 Data Outputs both Temperature
and Humidity through serial
Data
3 Ground Connected to the ground of
the circuit

DHT11 Specifications:

• Operating Voltage: 3.5V to 5.5V

• Operating current: 0.3mA (measuring) 60uA (standby)
 • Output: Serial data
• Temperature Range: 0°C to 50°C
• Humidity Range: 20% to 90%
• Resolution: Temperature and Humidity both are 16-bit
• Accuracy: ±1°C and ±1%

Difference between DHT11 Sensor and module:

The DHT11 sensor can either be purchased as a sensor or as a module. Either way, the
performance of the sensor is same. The sensor will come as a 4-pin package out of which only
three pins will be used whereas the module will come with three pins as shown above.

The only difference between the sensor and module is that the module will have a filtering
capacitor and pull-up resistor inbuilt, and for the sensor, you have to use them externally if
required.

Where to use DHT11 Sensors:

The DHT11 is a commonly used Temperature and humidity sensor. The sensor comes with a
dedicated NTC to measure temperature and an 8-bit microcontroller to output the values of
temperature and humidity as serial data. The sensor is also factory calibrated and hence easy
to interface with other microcontrollers.

The sensor can measure temperature from 0°C to 50°C and humidity from 20% to 90% with
an accuracy of ±1°C and ±1%. So if you are looking to measure in this range then this sensor
might be the right choice for you.

How to use DHT11 Sensor:

The DHT11 Sensor is factory calibrated and outputs serial data and hence it is highly easy to
set it up. The connection diagram for this sensor is shown below.
As you can see the data pin is connected to an I/O pin of the MCU and a 5K pull-up resistor is
used. This data pin outputs the value of both temperature and humidity as serial data. If you
are trying to interface DHT11 with Arduino then there are ready-made libraries for it which
will give you a quick start.

If you are trying to interface it with some other MCU then the datasheet given below will
come in handy. The output given out by the data pin will be in the order of 8bit humidity
integer data + 8bit the Humidity decimal data +8 bit temperature integer data + 8bit fractional
temperature data +8 bit parity bit. To request the DHT11 module to send these data the I/O
pin has to be momentarily made low and then held high as shown in the timing diagram below

The duration of each host signal is explained in the DHT11 datasheet, with neat steps and
illustrative timing diagrams

Applications:
• Measure temperature and humidity
• Local Weather station
• Automatic climate control
• Environment monitoring
SW-420 Vibration Sensor Module

SW-420 Vibration Sensor Module Pinout

The vibration sensor module based on the vibration sensor SW-420 and Comparator LM393
is used to detect vibrations. The threshold can adjust using an on-board potentiometer.
During no vibration, the sensor provides Logic Low and when the vibration is detected, the
sensor provides Logic High.
Pin Configuration of Vibration Sensor Module
Pin Name Description
VCC
The Vcc pin powers the module, typically
with +5V
GND Power Supply Ground
DO Digital Out Pin for Digital Output.

Vibration Sensor Module Features & Specifications

• Operating Voltage: 3.3V to 5V DC
• Operating Current: 15mA
• Using SW-420 normally closed type vibration sensor
• LEDs indicating output and power
• LM393 based design
• Easy to use with Microcontrollers or even with normal Digital/Analog IC
• With bolt holes for easy installation
• Small, cheap and easily available

Brief about SW-420 Vibration Sensor/Motion Sensor Module

This Vibration Sensor Module consists of an SW-420 Vibration Sensor, resistors, capacitor,
potentiometer, comparator LM393 IC, Power, and status LED in an integrated circuit. It is
useful for a variety of shocks triggering, theft alarm, smart car, an earthquake alarm,
motorcycle alarm, etc.

LM393 IC
LM393 Comparator IC is used as a voltage comparator in this vibration sensor module. Pin 2
of LM393 is connected to Preset (10KΩ Pot) while pin 3 is connected to vibration sensor. The
comparator IC will compare the threshold voltage set using the preset (pin2) and the Vibration
Sensor pin (pin3).
Preset (Trimmer pot)
Using the onboard preset, you can adjust the threshold (sensitivity) of the digital output.

SW-420 Vibration Switch

Vibration switch recognizes the amplitude of the vibration to which it is exposed. The switch
response can be electrical contact closure or contact opening. The electrical contact may be
either an electromechanical relay or a solid-state device.

How to Use SW-420 Vibration Sensor Module

Vibration sensor module consists of three pins i.e. VCC, GND, and DO. The Digital out pin is
connected to the output pin of the LM393 comparator IC. The Internal Circuit diagram of the
Temperature sensor module is given below.

Using the Vibration sensor module with the microcontroller is very easy. Connect the Digital
Output pin of the module to the Digital pin of Microcontroller. Connect VCC and GND pins to
5V and GND pins of Microcontroller.

Applications of Vibration Sensor Module

• Shocks triggering
• Theft alarm
• Smart car
• Earthquake alarm
• Motorcycle alarm

LCD (Liquid Cristal Display):

A liquid crystal display (LCD) is a thin, flat display device made up of any number of color or
monochrome pixels arrayed in front of a light source or reflector. Each pixel consists of a
column of liquid crystal molecules suspended between two transparent electrodes, and two
polarizing filters, the axes of polarity of which are perpendicular to each other. Without the
liquid crystals between them, light passing through one would be blocked by the other. The
liquid crystal twists the polarization of light entering one filter to allow it to pass through the
other.
A program must interact with the outside world using input and output devices that
communicate directly with a human being. One of the most common devices attached to an
controller is an LCD display. Some of the most common LCDs connected to the controllers are
16X1, 16x2 and 20x2 displays. This means 16 characters per line by 1 line 16 characters per
line by 2 lines and 20 characters per line by 2 lines, respectively.

Many microcontroller devices use 'smart LCD' displays to output visual information. LCD
displays designed around LCD NT-C1611 module, are inexpensive, easy to use, and it is even
possible to produce a readout using the 5X7 dots plus cursor of the display. They have a
standard ASCII set of characters and mathematical symbols. For an 8-bit data bus, the display
requires a
+5V supply plus 10 I/O lines (RS RW D7 D6 D5 D4 D3 D2 D1 D0). For a 4-bit data bus it only
requires the supply lines plus 6 extra lines(RS RW D7 D6 D5 D4). When the LCD display is not
enabled, data lines are tri-state and they do not interfere with the operation of the
microcontroller.

Features:
Interface with either 4-bit or 8-bit microprocessor.

Display data RAM

80x8 bits (80 characters).

Character generator ROM

(5). 160 different 57 dot-matrix character patterns. (6).

Character generator RAM

(7) 8 different user programmed 5 7 dot-matrix patterns

(8).Display data RAM and character generator RAM may be Accessed by the microprocessor.

Numerous instructions.

Accessed by the microprocessor.

(9).Numerous instructions

(10).Clear Display, Cursor Home, Display ON/OFF, Cursor ON/OFF, Blink Character, Cursor Shift,
Display Shift.

(11). Built-in reset circuit is triggered at power ON. (12). Built-in oscillator.

Data can be placed at any location on the LCD. For 16×1 LCD, the address locations

are:

Fig : Address locations for a 1x16 line LCD

Even limited to character based modules, there is still a wide variety of shapes and sizes
available. Line lengths of 8,16,20,24,32 and 40 characters are all standard, in one, two and
four line versions.
Several different LC technologies exists. ―supertwist‖ types, for example, offer Improved
contrast and viewing angle over the older ―twisted nematic‖ types. Some modules are
available with back lighting, so so that they can be viewed in dimly-lit conditions. The back
lighting may be either ―electro-luminescent‖, requiring a high voltage inverter circuit, or
simple LED illumination.

ELECTRICAL BLOCK DIAGRAM:

Power supply for lcd driving:

PIN DESCRIPTION:

Most LCDs with 1 controller has 14 Pins and LCDs with 2 controller has 16 Pins
(two pins are extra in both for back-light LED connections).
 Fig: pin diagram of 1x16 lines lcd

CONTROL LINES:
EN: Line is called "Enable." This control line is used to tell the LCD that you are sending it data. To
send data to the LCD, your program should make sure this line is low (0) and then set the other two
control lines and/or put data on the data bus. When the other lines are completely ready, bring EN
high (1) and wait for the minimum amount of time required by the LCD datasheet (this varies from
LCD to LCD), and end by bringing it low (0) again.

RS: Line is the "Register Select" line. When RS is low (0), the data is to be treated as a command or
special instruction (such as clear screen, position cursor, etc.). When RS is high (1), the data being
sent is text data which sould be displayed on the screen. For example, to display the letter "T" on the
screen you would set RS high.
RW: Line is the "Read/Write" control line. When RW is low (0), the information on the data bus is
being written to the LCD. When RW is high (1), the program is effectively querying (or reading) the
LCD. Only one instruction ("Get LCD status") is a read command. All others are write commands, so
RW will almost always be low. Finally, the data bus consists of 4 or 8 lines (depending on the mode
of operation selected by the user). In the case of an 8-bit data bus, the lines are referred to as DB0,
DB1, DB2, DB3, DB4, DB5, DB6, and DB7.

Logic status on control lines:

E - 0 Access to LCD disabled

1 Access to LCD enabled

R/W - 0 Writing data to LCD

1 Reading data from LCD

RS - 0 Instructions

1 Character

Writing data to the LCD:

1. Set R/W bit to low

2. Set RS bit to logic 0 or 1 (instruction or character)

3. Set data to data lines (if it is writing)

4. Set E line to high

5. Set E line to low

Read data from data lines (if it is reading)on LCD:

 6. Set R/W bit to high

7. Set RS bit to logic 0 or 1 (instruction or character)

8. Set data to data lines (if it is writing)

9. Set E line to high

10. Set E line to low

Entering Text:

First, a little tip: it is manually a lot easier to enter characters and commands in hexadecimal
rather than binary (although, of course, you will need to translate commands from binary
couple of sub-miniature hexadecimal rotary switches is a simple matter, although a little bit
into hex so that you know which bits you are setting). Replacing the d.i.l. switch pack with a
of re-wiring is necessary.
The switches must be the type where On = 0, so that when they are turned to the zero
position, all four outputs are shorted to the common pin, and in position ― F all four
outputs are open circuit.

All the available characters that are built into the module are shown in Table 3. Studying the
table, you will see that codes associated with the characters are quoted in binary and
hexadecimal, most significant bits (―left-hand‖ four bits) across the top, and least
significant bits (―right-hand‖ four bits) down the left.
Most of the characters conform to the ASCII standard, although the Japanese and Greek
characters (and a few other things) are obvious exceptions. Since these intelligent modules
were designed in the ―Land of the Rising Sun,‖ it seems only fair that their Katakana
phonetic symbols should also be incorporated. The more extensive Kanji character set,
which the Japanese share with the Chinese, consisting of several thousand different
characters, is not included!
Using the switches, of whatever type, and referring to Table 3, enter a few characters onto
the display, both letters and numbers. The RS switch (S10) must be ―up‖ (logic 1) when
sending the characters, and switch E (S9) must be pressed for each of them. Thus the
operational order is: set RS high, enter character, trigger E, leave RS high, enter another
character, trigger E, and so on.
The first 16 codes in Table 3, 00000000 to 00001111, ($00 to $0F) refer to the CGRAM. This
is the Character Generator RAM (random access memory), which can be used to hold user-
defined graphics characters. This is where these modules really start to show their potential,
offering such capabilities as bar graphs, flashing symbols, even animated characters. Before
the user-defined characters are set up, these codes will just bring up strange looking
symbols.
Initialization by Instructions:
I2C Serial Interface Adapter Module for LCD:
 I2C Serial Interface Adapter Module

I2C Serial Interface Adapter Module Pinout

Due to limited pin resources in a microcontroller/microprocessor, controlling an LCD panel

could be tedious. Serial to Parallel adapters such as the I2C serial interface adapter module
with PCF8574 chip makes the work easy with just two pins. The serial interface adapter can
be connected to a 16x2 LCD and provides two signal output pins (SDA and SCL) which can be
used to communicate with an MCU/MPU.

Features and Specifications of I2C Serial Interface Adapter

Module
This section mentions some of the features and specifications of the I2C Serial Interface
Adapter Module.
11. Operating Voltage: 5V DC
12. I2C control using PCF8574
13. Can have 8 modules on a single I2C bus
 14. I2C Address: 0X20~0X27 (the original address is 0X20, you can change it yourself via the onboard
jumper pins)

Pin Configuration of I2C Serial Interface Adapter Module

The module has multiple pins onboard for communication with the MCU/MPU via the I2C
protocol. The table below shows the pin name, type, and their functions.

Pin Name Pin Type Pin Description

GND Power Ground
VCC Power Voltage Input
SDA I2C Data Serial Data
SCL I2C Clock Serial Clock
A0 Jumper I2C Address Selection 1
A1 Jumper I2C Address Selection 2
A2 Jumper I2C Address Selection 3
Backlight Jumper Control Backlight of panel
Note: The module has an onboard potentiometer to vary the contrast of the display.

Addressing Table of I2C Serial Interface Adapter Module

Up to 8 devices can be connected on a single I2C bus. The address of each can be changed
using the solder points provided on the board(A0, A1, A2). The table below shows how the
address is set using the points A0, A1, A2.

A0 A1 A2 Address
Open Open Open 0x27
Jumper Open Open 0x26
Open Jumper Open 0x25
Jumper Jumper Open 0x24
Open Open Jumper 0x23
Jumper Open Jumper 0x22
Open Jumper Jumper 0x21
 Jumper Jumper Jumper 0x20

Connecting I2C Serial Interface Adapter Module to an

MCU/MPU
The I2C serial adapter can be connected to 16x2 or 20x4 LCD displays via breakout pins. Once
it fits perfectly onto the LCD, we can connect the module to any MCU/MPU using I2C protocol
pins.

The power points VCC and GND can be connected to the 5V and the ground terminal of the
MCU/MPU, respectively. Also, connect the SDA, SCL pins of the module to the MCU/MPU I2C
pins respectively to send the data.

Alternatives for I2C Serial Interface Adapter Module

PCF8574T, MCP23017

Applications of I2C Serial Interface Adapter Module

Here are some of the applications of the I2C Serial Interface Adapter Module.
15. Serial to parallel data adapter
16. Robots
17. LCD Displays

2D Model of I2C Serial Interface Adapter Module

Below is the 2D model of the I2C Serial Interface Adapter Module along with its dimensions
in millimeters. The following information can be used to design custom footprints of the
module for PCB designing and CAD modelling.
 SOFTWARE REQUIREMENTS

Arduino IDE
SOURCE CODE:

#include <SPI.h>
#include <LoRa.h>
#include <LiquidCrystal_I2C.h>
#include <Wire.h> // I2C Library

TwoWire Wire2;

// set the LCD number of columns and rows

int lcdColumns = 16;
int lcdRows = 2;

// set LCD address, number of columns and rows

// if you don't know your display address, run an I2C scanner sketch
LiquidCrystal_I2C lcd(0x27, lcdColumns, lcdRows);

//define the pins used by the transceiver module

#define ss 5
#define rst 16

#define dio0 4
String address= "Lora_3";
void setup() {
Wire.begin(4, 5);
 Wire2.begin(2, 0);

pinMode(15,OUTPUT);

//initialize Serial Monitor

Serial.begin(115200);
while (!Serial);
Serial.println("LoRa Receiver");

// initialize LCD
lcd.begin();
//setup LoRa transceiver module
LoRa.setPins(ss, rst, dio0);

lcd.clear();
lcd.setCursor(3, 0);
lcd.print("Welcome to");
lcd.setCursor(1, 1);
lcd.print("Lora Repeater");

//replace the LoRa.begin(---E-) argument with your location's frequency

//433E6 for Asia
//866E6 for Europe
//915E6 for North America

while (!LoRa.begin(433E6)) {
Serial.print(".");
lcd.clear();
lcd.setCursor(6, 0);

lcd.print("LoRa");
lcd.setCursor(0, 1);
lcd.print("Initializing....");
delay(500);

}
 // Change sync word (0xF3) to match the receiver
// The sync word assures you don't get LoRa messages from other LoRa transceivers
// ranges from 0-0xFF

LoRa.setSyncWord(0xFF);
Serial.println("LoRa Initializing OK!");

delay(5000);

lcd.clear();
lcd.setCursor(6, 0);
lcd.print("LoRa");
lcd.setCursor(2, 1);

lcd.print("Initialized");
delay(5000);
LoRa.onReceive(onReceive);
LoRa.receive();

String LoRaData;

void onReceive(int packetSize){

if (packetSize) {
// received a packet

Serial.print("Received lora-3 packet ");

// read packet
while (LoRa.available()) {

LoRaData = LoRa.readString();
 Serial.println(LoRaData);
}

String status11 = LoRaData.substring(0,LoRaData.indexOf("="));

String h1 = LoRaData.substring(LoRaData.indexOf("=")+1,LoRaData.indexOf("+"));
String t1 = LoRaData.substring(LoRaData.indexOf("+")+1,LoRaData.indexOf("-"));
String inaddress1 = LoRaData.substring(LoRaData.indexOf("-")+1,LoRaData.length());

Serial.println(status11);

if(inaddress1==address){
lcd.clear();

lcd.setCursor(0, 0);
lcd.print("t:");
lcd.setCursor(3, 0);
lcd.print(t1);
lcd.setCursor(9, 0);

lcd.print("h:");
lcd.setCursor(12, 0);
lcd.print(h1);
lcd.setCursor(0, 1);

lcd.print("D:");
lcd.setCursor(3, 1);
lcd.print(status11);

}
 }

void loop() {

LoRa.setSyncWord(0xFF);
//onReceive(LoRa.parsePacket());

LoRa.receive();
delay(2000);
Serial.println("+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++");
int statuss = digitalRead(15);

Serial.println(statuss);
LoRa.setSyncWord(0xF3);
LoRa.beginPacket();
LoRa.print(statuss);

LoRa.print("=");
LoRa.print("nul");
LoRa.print("+");
LoRa.print("null");

LoRa.print("-");
LoRa.print("Lora_1");
LoRa.endPacket();
}

CONCLUSION
LoRa technology is widely used in power IoT due to its advantages such as ultra-long
transmission and large-scale connectivity. When some terminals are unable to communicate
due to link failure, new links need to be planned. If all terminals are connected to their optimal
links, it will cause some gateways to become critical nodes, resulting in uneven network load,
which causes a series of problems and affects the long-term stable operation of the network.
Based on these problems, this paper proposes an adaptive link-level recovery mechanism
from the perspective of fault tolerance. When a link failure occurs, all alternative links are first
searched. These alternative links can be either through repeaters or directly connected to the
gateway. With the KM-based LRAKM algorithm proposed in this paper, the optimal links for
some terminals are adjusted to sub-optimal links while ensuring the communication demand.
From the level of all terminals in the network, this adjustment achieves network load
balancing and improves the link failure recovery rate. Simulation results show that the
mechanism improves the link fault recovery rate and load balancing compared to the
distance-first and idle-first mechanisms in both scenarios where repeaters are sparse or
dense. Further, the mechanism still performs well in larger scale terminal scenario.

References
1. U. Raza, P. Kulkarni and M. Sooriyabandara. (2017). “Low power wide area networks: An overview,”
IEEE Communications Surveys & Tutorials, vol. 19, no. 2, pp. 855–873.

2. Y. Liu, Z. Wang and Q. Peng. (2012). “Design and implementation of remote wireless meter reading
system based on ZigBee and GPRS,” Science Technology & Engineering, vol. 12, no. 30, pp. 8058–8062.

3. L. R. Prando, E. R. de Lima, L. S. de Moraes, M. Biehl Hamerschmidt and G. Fraindenraich. (2019).

“Experimental performance comparison of emerging Low Power Wide Area Networking (LPWAN)
technologies for IoT,” in 2019 IEEE 5th World Forum on Internet of Things (WF-IoTLimerick, Ireland, pp.
905–908.
4. W. Di, C. Ling, G. Lili, W. Yimei and J. Xuesong. (2017). “Application research of ZigBee protocol in CPS
based on multiagent,” in 2017 29th Chinese Control and Decision Conference (CCDCChongqing, China, pp.
6843–6846.

5. D. Heeger, M. Garigan and J. Plusquellic. (2020). “Adaptive data rate techniques for energy
constrained Ad Hoc LoRa networks,” in 2020 Global Internet of Things Summit (GIoTSDublin, Ireland, pp.
1–6.

6. A. Zourmand, A. L. Kun Hing, C. Wai Hung and M. Abdul Rehman. (2019). “Internet of Things (IoT)
using LoRa technology,” in 2019 IEEE International Conference on Automatic Control and Intelligent
Systems (I2CACISSelangor, Malaysia, pp. 324–330.

7. T. Zhuang, M. Ren, X. Gao, M. Dong, W. Huang et al. (2019). , “Insulation condition monitoring in
distribution power grid via IoT-based sensing network,” IEEE Transactions on Power Delivery, vol. 34, no.
4, pp. 1706–1714.

8. C. Liao, G. Zhu, D. Kuwabara, M. Suzuki and H. Morikawa. (2017). “Multi-hop LoRa networks enabled
by concurrent transmission,” IEEE Access, vol. 5, pp. 21430–21446.

9. R. A. Kjellby, L. R. Cenkeramaddi, A. Frøytlog, B. B. Lozano, J. Soumya et al. (2019). , “Long-range &

self-powered IoT devices for agriculture & aquaponics based on multi-hop topology,” in 2019 IEEE 5th
World Forum on Internet of Things (WF-IoTLimerick, Ireland, pp. 545–549.

10. M. S. Aslam, A. Khan, A. Atif, S. A. Hassan, A. Mahmood et al. (2020). , “Exploring Multi-Hop LoRa for
green smart cities,” IEEE Network, vol. 34, no. 2, pp. 225–231.

11. V. A. Dambal, S. Mohadikar, A. Kumbhar and I. Guvenc. (2019). “Improving LoRa signal coverage in
urban and sub-urban environments with UAVs,” in 2019 International Workshop on Antenna Technology
(iWATMiami, USA, pp. 210–213.

12. Y. Hou, Z. Liu and D. Sun. (2020). “A novel MAC protocol exploiting concurrent transmissions for
massive LoRa connectivity,” Journal of Communications and Networks, vol. 22, no. 2, pp. 108–117.

13. P. Rajeev, M. Amy, M. Michele and B. Luca. (2018). “On-demand LoRa: Asynchronous TDMA for
energy efficient and low latency communication in IoT,” Sensors, vol. 18, pp. 3718.

14. G. d. Campo, I. Gomez, G. Cañada and A. Santamaria. (2019). “Hybrid LPWAN communication
architecture for real-time monitoring in power distribution grids,” in 2019 IEEE 5th World Forum on
Internet of Things (WF-IoTLimerick, Ireland, pp. 920–924.

15. M. El-Aasser, A. Gasser, M. Ashour and T. Elshabrawy. (2019). “Performance analysis comparison
between LoRa and frequency hopping-based LPWAN,” in 2019 IEEE Global Conference on Internet of
Things (GCIoTDubai, United Arab Emirates, pp. 1–6.

16. M. Centenaro, L. Vangelista, A. Zanella and M. Zorzi. (2016). “Long-range communications in

unlicensed bands: The rising stars in the IoT and smart city scenarios,” IEEE Wireless Communications, vol.
23, no. 5, pp. 60–67.

17. S. Persia, C. Carciofi and M. Faccioli. (2017). “NB-IoT and LoRa connectivity analysis for M2M/IoT
smart grids applications,” in 2017 AEIT International Annual Conference, Cagliari, pp. 1–6.

18. P. Marco, S. Emiliano, F. Paolo, R. Stefano, D. Alessandro et al. (2020). , “Evaluation of the use of class
B LoRaWAN for the coordination of distributed interface protection systems in smart grids,” Journal of
Sensor and Actuator Networks, vol. 9, no. 1, pp. 13.
19. F. Van den Abeele, J. Haxhibeqiri, I. Moerman and J. Hoebeke. (2017). “Scalability analysis of large-
scale LoRaWAN networks in ns-3,” IEEE Internet of Things Journal, vol. 4, no. 6, pp. 2186–2198.

20. L. Rui, Y. Yang, Z. Gao and X. Qiu. (2019). “Computation offloading in a mobile edge communication
network: A joint transmission delay and energy consumption dynamic awareness mechanism,” IEEE
Internet of Things Journal, vol. 6, no. 6, pp. 10546–10559.

21. M. C. Bor, U. Roedig, T. Voigt and J. M. Alonso. (2016). “Do LoRa low-power wide-area networks
scale?,” in Proceedings of the 19th ACM International Conference on Modeling, Analysis and Simulation
of Wireless and Mobile Systems (MSWiM ’16New York, NY, USA: Association for Computing Machinery,
pp. 59–67.

22. S. Sağır, İ. Kaya, C. Şişman, Y. Baltacı and S. Ünal. (2019). “Evaluation of low-power long distance radio
communication in urban areas: LoRa and impact of spreading factor,” in 2019 Seventh International
Conference on Digital Information Processing and Communications (ICDIPCTrabzon, Turkey, pp. 68–71.