Wireless Gas Sensor Nodes : With focus on Long Range (LoRa) communication

(1)

Linköpings universitet

Linköping University | Department of Electrical Engineering

Bachelor’s thesis, 16 ECTS | Systemteknik

2020 | LIU-ISY/LITH-EX-G--20/0496--SE

Wireless Gas Sensor Nodes

–

With focus on Long Range (LoRa) communication

Amir Ebrahimi, David Kihlberg

Supervisor : Dr. Thanh Duc Nguyen, TEMA Linköpings university Examiner : Dr. Jacob Wikner, ISY Linköpings university

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten ﬁnns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

(3)

Abstract

Greenhouse gas emissions in indoor or outdoor areas are dangerous and can have short- or long-term effects on people’s health. There are several methods to monitor the air quality in such environments. This thesis project attempts to design and evaluate a wireless sensor network with two main characteristics such as long range and low power consumption. The sensor network is built upon Long Range Wide Area Network (Lo-RaWAN) protocol and is composed of sensor nodes and gateways. The sensor nodes are built upon a Raspberry Pi model 3B, a LoRa SX1276 transceiver and gas sensors. The sen-sors are intended to measure CO2, CH4, temperature, pressure and relative humidity. The

collected data is then logged and sent to The Things Network (TTN) via a backhaul con-nection.

(4)

Acknowledgments

The work for this bachelor thesis started the same time as the COVID-19 pandemic in Swe-den. This affected the work with changed routines at the university and less contact with all the involved. But during this hard time this work had not been able to succeed without all the help from the people around us.

We would like to thank our examiner Dr. Jacob Wikner and our supervisor Dr. Thanh Duc Nguyen for all the help and valuable inputs during this work. The project is funded by Prof. David Bastviken so we would like to thank you for making this project possible. We would also like to thank our families and friends for all the support and always be-lieving in us.

Amir and David Linköping, 2020

(5)

List of Figures

1.1 Three scenarios where the system can be implemented . . . 4 2.1 Modulated LoRa symbols with different SF. SF7 and SF12 have the shortest and

the longest airtime respectively [chirp_spread_spectrum] . . . . 7 2.2 Illustration of a LoRa packet is shown. A LoRa packet is either in explicit or

im-plicit mode. The only difference is the header in exim-plicit mode which contains information about the actual payload. . . 8 2.3 Illustration of all the gains and losses from the transmitter, through the medium

to the receiver [LinkMargin] . . . . 9 2.4 I2C communication between four device slaves and one master device. All device

slaves are parallel connected to the serial data (SDA) and the serial clock (SCL) on the master device . . . 11 2.5 Illustration of I2C communication. The start command is generated by the master

device and then a 7-bit address of the specific device slave (B6-B0) generates. Bit R/W is set to high or low depending on operation. The address confirms with the ACK bit and the data is transmitted or received (D7-D0) [I2C] . . . . 12 2.6 Master puts its data on Master Output Slave Input (MOSI) and receives data on

Master Input Slave Output (MISO) from slave [SPI] . . . . 12 2.7 Illustration of UART communication between two devices is shown. UART does

not require a clock signal instead a start and stop bit is used [UART] . . . . 13 2.8 A LoRa hat compatible with the Raspberry Pi has been used to build a gateway.

The module supports 868 MHz frequency band and has built-in GPS . . . 14 2.9 The IoT LoRa Node pHAT is a simple module to work with if using a Raspberry

Pi. The pHAT uses UART interface and a RAK811 chip . . . 15 2.10 Raspberry Pi model 3 B. In order to setup the Raspberry Pi, a monitor, keyboard

and mouse are needed. The Monitor can be connected through the HDMI port and the mouse and keyboard connect via the USB ports. . . 15 2.11 GPS module from Adafruit with UART interface. The module is based on the

MTK3339 chip and has a sensitivity receiver of about -165 dBm. . . 16 2.12 An 8-channel Analog-digital converter with a 12-bit resolution . . . 17 2.13 TGS 2611-E00 is an analog methane gas sensor that measures voltage differences

and with the help of temperature and humidity, the gas concentration can be cal-culated . . . 18 2.14 Temperature and humidity sensor called AM2320 . . . 18 2.15 The BMP388 is a barometric pressure sensor with the ability to measure

tempera-ture, altitude and pressure . . . 19 2.16 K33 ELG is a gas sensor with the possibility to measure temperture, relative

hu-midity and carbon dioxide . . . 20 3.1 Device overview at The Things Network with information of the device such as

secret keys, activation method and status . . . 23 3.2 Device EUI generated in the terminal . . . 24

(8)

3.3 Configuration file to modify with secret keys from TTN when using activation

method ABP . . . 24

3.4 Parts of python code for temperature and humidity sensor (AM2320). Every mea-surement is added together during 30 seconds and then an average value is calcu-lated for both parameters and then printed . . . 25

3.5 Python code to read from port A0 on the ADC. The result is printed every other second . . . 25

3.6 Python code for CO2sensor using UART . . . 26

3.7 Configure section . . . 27

3.8 Register a gateway at TTN . . . 28

3.9 Gateway overview . . . 28

3.10 Decoding and simulation at TTN website . . . 29

4.1 Block diagram with specified communication interfaces. The AM2320, BMP388 and the ADC uses I2C communication. The GPS and the LoRa module uses UART interface and because of pin conflicts an software UART is implemented. . . 33

4.2 Text-file to log data. The figure illustrates how it looks like when data are stored from startup and with a log interval of around every third minute . . . 33

4.3 Log file 3 hours after start where the restart function can be verified at line 62 . . . 34

4.4 Datalogging in csv-file . . . 34

4.5 Test performed in Ryd with a distance of 652.97 meters between the sensor node and the gateway . . . 35

4.6 The first 8 packages delivered to TTN without any data loss . . . 36

4.7 Decoded payload at TTN. For each received package at the TTN website the pay-load and the decoded data can be seen . . . 36

4.8 During test 1 some data loss occurred according to the frame counter. As seen the frame counter goes from 38 to 43 which means that 4 packages were lost . . . 37

4.9 60 messages successfully delivered to TTN . . . 37

4.10 Distance between the end-device and the gateway in test 3. The test were pre-formed in urban environment in central Linköping . . . 38

7.1 Circuit diagram of the sensors and the GPS module . . . 48

7.2 Configuration tool for the Raspberry Pi . . . 58

7.3 Access setup section for I2C . . . 59

7.4 Enable I2C . . . 59

7.5 The I2_{C is now enabled and can be confirmed by pressing "Ok" . . . .} ₆₀

7.6 Reboot raspberry Pi . . . 60

7.7 Access setup section for serial communication . . . 61

7.8 Disable serial login shell . . . 61

7.9 Enable serial port hardware . . . 62

7.10 The serial interface is now enabled and can be confirmed by pressing "Ok" . . . 62

7.11 Create application at TTN . . . 64

7.12 Application overview . . . 64

7.13 Register a device at TTN . . . 65

7.14 Device overview . . . 65

7.15 Access key to authorize storage function . . . 66

7.16 Integration overview . . . 66

7.17 Authorization, use the access key in the field "Key" . . . 66

7.18 Sensor node with component names . . . 68

(9)

List of Tables

2.1 Pin assignment for the temperature and humidity sensor AM2320 . . . 19 2.2 Pin assignment for the barometric pressure sensor BMP388 . . . 19 3.1 Bill of material to build one sensor node. At the time of writing this paper the cost

for each component was as above. . . 22 3.2 Description of command sent to K33 ELG when using UART interface [k33_uart] . 26

(10)

Nomenclature

ABP Activation By Personalisation ADC Analog Digital Converter

BW Bandwidth

CR Coding Rate

CRC Cyclic Redundancy Check CSS Chirp Spread Spectrum FEC Forward Error Correction FSK Frequency Shift Keying I2C Inter-Integrated Circuit IoT Internet of Things IP Internet Protocol

ISM Industrial Scientific and Medical

LKM Link Margin

LoRa Long Range

LoRaWAN Long Range Wide Area Network LPWAN Low Power Wide Area Network

OS Operative System

OTAA Over The Air Activation

(11)

LIST OF TABLES

SCL Serial Clock

SDA Serial Data

SDG Sustainable Development Goals

SF Spreading Factor

SPI Serial Peripheral Interface

SS Slave Select

TTN The Things Network

U ART Universal Asynchronous Receiver Transmitter WSN Wireless Sensor Networks

(12)

1 Introduction

1.1 Motivation

In 2015 the General Assembly consist of all the member states of the United Nation have adopted an agreement called Sustainable Development Goals (SDG). The agreement is com-posed of 17 goals to achieve with the aim of sustainable development for people and the planet by year 2030 [1]. The goal number 13 focuses on climate changes and address that as one of the biggest challenges on the planet that need urgent action. One way to fight the climate changes is to detect and measure pollutants in urban and rural environments and in order to do that, several platforms and solutions have been developed through the years. For the last couple of years, Internet of Things (IoT) together with Long Range communication (LoRa) have been an interesting subject and gained a lot of attention. However, many devel-opers and engineers have utilised this technology to build Wireless Sensor Networks (WSN) in order to monitor various gasses in various range of indoor or outdoor applications. In this paper, a low-cost and low-powered gas monitoring system will be developed and evaluated. The system will be composed of sensors, processing unit, power supply and wireless com-munication which all together will constitute a sensor node. The sensor node will then be installed in a remote location, sensing pollutants and other parameters such as temperature and relative humidity. Eventually the data will be logged and sent to a server station via radio communication for further analysis.

1.2 Aim

The aim of this thesis is to implement a low-power, long range wireless gas sensor nodes exploiting LoRaWAN protocol. The nodes or end-devices will be composed of a LoRa mod-ule, a processing unit, a battey and sensors with the ability of measuring carbon dioxide, methane, temperature, relative humidity and pressure. The measured data will then be sent to The Things Network (TTN) via the LoRaWAN networks.

(13)

1.3. Research questions

1. The first case is when the system is mounted on a carrier in motion, e.g. a train. The data will then be transmitted to the base station via a GSM network or WIFI. The reason why LoRaWAN is not an option in this case is because of the distances that will appear.You can not be sure that a gateway is in range for the module and this will create data loss. To avoid it, it is more reasonable to for example connect the node to the WIFI on the train and upload the data to the cloud.

2. The second case is based on surrounding a gas emission. This is done by placing the nodes on different rods around the emission and perform measurements and then send the data to TTN via LoRaWAN for further analyses. The sensor node should be pow-ered by a battery and solar panels.

3. The third and final case is a floating sensor node on the water surface, e.g. a lake. The sensors should in this case be powered by a battery and solar panels. The principle of sending data should be the same as in scenario 2.

As mentioned before all scenarios should take measurements of temperature, relative humid-ity, pressure, methane and carbon dioxide. To know where the data comes from and when measurements were taken, time and location should be generated. Time is needed when storing data to be able to find the right information if data loss occurs.

Figure 1.1: Three scenarios where the system can be implemented

1.3 Research questions

The research questions that will be studied and evaluated are formulated as:

1. Is it possible to build a wireless sensor networking using LoRa communication? 2. How does distance affect data transmission?

1.4 Delimitations

Because of the time limit, the main focus will be to develop a system adapted for case 2 described in section 1.2. The code implementation will be done with the aid of the code sources available on the internet or the sources offered by manufacturer. Hence no library will be written from scratch. During this project a Raspberry Pi model 3 B will be used as the

(14)

1.4. Delimitations

processing unit and some comparisons between this single board computer and two different microcontrollers are presented in chapter 3.

(15)

2 Theory

2.1 Introduction

This chapter will include the theoretical background of the project and description of the whole system. The hardware that has been used will also be presented.

2.2 LoRa

Although in many cases the LoRaWAN (Low-Power, Wide-Area Networks) is abbreviated as LoRa (Long Range), the two are technically different. LoRa is the physical layer (PHY) that sitting in the bottom of the OSI model and is used for creating communication links. The main characteristic properties of LoRa are its capability to cover huge areas while consuming low power. This property gives developers and costumers an advantage to provide reliable data communication in e.g. their IoT applications. According to [2] the range of LoRa devices can exceed to hundreds of kilometres in urban environments. But it is worth mentioning that the range extremely depends on the obstacles and interference in these locations. On the other hand, a disadvantage of LoRa networks is the low data rate typically a few kilo bytes per second.

2.2.1 Chirp Spread Spectrum

Unlike the earlier radio systems that utilize frequency-shift keying (FSK) modulation, LoRa deploys chirp spread spectrum (CSS) modulation to create the links. In digital communica-tion CSS is a modulacommunica-tion technique that encodes informacommunica-tion into chirps or symbols which its frequency changes linearly with time [3]. The amount of data or bitrate that carriers by each symbol varies depend on a vital parameter called spreading factor (SF). LoRa utilizes an SF between 7 and up to 12, meaning e.g. 7 bits can be transmitted by each symbol with a spreading factor of 7. As it illustrates in figure 2.1 the CSS technique utilises an entire allo-cated spectrum to transmit data. Each chirp sweeps between highest and lowest frequency and due to the low-power and long transmission distances that can be accomplished by CSS, it has only been utilized in military and space applications for years but LoRa is the first low-cost application for consumer use [4].

(16)

2.2. LoRa

Figure 2.1: Modulated LoRa symbols with different SF. SF7 and SF12 have the shortest and the longest airtime respectively [5]

2.2.2 Spreading Factor

The range and performance of a LoRa modulation depends on multiple parameters including spreading factor (SF). SF defines the number of bits that can be encoded by a symbol and can take values between 7-12. SF has a direct influence on the transmission time, meaning an increment by one bit will result in twice the airtime. On the other hand, the longer time a transmission takes, the better the reception will be on the receiver side [6]. Consequently, higher SF will reduce the data rate and battery life.

2.2.3 Bandwidth

Depending on the region, LoRa employs three different bandwidths such as 125, 250 and 500 KHz. A bandwidth is a channel where chirps sweep between highest and lowest frequencies. A higher channel bandwidth contributes faster symbol rate but as a matter of fact it will be more sensitive to noise. The duration of the symbols is determined by the bandwidth according to

TS = 2 SF

BW (2.1)

(17)

2.2. LoRa

2.2.4 Coding Rate

In order to achieve a more reliable data transmission, Semtech have implemented a data cor-rection technique called forward error corcor-rection (FEC). In such coding scheme, redundant bits will be added to the transmission which helps to recover data at reception. The propor-tion of the non-redundant bits and redundant ones is called coding rate (CR) and is defined by

CR= 4

4+n (2.2)

where n= (1, 2, 3, 4)[4]

For instance, a data transmission with SF = 8 and CR = 4/8 means, twice the number of the actual bits that contain information, will be transmitted.

2.2.5 LoRa Packet Format

The structure of each packet sent by a physical LoRa device incorporates both essential and nonessential elements. There are two packet modes, explicit and implicit mode, figure 2.2 illustrates the structure of both packets. Regardless the packet mode, a message is always started with a preamble which contains of a variable length of upchirps followed by two downchirps at the end of the preamble. The preamble also accounts for synchronization between the receiver and the incoming message. Next is the header and is only used in explicit mode. It contains payload size, coding rate (CR) and if exists a 2-byte long cyclic redundancy check (CRC) that is used to detect errors. On the other hand, the implicit header mode uses no settable parameters but fixed values, thus the transmission time is reduced [7]. The two last fields are payload and CRC. Payload is the actual variable transmitted data and CRC provides information about whether it is an uplink or a downlink. Uplink is the process when an end-device transmits data to the gateway and downlink is the opposite direction.

Figure 2.2: Illustration of a LoRa packet is shown. A LoRa packet is either in explicit or implicit mode. The only difference is the header in explicit mode which contains information about the actual payload.

2.2.6 Link Budget and Link Margin

In radio frequency (RF), path loss (PL) will occur when a high frequency radio signal prop-agates from the transmitter to the receiver. The cause of the PL may be due to many factors such as reflection of the signal on the ground, line of sight and the height of the antennas. In such a network, link budget is given by sum of all the gains and losses and it defines the maximum losses that a wireless link can tolerate but still maintains a functional communi-cation [8]. As it is shown in figure 2.3, the green lines are the gains and the red lines are the losses.

(18)

de-2.3. LoRaWAN

signing a wireless system. LKM is defined as the difference between received power (Rx power) at the receiver’s side and the receiver’s sensitivity (Rx sens)

LKM(dB) =Rx power(dBm)´Rx sens(dBm) (2.3) The minimum allowed LKM at least needs to be equal to the receiver’s sensitivity.

Figure 2.3: Illustration of all the gains and losses from the transmitter, through the medium to the receiver [9]

2.3 LoRaWAN

LoRaWAN (Long Range Wide Area Network) or LPWAN (Low Power Wide Area Network) developed by LoRa Alliance is a communication protocol that is utilized in many wireless applications such as IoT devices. The protocol uses an open and free radio spectrum called industrial, scientific and medical (ISM) band and is known for its low power consumption which means that the data can be transmitted over long distances with a minimal current draw. This ability is an essential factor in the manner of lifetime in battery powered devices such as wireless sensor nodes. In a LoRaWAN network the building blocks are composed of end nodes, gateways, network servers and costumer applications. In such a network the data transmission procedure is done by collecting, transmitting and interpreting. The end nodes collect and transmit data to the gateways which act as communication bridges between end devices and network servers. When the data packets arrive, the gateways interpret them to IP packets for further transmitting to the server networks and customer applications via high bandwidth networks such as Ethernet, 4G and WiFi.

The LoRaWAN protocol employs several frequencies in the ISM bands but the most common ones that have been used in the protocol are 433 MHz, 868 MHz and 915 MHz. Countries have their own regulations and specifications when it comes to the ISM bands, hence the frequencies vary in each country.

(19)

2.4. Range

2.3.1 Classes

As it mentioned earlier, LoRaWAN’s main characteristics are low power and wide area net-working that can be used to connect remote and battery-powered devices to each other. Lo-RaWAN also supports bidirectional communications and offers three types of communica-tion depend on the applicacommunica-tions, limitacommunica-tions and requirements.

• Class A: is the default class in LoRaWAN and is the class that consumes lowest power. Here, an end-device can initiate a transmission regardless time. Each uplink is followed by two short downlink widows and it provides the opportunity for bi-directional com-munication. This class is suitable for battery-powered applications which allows the end-device to enter low-power mode for whatever length of time that is characterized by the application [10].

• Class B: class B end-devices are time scheduled meaning downlinks will be done at scheduled times. Class B is slightly more power consuming than class A, but it is still suitable for battery-operated usage.

• Class C: unlike the class A that opens the receive slots whenever an uplink arrives, the receiver side is open all the time in class C, meaning a server can transmit a downlink at any time. No latency is the main advantage of the class C but in exchange the power consumption is the most compared with class A.

LoRaWAN communication is based on class A while class B and C are developed from class A. Therefor all end devices must support class A communication.

2.4 Range

Two vital parameters that characterize LoRa and LoRaWAN are power consumption and range. When it comes to the range, it may arise some differences between the theoretical and the practical performance of a LoRa device. According to Semtech, the SX1276 chip has the capability of reaching a range greater than 15 km, but it is not specified if such a capability refers to urban or rural areas. In [11], a range measurement has been done in the city of Paris, France. The results show that with SF 7 and 9, no packets could be received and only with SF 12 could 40% of data be received at the receiver’s side in a distance of 3.4 km.

2.5 The Things Network

The Things Network (TTN) is a community that allows people to build their own data net-work with long range and in a cost effective way. The data netnet-work can connect to internet using LoRaWAN [12]. On the TTN website you can connect your LoRa device and see the received data. TTN also gives the possibility to connect your own gateway which has been done in this project and will be presented in section 2.10. When the gateway is connected to TTN you can monitor when data is going through, and see some information for example device address, airtime, signal-noise ratio, and signal strength.

2.6 Over-the-air activation and Activation by personalisation

On the TTN website it is possible to choose between two activation methods, Over-The-Air Activation (OTAA) or Activation By Personalisation (ABP).

In OTAA a device is given a DevEUI, an AppEUI and an Appkey. The AppKey gener-ates two session keys, NwkSKey and AppSKey. To activate, the node sends a join request

(20)

2.7. Inter-Integrated Circuit

and uses the response to derive the session keys. The keys are saved and used to communi-cate and if they are deleted the device needs to reconnect to generate new session keys. In ABP the device does not need a DevEUI, an AppEUI and an Appkey. Into the device the session keys NewkSKey and AppSKey are preprogramed and preregistered on the net-work. The session keys are used for the communication, so this activation method does not need any join procedure.

To find out which activation method that fits the best it depends on the product require-ments. Both methods can be as secure and efficient as the other in the right use, but it is easier with the OTAA to achieve higher security because of the join procedure. On the other hand, ABP is better during the development when more control over the activated device is important. During this project OTAA will be used for the final product and ABP during the develop stage [13].

2.7 Inter-Integrated Circuit

Inter-Integrated Circuit (I2C), is a two wire serial protocol used to connect different devices such as microcontrollers, analog-digital converters and sensors. Each slave device has their own unique address and the I2C bus is supported by 7-bit and 10-bit addresses. This means that up to 1024 I2C devices can be connected at the same time. In figure 2.4 the I2C connec-tion is shown where the device slaves are connected to a master device. The device slaves symbolise different sensor and the master device is the processing unit. Data transfers to and from the master device via serial communication with 8-bit packets.

Figure 2.4: I2C communication between four device slaves and one master device. All device slaves are parallel connected to the serial data (SDA) and the serial clock (SCL) on the master device

In normal state both the serial data (SDA) and the serial clock (SCL) are high and the com-munication starts by the master device. In figure 2.5, I2C protocol is presented. The master device generates a start command followed by a 7-bit address of the device slave X (B6-B0). R/W is representing read or write operation which means that if the bit is low, the master device writes to the device and read from device if the bit is high. The ACK bit is the ac-knowledge signal that verify that the address matches any device address. After this the data transmitting or receiving can starts (D7-D0) and verifies. When the data transmitting or receiving is done the master device generates a stop command.

(21)

2.8. Serial Peripheral Interface

Figure 2.5: Illustration of I2C communication. The start command is generated by the master device and then a 7-bit address of the specific device slave (B6-B0) generates. Bit R/W is set to high or low depending on operation. The address confirms with the ACK bit and the data is transmitted or received (D7-D0) [14]

2.8 Serial Peripheral Interface

Serial Peripheral Interface (SPI) is a synchronous data bus used for data communication be-tween two or more devices, master and slave(s). As it is depicted in figure 2.6, SPI uses a clock signal to synchronise the data transmission between the master and the slave. In this way the slave device will receive or transmit data whenever the clock signal changes its state. SPI protocol also gives the opportunity to connect multiple slaves to a single master by se-lecting each slave whenever it is needed. It can be done by connecting Slave Select (SS) of the master device to SS-pin of each Slave devices. The SS line is active low meaning it needs to be low before each transmission.

Figure 2.6: Master puts its data on Master Output Slave Input (MOSI) and receives data on Master Input Slave Output (MISO) from slave [15]

(22)

2.9. Universal Asynchronous Receiver Transmitter

2.9 Universal Asynchronous Receiver Transmitter

Unlike SPI or I2_{C that are communication protocols, Universal Asynchronous Receiver} Trans-mitter (UART) is a dedicated physical hardware in a microcontroller. As the name implies, the data communication in UART is asynchronously i.e. no clock line is needed between the transmitter and the receiver. Instead, the data communication is done via two lines, Tx and Rx like it is shown in figure 2.7. The device that wants to transmit, needs to provide its data on the Tx-pin which needs to be connected to the Rx-pin on the device that receives data. Each transmission initialises with a start-bit which is done by pulling the data line low and then high. After that, the receiver starts to reading the actual data. In order to tell the receiver that the transmission is done, a stop-bit needs to be sent. It is done by pulling the data line from low to high.

Figure 2.7: Illustration of UART communication between two devices is shown. UART does not require a clock signal instead a start and stop bit is used [16]

2.10 Gateway

A gateway acts as a transparent bridge between end-devices and TTN. Usually the gateway uses high bandwidth communication such as WiFi or 4G to connect to TTN. The devices use LoRaWAN to connect to the gateways which is equipped with LoRa concentrator to receive LoRa packets. Thousands of devices can be handled by one single gateway. When the mes-sage is received by the gateway it delivers to TTN [12].

2.11 Hardware

This section contains theoretical description about the hardware that have been used during this project.

2.11.1 Dragino LoRa/GPS HAT (SX1276)

During the project there were some problems with the connection between the devices and TTN. This problem only occurred at the University which forced the group to build their own gateway so the communication to TTN could be tested. For this task the Dragino LoRa/GPS HAT v1.4 from Seeed Studio were used [17]. This module is compatible with the Raspberry pi and it is based on SX1276 transceiver. The transceiver contains LoRa, long range modem which supply ultra-long range spread spectrum communication and high interference im-munity while reducing the current consumption.

(23)

2.11. Hardware

Figure 2.8: A LoRa hat compatible with the Raspberry Pi has been used to build a gateway. The module supports 868 MHz frequency band and has built-in GPS

2.11.2 IoT LoRa Node pHAT

Since the introducing of the LoRaWAN technology many manufacturers have developed and produced low-cost and high-efficient LoRa modules. Depend on applications, developers and costumers have a wide range of choices. Some devices are mounted on a PCB and come with different connectors which increase the flexibility and ease of the usage while other mod-ules are just a raw unit that needs to be integrated into a circuit. But the working principle of all the LoRa devices is the same, data transmission with low power consumption. LoRa Node pHAT from Pi Supply is a low-cost hat that utilises the RAK811 module [18]. The hat offers a simple installation and communicates with Raspberry Pi through the UART proto-col. RAK811 is based on SX1276 chip from Semtech and supports the 868 MHz ISM band for Europe.

(24)

2.11. Hardware

Figure 2.9: The IoT LoRa Node pHAT is a simple module to work with if using a Raspberry Pi. The pHAT uses UART interface and a RAK811 chip

2.11.3 Raspberry Pi model 3 B

For the processing unit in the system, a Raspberry Pi Model 3B has been used [19]. The Pi has been deployed both in the LoRa motes and as a host computer in the gateway. Raspberry Pi is a pocket size single board computer (SBC) with different intergrated components and interfaces such as WiFi, Bluetooth, HDMI output and USB ports. It also has a 40-pin header that enables to connect sensors and modules. In order to be able to use the hardware on the Pi, different operative systems (OS) have been developed. The OS that has been used in this project is Rasbian Buster which offers all the necessary software and programs needed for the project.

Figure 2.10: Raspberry Pi model 3 B. In order to setup the Raspberry Pi, a monitor, keyboard and mouse are needed. The Monitor can be connected through the HDMI port and the mouse and keyboard connect via the USB ports.

(25)

2.11. Hardware

2.11.3.1 Power consumption

One of the goals by this project is to implement a system with as low power consumption as possible. Compared to other microcontrollers and SBCs, the Raspberry Pi has a high power consumption around 1.22 W in idle state. This is a problem in a long term perspective for systems like this. To increase the lifetime, it is essential to reduce the energy consumption and there are a few things that can be done to achieve this.

According to [20] it is possible to reduce the power consumption by disable HDMI port, disconnect Ethernet and down clock the CPU. With disconnected Ethernet and disabled HDMI the energy consumption reduces around 20.5%, from 1.22 W to around 0.97 W. This will affect the lifetime in a positive manner. It is also possible to down clocking the CPU because the system probably does not need full CPU capacity. This can be hard to obtain since the frequency must sync the system to not crash.

Another way to reduced the power consumption is to disable WIFI, bluetooth, USB ports and on-board LEDs [21]. All these functions are not of use for this project.

2.11.4 GPS module

The Ultimate GPS is a high-quality module from Adafruit that can track up to 22 satellites on 66 channels [22]. The GPS has a built-in antenna and the possibility to connect an external antenna via a u.FL connector. Every second it can do 10 location updates with high sensitivity and the power usage during navigation is around 20 mA. There is also a led that blinks to show the status on the fix. The led is blinking in 1 Hz which means around every second and that indicates for no fix. If the led is blinking once every 15 seconds, there is a fix which means that satellites are found, and calculation of the position can start. The module also has a real time clock (RTC) with a coin cell that can be soldered on the backside.

In figure 2.11 the Ultimate GPS module is shown, it communicates via UART which is a protocol to transmit (Tx) and receive (Rx) serial data. For the flexibility the module has a built in voltage regulator that regulates the input voltage at VIN (3.3-5V) to 3.3V and gives a clean output voltage if needed. The enable pin (EN) can be used to turn of the GPS module by pulling the pin to ground.

Figure 2.11: GPS module from Adafruit with UART interface. The module is based on the MTK3339 chip and has a sensitivity receiver of about -165 dBm.

(26)

2.11. Hardware

2.11.5 Analog-Digital Converter

Almost all sensor networks have a mix of analog and digital sensors and in those cases an analog-digital converter (ADC) is often needed to communicate with the microcontroller. In figure 2.12 an 8-channel ADC from Seeed Studio is depicted [23]. It is compatible with the Raspberry Pi and has a 12-bit resolution. The resolutions show what kind of values that can be represented and in this case, where the resolution is n=12, it is possible to present a number up to 4096, as

2n =212=4096 (2.4)

This module uses I2C to transfer the converted data to the Raspberry Pi. There are three different kind of input ports on the ADC; screw terminals, female pin headers and grove analog ports. These connections make the module flexible and suitable for many kinds of sensors.

Figure 2.12: An 8-channel Analog-digital converter with a 12-bit resolution

2.11.6 Sensors

In this section the sensors that have been used and recommended from the supervisor will be described.

2.11.6.1 TGS 2611-E00

The TGS 2611-E00 is an analog sensor (figure 2.13) that is dependent of temperature and humidity. To convert the result to methane gas, measurements of VRL, temperature and hu-midity need to be done and then some interpretations of the result. This sensor is developed with a built-in filter which helps to get rid of the influence of interference gases, for example alcohol [24].

(27)

2.11. Hardware

Figure 2.13: TGS 2611-E00 is an analog methane gas sensor that measures voltage differences and with the help of temperature and humidity, the gas concentration can be calculated

2.11.6.2 AM2320

The AM2320 is a digital temperature and humidity sensor using I2C interface. The temper-ature range is between –40 and 80 °C with ±0.5 °C accuracy [25]. The humidity range are around 0 to 99.9 % with a deviation of ±3% in the condition of 25 °C. In figure 2.14 the sensor is shown where the pin assignment is presented in table 2.1.

(28)

2.11. Hardware

Pin Name Description 1 VDD 3.3-5V power supply

2 SDA serial data

3 GND Ground

4 SCL Serial clock

Table 2.1: Pin assignment for the temperature and humidity sensor AM2320

2.11.6.3 BMP388

The BMP388 module is a barometric pressure sensor from Adafruit with the possibility to use either I2_{C or SPI interface [26]. This sensor offers the ability to measure pressure, temperature} and altitude with high accuracy. The sensor is shown in figure 2.15 and the pin assignment in table 2.2.

Figure 2.15: The BMP388 is a barometric pressure sensor with the ability to measure temper-ature, altitude and pressure

Pin Description VIN 3-5V power supply

3V0 3.3 V output

GND Ground

SCK Serial clock SDO Serial data out

SDI Serial data in CS Chip select pin INT Interrupt pin

Table 2.2: Pin assignment for the barometric pressure sensor BMP388

To communicate via SPI pin SCK, SDO, SDI and CS are used where SDO is the data sent from sensor to the microcontroller and SDI is the data in the opposite direction. Pin CS is used

(29)

2.11. Hardware

Like the GPS module described in section 2.11.4 this sensor has the same function with a voltage regulator and generates an output voltage of 3.3V.

2.11.6.4 K33 ELG

Senseair K33 ELG is a gas sensor with the ability of measuring CO2concentration, tempera-ture and relative humidity [27]. The sensor can measure CO2concentration up to 5000 ppm with an accuracy of ±30 ppm. Furthermore, the sensor communicates through either I2C or UART which both have been used during this project. A brief explanation can be found in section 3.2.3.

Figure 2.16: K33 ELG is a gas sensor with the possibility to measure temperture, relative humidity and carbon dioxide

(30)

3 Method

This chapter will contain information of how the work has been organized and imple-mented. The project required both theoretical and practical knowledge about radio frequency networks, modules, sensors and programming. The work was divided into three stages; prestudy, implementation and verification.

3.1 Prestudy

This first step of the project was to find information of related work to get more knowledge and understanding about the whole project. In order to understand the idea of LoRa and LoRaWAN, different studies in terms of reading articles and web sources were done. Such studies helped to increase the understanding of how the work could be performed and what kind of results the group could expect. Studies about the hardware part of the thesis were also done. In order to find parts that were best suited, a range of different components and modules from various manufacturer were looked at. The most important properties here were compatibility, ease of implementation in terms of code and available libraries and prices. As a starting point into the hardware comparison, three processing units were studied, Ar-duino Mega 2560, ArAr-duino Due and Raspberry Pi Model 3B. The aim of this was to find a microcontroller or microprocessor that can offer reliability, flexibility and high efficiency. All these three devices have been used in similar projects before and are popular choices in the areas of interest. Their simplicity, high flexibility, rich interface and low cost make them great candidates for the project but since the sensor nodes are battery powered, it is considerable to maximize the battery life. Even though all the candidates offer same primary functionalities such as fast speed or great peripherals, but some have greater advantages than the others. For instance, Arduino Mega 2560 employs an 8-bit microcontroller while Arduino Due utilizes a 32-bit chip with higher performance. Both are low cost microcontrollers based on fast and powerful chips that could be a possible option for the brain of the system. But since the development of IoT is going forward everyday, we wanted to use an even more powerful device that is capable of heavy operations like signal processing. Therefor we looked at the

(31)

3.2. Implementation

1.3 GHz. The high-power computing ability of Pi 3 B makes it suitable in IoT and monitoring applications with heavy duty calculations or in sensor nodes that require signal processing. Likewise, The Raspberry Pi contains various interfaces to communicate with external de-vices. It comes with built-in WIFI, Bluetooth, USB ports and Ethernet port.

An important matter of fact that needs to be considered is the power consumption of Rasp-berry Pi. This device has typically higher power consumption compared with other platforms like Arduino boards. But in fact, there are several solutions to reduce its power consumption, especially in remote control applications with limited battery life [20].

Despite the high power consumption, the Raspberry Pi is a flexible single board com-puter that enables users and system developers to build their own monitoring systems. Due to its customizable, it also leaves rooms for future developments.

In table 3.1 the components that have been used for this project is listed, containing name, a short description and price. These components are used to build one sensor node and does not include modules for a gateway. For the gateway one extra Raspberry Pi is needed and a LoRa/GPS pHAT (354 SEK).

Name Description Price[SEK]

Raspberry Pi model B Microprocessor 354.61

32 GB microSDHC Storage 79

8-Channel 12-Bit ADC Analog-Digital converter 90.30

LoRa Node pHAT LoRa module 286

Stackthrough connector To extend the contacts 42.08 Ultimate GPS Breakout Position and time 380.47

CR1220 Battery for GPS 21.71

AM2320 Temperature and humidity sensor 37.60 BMP388 Temperature and pressure sensor 94.80

TGS 2611-E00 Methane sensor Unknown

K33 ELG Carbon dioxide sensor Unknown

Table 3.1: Bill of material to build one sensor node. At the time of writing this paper the cost for each component was as above.

This project also included some programming to read sensor measurements, datalogging, send it to TTN and translate the data on TTN website which means that some study about Python, C++ and JavaScript were done.

3.2 Implementation

To implement the sensor node, all parts were tested separately to gather knowledge and understand how every part worked before putting everything together.

3.2.1 Getting started with Raspberry Pi

The first step was to download the operative system Rasbian from [28]. Then the OS was flashed onto an SD-card and inserted into the Pi. After booting the Pi, some configurations such as setting up the network, updating the OS were done. Since the sensors and modules utilised different communication protocols and the corresponding ports were deactivated by

(32)

3.2. Implementation

default on the Pi, an activation was necessary. To enter the configuration tool the following command were typed in the terminal:

1 $ sudo raspi-config

Then the corresponding ports were activated in the interfacing options menu. A more de-tailed description of the setup can be found in Appendix A 7.7.

3.2.2 LoRa device registration on TTN

As previously stated, the module is compatible with the Raspberry Pi which made the con-nection very simple. It was done by simply mount the LoRa module on top of the Pi. A very important step to do, was to desoldering one of the inductors that controls the antenna mode. The inductor marked INT was desoldered since it activates the internal antenna of the device. Instead an external antenna with higher gain was connected to the u.fl connector. To connect the LoRa module to TTN, a device was registered on the TTN website where all the necessary keys were received. Figure 3.1 shows the fields that contain all the necessary keys to make the activation possible. A brief explanation of these parameters can be found in section 2.6. The library RAK811 [29] was downloaded to configure the LoRa module and communicate with TTN. The library included some example code for activation with both OTAA and ABP which were used to send simple data as a starting point for the LoRa communication.

Figure 3.1: Device overview at The Things Network with information of the device such as secret keys, activation method and status

To receive the Device EUI and get a working communication, the following commands were executed in the terminal.

1 $ rak811 hard-reset

2 $ rak811 get-config dev_eui

Eight bytes appeared in the terminal. These bytes were then copied to the field Device EUI on TTN (figure 3.2).

(33)

3.2. Implementation

Figure 3.2: Device EUI generated in the terminal

To receive data at TTN the code had to be modified with the generated keys which is shown in figure 3.3.

Figure 3.3: Configuration file to modify with secret keys from TTN when using activation method ABP

3.2.3 Sensors

Because of no experience in the programming language Python every sensor was tested sep-arately to make the code as compact and simple as possible. The majority of the sensors used the I2C protocol and had their own unique address which made the connection to the Rasp-berry Pi simple. By create a parallel connection interface between all sensors and connect it to the SDA and SCL pins on the Pi no conflict occurred. In figure 3.4 a simple code example for the AM2320 sensor is shown. For this sensor the library adafruit-am2320 were used to calculate and get the right result. The code is creating an I2C shared bus which allows the Raspberry Pi to find the sensor at the specific address. The command am.temperature and am.relative-humidity means that the Pi reads the sensor data from the given I2C bus and then return the result. The AM2320 and BMP388 sensor used I2_{C interface and were tested in a} similar way except different libraries.

(34)

3.2. Implementation

Figure 3.4: Parts of python code for temperature and humidity sensor (AM2320). Every mea-surement is added together during 30 seconds and then an average value is calculated for both parameters and then printed

The methane sensor (2.11.6.1) is an analog sensor which means that the ADC had to be im-plemented. To implement the ADC a library [30] were needed and some setup to activate the right port. In this case the terminal block port A0 were used. In figure 3.5 a simple code example is shown. The argument adc.read_voltage(0) activates port A0 on the terminal block and reads the measured value and then print the result.

Figure 3.5: Python code to read from port A0 on the ADC. The result is printed every other second

During the implementation of the carbon dioxide sensor (2.11.6.4) problems occurred with both I2C and UART interface. This will be discussed further in the chapter 6. In figure 3.6

(35)

3.2. Implementation

readable value the high bytes is left shifted and added together with the low byte. Code for I2C communication is found in Appendix A 7.5.

Figure 3.6: Python code for CO2sensor using UART

To read the correct data from the sensor which in this case is the CO2value, a command had to be sent to the sensor.

1 ser.write(b’\xFE\x04\x00\x03\x00\x01\xD5\xC5’)

Byte Description

xFE Sensor address

x04 Register to read

x0003 Start address

x0001 Quantity of registers

xD5C5 Cyclic Redundancy Check (CRC) calculated to the register

Table 3.2: Description of command sent to K33 ELG when using UART interface [31]

After each sensor were tested and worked as planned, it was time to implement the main code and put it all together. The main code is shown in Appendix A 7.2.

3.2.4 Gateway

The gateway that has been used during this project were constructed with a Raspberry Pi and a Lora/GPS phat from Dragino. It is a single channel gateway and to build it some steps had to be done which is presented below:

1. Connect the Raspberry Pi to internet and enable SPI 2. To be sure that the SPI is enabled, reboot the Raspberry Pi

1 $ sudo reboot

3. Run the following command to install the GPIO access library

(36)

3.2. Implementation

4. Download the single channel source code from GitHub [32] and edit main.cpp in section Configure these values.

Figure 3.7: Configure section

5. Connect the LoRa/GPS pHAT and the Raspberry Pi 6. Runing the following command to get the gateway ID

1 $ sudo ./single_chan_pkt_fwd

7. Register a gateway on the TTN website and use the gateway ID as the gateway EUI. Also specify the exact location and if it is indoor or outdoor.

(37)

3.2. Implementation

Figure 3.8: Register a gateway at TTN

8. When the registration is done it should look like figure 3.9 where the status shows connected and last seen should update frequently.

Figure 3.9: Gateway overview

As mentioned before this is a single channel gateway which is very limited compared to a dual channel gateway. A single channel can only receive at one channel and one spreading factor at the same time which can result in data loss.

3.2.5 Software UART

The Raspberry Pi Model 3B had two serial ports but only one was accessible via the GPIOs and since more than one device used serial communication, it was necessary to find a so-lution. A possible solution could be using USB-serial adapters but considering keeping the costs as low as possible, purchasing extra hardware was not an option. To overcome this problem, a software UART port had been created which enabled us to define any two GPIO pins as Rx and Tx. The software was written by Adriano Marto and was downloaded from [33].

3.2.6 Decoding data for better user interface

When the data arrives to the TTN website the formats of the payloads are in bytes and needs to be converted to readable messages. For this task a decoder and some error management were implemented in JavaScript on the website. On the website there is a section called Decoding where it is implemented which is shown in figure 3.10. It is also possible to simulate the code by manually generate a payload. In order to convert the payload, the high byte is

(38)

3.2. Implementation

shifted eight steps and added together with the low byte. In this way the bytes are translated into integers.

Figure 3.10: Decoding and simulation at TTN website

One thing to be aware of is that this decoder only works if the data is packed in a specific order, otherwise the decoder will generate wrong heading for each value. The full code is shown in Appendix A 7.6.

3.2.7 Power Consumption

One critical part about the Raspberry Pi is the high power consumption compared to the Arduino boards. As mentioned before in section 2.11.3.1 there are a few things that can be modified to reduce the power consumption. The different approaches are stated below [21].

• Switch off USB/LAN IC:

To turn off and on USB chip run the following command in the terminal during startup.

Turn off: $ echo ’1-1’ |sudo tee /sys/bus/usb/drivers/usb/unbind Turn on: $ echo ’1-1’ | sudo tee /sys/bus/usb/drivers/usb/bind • Turn off HDMI:

For the final product when it is placed outside the HDMI port will not be used and probably SSH will be used instead. This means that the HDMI port can be disabled which is done by the following command in the terminal.

Turn OFF HDMI output: $ sudo /opt/vc/bin/tvservice -o Turn ON HDMI output: $ sudo /opt/vc/bin/tvservice -p

It is also possible to turn off the HDMI port in the /boot/config.txt file by adding the following line.

(39)

3.3. Verification

By changing some parameters in the /boot/config.txt file the core can then be down clocked. Below some example values is presented but these values need to be experi-mented with to match the specific system.

arm_ f req_min=250 core_ f req_min=100 sdram_ f req_min=150

over_voltage_min=0 • Disable WIFI:

The WIFI function is not used for the sensor node which means that it can be disabled. Add the line below in the /boot/config.txt file.

dtoverlay= pi3 ´ disable ´ wi f i • Disable Bluetooth:

Also the bluetooth function were not a use for the sensor node so it was disabled in the /boot/config.txt file.

dtoverlay= pi3 ´ disable ´ bt • Disable on-board LEDs:

By disabling the on-board LEDs the power consumption will not reduce to much but in a long perspective it will affect the system. Edit the /boot/config.txt file with the following lines.

dtparam=act_led_trigger=none dtparam=act_led_activelow=on • Turn off GPS module

The GPS module for this project only uses once every third hour. The GPS time is synchronized with the Raspberry Pi and the location is stored. This means that the GPS is turn on all the time without doing anything. To reduce the current draw the module is turned off directly after use. Meaning that it is on until a fix is achieved and then turned off.

To turn off the GPS module the enable pin is used described in section 2.11.4. By pulling the pin to ground with a 10 kΩ resistor the module turns off. By doing this the current drawing is reduced significantly and the lifetime of the system will increase. After each modification reboot the Raspberry Pi to make sure that every command takes effect.

3.3 Verification

To verify that each module worked as planned they were tested separately as mentioned before. This simplified the process to a finished system and the understanding of the different parts of the project. Different trials were performed with various range between the sensor node and the gateway. This to clarify when data loss occurred and what kind of range the LoRa module could handle.

(40)

3.3. Verification

To make sure that measurements like temperature and humidity were correct and rea-sonable, comparisons were made with local weather report and other kind of applications that measured these values.

(41)

4 Results

The intention of this chapter is to present the performance of the prototype regarding data logging, range and data loss.

4.1 Sensor node

The functionality of the system is listed below. • Measurement of analog and digital sensors • Track GPS location and time

• Sync time with RPi to be able to turn off the GPS

• Take average value of each measurement over 30 seconds • Pack the data into byte-package

• Send data via LoRa communication (around every third minute) • Log data in a csv-file

• Restarts the main code every third hour to update location and time • Reboot function if LoRa module sends 5 messages without any GPS fix

In figure 4.1 the communication interfaces are specified for the sensor node. Because of only one UART connection on the GPIO pins the GPS uses a software UART to prevent conflicts between devices. The CO2sensor is not implemented in the system but code for both UART and I2C are presented in Appendix A 7.4 respective 7.5

(42)

4.2. Datalogging

Figure 4.1: Block diagram with specified communication interfaces. The AM2320, BMP388 and the ADC uses I2C communication. The GPS and the LoRa module uses UART interface and because of pin conflicts an software UART is implemented.

4.2 Datalogging

The data is logged after each transmission. Figure 4.2 shows the result of the logged data from the startup that is marked with a timestamp at 12:22:02. The first data package matches the data that has been received att TTN, figure 4.7.

Figure 4.2: Text-file to log data. The figure illustrates how it looks like when data are stored from startup and with a log interval of around every third minute

As mentioned before the system restarts after three hours to update the GPS location and the timestamp. This is shown in figure 4.3 where the restart function appears at line 62, just before the timestamp 15:22:25. The program started at 12:22:02 (figure 4.2) which means that the restart happened three hours after startup as expected. It is also shown in the figure that the GPS has been updated with a small difference of the location.

(43)

4.3. Result TTN

Figure 4.3: Log file 3 hours after start where the restart function can be verified at line 62

At the end of the project some changes were done regarding datalogging. To make the system as simple as possible and log the data in a better way a csv-file was used. In figure 4.4 an example with datalogging in a csv-file is shown.

Figure 4.4: Datalogging in csv-file

This change resulted in a better and simpler format to read from. This were done to make it easier for the people on the field to find the lost data.

On the TTN website it is also possible to store the received data for seven days. How to enable this function is described in the setup instructions in Appendix A 7.7.

4.3 Result TTN

This section present the results during different trails with various range between gateway and sensor node.

(44)

4.3. Result TTN

4.3.1 Test 1, distance test in open-air with SF7

Test 1 was performed in Ryd, Linköping at a distance of around 650 meters from the gateway shown in figure 4.5. The test were done with the method ABP and a setup using SF7. This test showed a result of no data loss in the beginning which can be seen in figure 4.6.

Figure 4.5: Test performed in Ryd with a distance of 652.97 meters between the sensor node and the gateway

(45)

4.3. Result TTN

Figure 4.6: The first 8 packages delivered to TTN without any data loss

The decoding part is shown in figure 4.7 which corresponds to the first message in figure 4.6. The decoded data matched the saved data at line 2 in figure 4.2 which verified that the decoder worked. As seen in figure 4.7 the decoder returns "co2 [ppm]": "Error!", this is because the sensor node does not send any carbon dioxide value. The decoder at TTN on the other hand is implemented to be able to extend the system with the carbon dioxide sensor in future work.

Figure 4.7: Decoded payload at TTN. For each received package at the TTN website the pay-load and the decoded data can be seen

After around 2 hours some data loss occurred shown in figure 4.8. Four packages in a row were lost during the transmission but saved in the log file.

(46)

4.3. Result TTN

Figure 4.8: During test 1 some data loss occurred according to the frame counter. As seen the frame counter goes from 38 to 43 which means that 4 packages were lost

4.3.2 Test 2, distance test in open-air with SF12

Test second test were performed in the same way as test 1 except with change in the setup from SF7 to SF12. This gave the result of no data loss in 60 transmissions. In figure 4.9 some of the last packages are seen.

Figure 4.9: 60 messages successfully delivered to TTN

4.3.3 Test 3, distance test in central city with SF12

The third test was performed in central Linköping with a distance of around 1.5 km between the end-device and the gateway. The test were executed in urban environment. The LoRa packages were first received when the SF was set to 12. Lower SF resulted in no received payloads.

(47)

4.3. Result TTN

Figure 4.10: Distance between the end-device and the gateway in test 3. The test were pre-formed in urban environment in central Linköping

During this test similar packages in terms of size and duration were sent to a gateway 1.5 km away. This test resulted in only 22 received packages out of 60 which corresponds to 64 percent data loss.

(48)

5 Discussion

The purpose of this chapter is to discuss the following sections; result, method and the work in a wider context.

5.1 Results

The evaluation of the results can be divided into three parts; the sensors, LoRaWAN and the power consumption of the node.

For the sensor part, the results ended up pretty much as we expected. Most of the sen-sors work correctly and the measurements seem to be acceptable. The only issue that we have faced with the sensor part was the integration of the carbon dioxide sensor. The sensor functions fine as a stand-alone device but when it connects with the other sensors, it does not respond to the commands sent by the master device. We have spent a good amount of time to debug and troubleshoot the problem but unfortunately, we have not been able to address the issue. We have even tried to contact the manufacturer for further information, but they did not respond to any of our attempts.

There are a few things that can be improved and could have been done differently when it comes to the implementation of the radio communication. The nodes are programmed in such a way that they send packets every third minute which seems to be unnecessary since the temperature, carbon dioxide and methane do not change so often in the air. Instead the measurements can be sent with longer interval between each transmission e.g. every third hour. In this way the power consumption of the LoRa device and the power consumption of the node in general will be less. One more thing that is not taken into consideration is the impact of Signal to Noise Ratio (SNR) and the Received Signal Strength Indicators (RSSI) of received packets. Recording and analysing these parameters could have helped us to understand and even optimise the nodes better.

(49)

5.2. Method

Designing a more battery friendly system requires more time and research since the power efficiency is a complicated and advanced subject.

5.2 Method

The methods used in this project could have been done differently. First, the components should have been studied closer so that the additional issues such as compatibility, flexibility and pin conflicts could be avoided. Two problems that we have faced when the components arrived were the pin conflicts and short pin headers of the LoRa-devices. The later was solved by ordering additional extension pin headers but the negative side of that was the extra cost which could be avoided if the LoRa devices were studied more carefully. The problem regarding UART conflict could also be bypassed if we could find a GPS module with other interfaces like I2C. But luckily, we have managed to overcome the problem by using a software defined UART port.

Another factor that affect the project was the ongoing circumstances due to the COVID19-pandemic in the world. The initial idea was to improve an existing monitoring system with LoRa communication but since the start of the pandemic, the group had to change the plans and instead developed a new monitoring system.

5.3 The Work in a Wider Context

For the last century the greenhouse gases have increased significantly and became a threat for humans and animals health. By performing more measurements and analysing the origin of the gases, we will get better understanding about the negative effects. With more knowl-edge the possibility to make changes increases which is exactly what the planet needs. But there are a lot of negative ethical aspects with electronic and the equipment that needs for measurements like this.

One example could be lithium batteries that are often used to power systems like this. Lithium batteries contains cobalt which is a metal that mainly comes from Democratic Re-public of Congo where the work around cobalt often violates human rights. According to [34] children with the age of only seven years old works in life-threatening conditions with no safety gear. This results in severe pulmonary diseases and deaths because of the dust and collapsed tunnels.

The production of electronic is a factor that affects the climate in a negative way. For example, manufacturing one single mobile phone corresponds to the same amount of emissions as 460 km driving [35]. Another problem with products containing electronic components is the waste when electronic stops working. It is important to take care of the electronic waste in a proper way and if not, it affects the environment in a bad way.

(50)

6 Conclusion

This chapter will contain discussion of the purpose, the research questions and improvement ideas for future work.

6.1 Aim and problems

During the project a sensor node and a gateway were built. The main aim for this project was to implement a low-power, long range wireless gas sensor nodes using LoRaWAN protocol. Except for the power consumption part everything is fulfilled. According to the project requirement the system should be able to take measurements of carbon dioxide, methane, temperature, relative humidity and pressure. Because of problems during the implementation of the CO2sensor the system can not measure carbon dioxide. This because of pin conflicts between the LoRa module and the sensor when using UART interface. When using I2_{C communication the response from the sensor was very slow. This made it hard to} implement the sensor in the system and make it work with the other modules. With UART the sensor response were fast and reliable compared to the I2C interface. Code for both UART and I2C use are done but not implemented. This is discussed in section 6.3.

Right now it is hard to say how good the system is, it needs more testing for longer time periods. Because the tests that were performed during this project were around three hours which means that it is impossible to say how the system will react if it is running for example in three days.

Because of time limit trials about power consumption were not done and one of the goals was to reduce it. How to reduce the power consumption is therefor specified in section 3.2.7 but not implemented in the project.

Wireless Gas Sensor Nodes : With focus on Long Range (LoRa) communication

Linköping University | Department of Electrical Engineering

Bachelor’s thesis, 16 ECTS | Systemteknik

2020 | LIU-ISY/LITH-EX-G--20/0496--SE

Wireless Gas Sensor Nodes

With focus on Long Range (LoRa) communication

Amir Ebrahimi, David Kihlberg

Upphovsrätt

Copyright

Acknowledgments

Contents

List of Figures

List of Tables

Nomenclature

1

Introduction

1.1

Motivation

1.2

Aim

1.3

Research questions

1.4

Delimitations

2

Theory

2.1

Introduction

2.2

LoRa

2.2.1

Chirp Spread Spectrum

2.2.2

Spreading Factor

2.2.3

Bandwidth

2.2.4

Coding Rate

2.2.5

LoRa Packet Format

2.2.6

Link Budget and Link Margin

2.3

LoRaWAN

2.3.1

Classes

2.4

Range

2.5

The Things Network

2.6

Over-the-air activation and Activation by personalisation

2.7

Inter-Integrated Circuit

2.8

Serial Peripheral Interface

2.9

Universal Asynchronous Receiver Transmitter

2.10

Gateway

2.11

Hardware

2.11.1

Dragino LoRa/GPS HAT (SX1276)

2.11.2

IoT LoRa Node pHAT

2.11.3

Raspberry Pi model 3 B

2.11.4

GPS module

2.11.5

Analog-Digital Converter

2.11.6

Sensors

3

Method

3.1

Prestudy

3.2

Implementation