• No results found

Development and design of a prototype for monitoring the water level in water wells using LoRaWAN

N/A
N/A
Protected

Academic year: 2021

Share "Development and design of a prototype for monitoring the water level in water wells using LoRaWAN"

Copied!
59
0
0

Loading.... (view fulltext now)

Full text

(1)

Faculty of Technology and Society

Bachelor’s thesis 15 credits, ground level

Development and design of a prototype for monitoring the

water level in water wells using LoRaWAN

Utveckling och konstruktion av en prototyp för övervakning av vattennivån i vattenbrunnar med hjälp av LoRaWAN

Alshekhly, Zoubida

Dalkic, Yurdaer

Exam: Bachelor of Science in Engineering Area: Computer Engineering

Program: Data & Mobil IT

Date of final seminar: (2018-05-30)

Supervisor: Jevinger, Åse Examiner: Emruli, Blerim

(2)

Abstract

A flood may occur anytime and anywhere in the world. A flood starts when the water level increases, especially, in the wells in the urban areas. By taking advantage of the modern technology, such as Internet of Things (IoT), the losses caused by the flood can be reduced. Therefore, an IoT-solution is needed for monitoring the water level in the wells.

The aim of this thesis is to investigate how to design and implement an IoT-based system that monitors the water level to build a prototype using LoRaWAN technology. Building the prototype is done by following the steps of an iterative system development method. The prototype uses a Lora public network, specifically The Things Network (TTN). The functions of the prototype are measuring the water level by an ultrasound sensor, sending the measurement data through LoRa to TTN, and visualizing the data on the "Cayenne" dashboard in real-time. The system is tested in a lab environment. The results of the constructed prototype show that the prototype measures the water level and sends the measurement data whenever the state of the water level is changed. Additionally, the data is visualized on the Cayenne dashboard.

(3)

Sammanfattning

En översvämning kan inträffa när som helst och var som helst i världen. En översvämning börjar när vattennivån ökar, särskilt i dagvattenbrunnar i stadsområden. Genom att ut-nyttja de olika moderna teknologier som Internet of Things (IoT), förluster som orsakas av en översvämning kan minskas. Därför behövs en IoT-lösning för att övervaka vattennivån i brunnarna.

Syftet med denna avhandling är att undersöka hur man konstruerar och implementerar ett IoT-baserat system som övervakar vattennivån för att bygga en prototyp med LoRaWAN teknologi. Konstruktionen av prototypen utförs genom att följa stegen i en iterativ syste-mutvecklingsmetod. Prototypen använder ett offentligt Lora-nätverk, särskilt The Things Network (TTN). Prototypens funktioner är att mäta vattennivån med en ultraljudssen-sor, sända mätdata via LoRa till TTN och visualisera data på en visualiserings plattform "Cayenne" i realtid. Systemet är testad i en laboratoriemiljö. Resultaten av den kon-struerade prototypen visar att den mäter vattennivån och skickar mätdata när vattennivåns tillstånd ändras. Dessutom visualiseras datan på visualiserings plattformen Cayenne.

(4)

Acknowledgments

We would like to express our gratitude to our supervisor Åse Jevinger for guiding us throughout the thesis where she was very helpful. We would also thank our teacher Magnus Krampell for comments, inputs and feedback throughout the thesis. Lastly, we would like to thank Adam Gray for language support.

(5)

Glossary

Internet of Things(IoT): IoT refers to anything that can possibly be connected to the internet. The things that can be connected to the internet can be anything from a sensor for heartbeat monitoring to a wide range of devices like cell phones, washing machines, home automation, wearable devices, automotives etc.

Machine-to-machine(M2M): Machine-to-machine, or M2M, refers to technology that allows and supports communication between machines and devices through both wireless and wired systems. It represents one aspect of the so-called Internet of Things.

European Telecommunications Standards Institute (ETSI) :An independent, not-for-profit, standardization organization in the telecommunications industry in Europe.

(6)
(7)

Contents

1 Introduction 1 1.1 Background . . . 1 1.2 Research purpose . . . 2 1.3 Research questions . . . 3 1.4 Thesis limitations . . . 3 1.5 Requirement specification . . . 3 2 Theoretical Background 4 2.1 Ultrasonic distance measurement . . . 4

2.1.1 Distance calculating . . . 4

2.1.2 Impact of environment factors . . . 5

2.1.3 Ultrasonic sensors . . . 6

2.2 Low Power wide Area Network (LPWAN) . . . 7

2.2.1 LoRa . . . 7

2.2.2 LoRaWAN . . . 8

2.2.2.1 Device Classes . . . 8

2.2.2.2 Network topology and capacity . . . 9

2.2.2.3 Security . . . 10

2.2.2.4 LoRaWAN for Europe . . . 12

2.3 The Things Network(TTN) . . . 12

3 Related Work 14 3.1 Early flood alerts using Short Message Service (SMS) . . . 14

3.2 A flood warning system to critical region . . . 14

3.3 Design and development of a flood warning system via mobile and computer network . . . 15

3.4 On the application of IoT: Monitoring of troughs water level using WSN . . 16

4 Method 17 4.1 Method Description . . . 17

4.1.1 Construct a conceptual framework . . . 18

4.1.2 Develop a system architecture . . . 18

4.1.3 Analyze and design the system . . . 18

4.1.4 Build the system . . . 18

4.1.5 Observe and evaluate the system . . . 20

4.1.5.1 Test for water level measurement . . . 20

4.1.5.2 Test for LoRaWan Network . . . 20

4.1.5.3 Test for visualization of data . . . 20

4.1.5.4 System evaluation . . . 20

5 Results 21 5.1 Construct a conceptual framework . . . 21

5.1.1 Problem breakdown . . . 22

5.1.2 Literature study . . . 24

5.2 Develop a system architecture . . . 26

5.2.1 System functions . . . 26

5.2.2 The logical view of the system . . . 26

(8)

5.3.1 Measurement technique . . . 27

5.3.2 Hardware . . . 27

5.3.3 Real-time data visualization platform . . . 29

5.3.4 Software . . . 30

5.4 Build the system . . . 32

5.4.1 System overview . . . 33

5.4.2 Current consumption . . . 34

5.5 Observe and evaluate the system . . . 35

5.5.1 Test for water level measurement . . . 35

5.5.2 Communication test . . . 35

5.5.3 Test for visualization of data . . . 36

5.6 Analysis of the results . . . 36

5.6.1 Accuracy of water level measurements . . . 36

5.6.2 Current consumption . . . 37

5.6.3 Communcation . . . 37

6 Discussion 38 6.1 Iteration ability in the method . . . 38

6.2 Discussion of results . . . 38

6.3 Relation to previous studies . . . 39

7 Conclusions and future work 40 7.1 Answering the research questions . . . 40

(9)

1

Introduction

This chapter presents the background of the problem area, the research purpose, research questions and the research limitations, followed by the requirement specifications of the system.

1.1 Background

Climate change may cause destructive effects. An example of these effects are disasters caused by floods that have become increasingly common today [1]. The impacts of floods may lead to deaths, destroyed infrastructures, destroyed environment, and destroyed prop-erty. A solution that informs the stakeholders is necessary to limit the losses when a flood occurs [2]. One of the reasons that possibly leads to flooding is a torrential rain. The occurrence of the torrential rain has been increasing. Furthermore, the torrential rain is hard to predict, for instance it is difficult to know when the rains may occur in comparison to typhoon. In this way, floods would be destructive [3]. The most well-known floods caused by torrential rain are:

• India, 1979, where 7,000-10,000 people died. • Sudan, 1988 with unknown number of deaths. • U.S. Midwest, 1993, which resulted in 55 deaths.

• England, 2007 with the results of destroyed houses and buildings. • Turkey, 2009 with 37 dead people [4].

The impact of floods in Sweden have so far not been extreme, and the destruction is limited into the economic frame. Since the 16th century, Sweden has experienced several floods which caused devastation to buildings and infrastructure [5].

Many counties in Sweden may become affected by heavy rain under one-day duration [6], e.g. Skåne county. Malmö city in Skåne was affected by a flood during the year 2014 because of a heavy rain that lasted 24 hours as shown in figure 1 below.

(10)

Before that, Malmö had not experienced an extremely heavy rain since 1962. In addition, Malmö had a record amount of precipitation within an hour of 31.6 mm, and a record within fifteen minutes of 17.6 mm between 08:30 and 08:45 o’clock at a Sunday morning in 2014 [7], as shown in figure 2.

Figure 2: Fifteen minutes precipitation for Malmö on Sunday 31 August 2014 [7]. According to weather forecast, several torrential rains may affect Malmö city in the future [8]. The experience that the city has acquired by the previous flood in 2014 shows that cooperation with other organizations has been successful in solving the problems caused by the flood. However, there were obvious lacks that caused a large number of materialistic losses [10]. Some of the lacks that Malmö city had when the flood took place were; all the concerned departments did not receive a warning when the water increased to a certain level, the Rescue Service did not receive an alarm from SMHI 1 to take the necessary

actions, besides, the public transport did not receive enough information about the affected areas. The costs because of the losses to Malmö city were up to 100 million Swedish kronor [10]. The losses could be reduced if the city had control over the water level in the wells [11].

Malmö City municipality is interested in smart city solutions that use LoRa wireless com-munication technology which can be used today for IoT-based smart city applications. Therefore, Malmö City is starting to install the LoRaWAN gateways in Malmö. The gate-ways are supposed to cover the whole city within one year. Since water systems have the main role in precipitation throughout the city, it is important to have control over the wa-ter level in the wells by using a LoRaWAN-based system. The contribution of this thesis is based on the information provided by Malmö City municipality, to build an IoT-based solution with LoRaWAN that monitors the water level in the wells [11].

1.2 Research purpose

The purpose of this thesis is, to investigate how to design and implement a system that measures the water level and visualize water level information in the wells to build a pro-totype that using LoRaWAN technology. In this way, the correct actions can be taken in time to avoid the losses of floods. The system performance occurs under various environ-mental impacts, such as high/low temperature, humidity, high water level and the build

(11)

up of salt/sand in the wells. Additionally, reducing energy consumption in the system is important to avoid changing the power source often. The system communicates through the communication technology LoRa. Visualizing the measurement results, on a platform, is for displaying the data about the water level in different parts of a city. The platform connects to the LoRaWAN public network to view the data in real-time.

1.3 Research questions

RQ1.

• How can a LoRaWAN-based system that measures the water level in the wells and visualizes water level information be designed and implemented?

RQ1.1

• Which sensor types for water level measurement are able to handle the environmental impacts that the water wells are exposed to?

RQ1.2

• How can the energy consumption be reduced for the prototype? RQ1.3

• How can a LoRa public network be used for visualization of the water level informa-tion on a platform/dashboard?

1.4 Thesis limitations

The thesis limitations are measuring the water level only in the water wells which have a maximum depth of five meters. The sensor used, in this case, need to be waterproof and resistant to the different weather conditions as mentioned earlier in the research purpose. The requested network is LoRaWAN, which has recently been implemented in Malmö. The information sent from the network for water level measurements should be displayed by using a platform/dashboard to show the water level. The LoRa public network should be The Things Network(TTN). TTN is building a network for the Internet of Things based on LoRaWAN technology.

1.5 Requirement specification

The system requirements are provided by Malmö City multiplicity [11] for specifying the problems of the system and they are presented below:

1. The prototype should measure the water level in the wells.

2. The prototype should withstands different weather conditions. The operating tem-perature should be at least -20◦C..+30C. The prototype should be waterproof.

3. The prototype should be connected to a LoRa network for sending the measurement data to the visualization platform.

4. The prototype should provide information about water level on a visualization plat-form.

5. The battery of the prototype should have a long lifetime (at least one year) to avoid changing it frequently.

(12)

2

Theoretical Background

This chapter aims to describe the theoretical background in some related areas to ease understanding the thesis.

2.1 Ultrasonic distance measurement

Ultrasonic measurement technology was first used by submarines for sonar depth gauging and marine detection. In 1949 this technology was applied for level measurement. Regard-less of the type of the application, all industries have similar expectations from a distance measurement technique: measuring level accurately, consistently, and cost-effectively. Ul-trasonic level measurement has been the selected solution since 1970, because it covers all these expectations. Today ultrasonic sensors are commonly used for a wide variety, e.g. non-contact presence, motion detection, proximity, or distance measuring applications.

Figure 3: Application areas for ultrasonic level measurement technology [12] The sound is the main part of the ultrasonic distance measurement technology. The sound is interpretation of electrical signals, which are derived from the acoustic pressure waves. The source of the sound signals is a mechanical vibration of an object. Sound waves require a medium to propagate. If there is no gas or liquid as in the vacuum, then there will be no propagation of sound. Thus, an application that operates in the vacuum may not use ultrasonic measurement technology for level measurement [12].

2.1.1 Distance calculating

The sound is used as a measurement tool, because there is a measurable time difference between the sound generation and the received bounced echo. The theoretical principle of ultrasonic level measurement is straightforward. The distance between a sound source and an object may be calculated by measuring the time it takes for the sound to travel to the object. The velocity of the sound through the air is 344 m/s within the standard medium of air and temperature of 20◦C[12]. Therefore, if it takes 58.2 ms for the echo to

(13)

Distance = Velocity of sound × Time

2 =

344 × 0.0582

2 = 10 m

2.1.2 Impact of environment factors

The velocity of sound may change if the medium between the sound source and the target is different from the standard medium of air, and if the temperature is also different from ideal temperature 20◦C. Primarily factors that affect the speed of the sound waves within

the application environment are; • Temperature

• Medium pressure

• Medium absorbency (dust, humidity) • Medium type

• Reflectivity of material

To achieve a good accuracy for distance measurement, all these conditions must be known before the setting up of the application [12]. The dry air is considering as an ideal medium of the air for indoor environmental conditions. Therefore, the air pressure does not affect the speed of the sound. The humidity has also a small effect on the speed of sound. Thus, the impacts of the humidity and the air pressure may be neglected. For indoor distance measurement, the speed of sound has dependency only on the air temperature. The dependency is almost linear.

For outdoor environments, the speed of sound changes with the temperature, as well as, low humidity and air pressure. The pressure variation does not affect the speed of sound if the air is dry. Furthermore, if there is humidity in the air, the influence of the air pressure in the speed of sound is small and may be neglected. It depends on the requirement of the application environment. Thus, the sound speed depends on temperature and relatives humidity. Temperature is an essential factor of the sound speed which may be consid-ered [13]. In the air, the speed of the sound increases simultaneously with the increasing temperature about 0.17% per Celsius [12].

(14)

The impact of the relative humidity on the sound speed depends on the temperature. If the temperature is below 20◦C, the influence of the relative humidity on the sound speed

may be neglected, because of unclearness change of the humidity that affect the sound speed. For temperature values above 20◦C, the sound speed increases, in connection with

the relative humidity as seen in figure 5.

Figure 5: Speed of sound variations with temperature and relative humidity [13] In summary, the sound speed has a direct impact on the accuracy of distance measurement. For the outdoor environment applications, the pressure influence on the sound speed is little and can become neglected. The temperature has the most significant impact on the sound speed. The relative humidity may become taken into account if the temperature value is higher than 20◦C [12] .

2.1.3 Ultrasonic sensors

An ultrasonic sensor module contains two components; the first one generating the sound and receiving the echo (transducer), and the second one to interpreting the data (con-troller) [12]. Every sensor has a transmitter unit and a receiver unit, otherwise it can be a transmitter and a receiver in one unit [13].

Ultrasonic sensors use a transducer as transmitter/receiver unit to create the sound and sense the echo. A piezoelectric crystal inside the transducer, converts the electrical transmit pulse into the sound energy, and converts the sound waves into the air where it travels to target. When the sound waves are reflected, the transducer converts the sonic energy back into an electrical signal. The primary mission of the controller in an ultrasonic sensor is to analyse the signals that come from the transducer and turn it into something useful. The controller operates a signal processing to eliminate unwanted noise and extract the most probable echo from the target [12].

Ultrasonic sensors operate at different frequencies. A lower frequency sensor should be selected for longer ranges of detection, and a higher frequency sensor should be selected for shorter range, with higher resolution measurements [13].

(15)

2.2 Low Power wide Area Network (LPWAN)

IoT is smart devices connected to each other through internet. IoT is included in many life applications e.g. industry, transportation, logistics, smart home and smart city applica-tions. The smart devices communicate in two ways either wired or wireless communication. The consideration in this thesis is for the wireless communication which include Low Power Wide Area Network (LPWAN)[14]. LPWAN is growing effectively and the reason is the “low power, long range, and low-cost communication characteristics”. By the long-range means 10-40 km, in contrast to short range network (e.g. ZigBee, Bluetooth). The LP-WAN is proper for IoT applications to transmit a little amount of data in long range. An example of LPWAN technologies is NB-IoT, Sigfox and LoRa [15].

2.2.1 LoRa

LoRa stands for Long Range. It is a wireless communication technology which has been developed by Semtech [16]. This communication technology is mainly targeted for machine to machine (M2M) and IoT networks. Some of the key properties of LoRa are long-range capability, low power consumption and high robustness. A single gateway or base station may cover entire city or hundreds of square kilometres [17].

LoRa uses frequency shift keying (FSK) modulation as the physical layer. It is very effi-cient modulation for achieving low power consumption. LoRa utilizes a spread spectrum technique called Chirp Spread Spectrum (CSS), which maintains the same low power char-acteristics as FSK modulation but significantly increases the communication range [18]. CSS has been used in military and space communication for decades, due to the long com-munication distances that may become achieved and robustness to interference. LoRa is the first low-cost implementation for commercial usage. The basic explanation of CSS is that each bit of information is encoded as multiple chips in the transmitted signal. LoRa employs multiple orthogonal spreading factors(SF). SF is ranging from 6 - 12 but using the spreading factor 6 is currently not enabled by Semtech [16]. SF provides a tradeoff between data rate and range [18]. Choice of higher spreading factor may increases the range but decreases the data rate and vice versa as illustrated in figure 6.

(16)

LoRa uses Hamming codes for forwarding error correction (FEC). LoRa offers code rates (CR) values between 0 to 4, where CR = 0 means no FEC. LoRa uses code rates of 4/5, 4/6, 4/7 and 4/8. If the code blocks are well defined as the minimum hamming distance is 1, 2, 3 and 4 are corresponding code rates 4/5, 4/6, 4/7 and 4/8 respectively. The error correction and error detection capabilities are shown in table 1. As can be seen in table 1, error correcting is only introduced by the 4/7 code rate. Furthermore, the code rate 4/8 does not add to the error correction capabilities, only to detection capabilities. The code rate 4/5 offers no clear advantage over no coding and code rate 4/6 only adds error detection, but no correction capabilities. Therefore, to have actual error correcting capabilities, at least code rate 4/7 must be used. If the code rate is denoted as k=n, where k represents useful information, and encoder generates n number of output bits, then n − k will be the redundant bits. The redundancy allows the receiver to detecting and correcting the errors in the message, but it also decreases the effective data rate [18]. However, introducing coding and utilizing code rate 4/7 increases the payload length by 75% [16].

Table 1: Error correction and detection capabilities of LoRa Code Rate Error Correction [bits] Error Detection [bits]

4/5 0 0

4/6 0 1

4/7 1 2

4/8 1 3

2.2.2 LoRaWAN

The LoRa-Alliance describes LoRaWAN [17] as:

LoRaWAN is a LPWAN specification intended for wireless battery-operated Things in a regional, national or global network. LoRaWAN targets key requirements of Internet of Things such as secure bi-directional communica-tion, mobility and localization services. The LoRaWAN specification pro-vides seamless interoperability among smart things without the need of com-plex local installations and gives back the freedom to the user, developer, businesses enabling the roll out of Internet of Things.

LoRaWAN defines the communication protocol and the system architecture for a LoRa network. The protocol and the network architecture have the impacts in determining the battery life of the node, the network capacity, the quality of service, the security, and the variety of applications served by the network.

2.2.2.1 Device Classes

LoRaWAN end-devices are used for different applications and have different requirements. To optimize a variety of end application profiles, LoRaWAN utilizes different device classes. The device classes trade off network downlink communication latency versus battery life-time.

(17)

Class A devices have the most limited downlink communication capabilities which in-tended for the devices that rarely need to receive downlink transmissions. All downlink transmissions to a class A device must be performed shortly after an uplink transmission from the class A device. Since a class A device opens only in two short receiving windows within a limited time from the associated uplink transmission. Downlink transmission is not possible outside of those two receiving windows. If the downlink transmission is re-quired at any other time, the gateway simply must wait until the next uplink transmission from the device before transmitting a message on the downlink. End-devices of Class A are the most energy efficient devices comparing to other device classes.

Class B devices are similar to Class A devices. The difference between a Class A and B device is that the random receive windows in Class B device opens extra at the scheduled times. For the end-device to open the receive window at the scheduled time, it receives a time-synchronized beacon from the gateway. It allows the server to know when the end-device is listening.

Class C devices are best suited if the downlink transmission is important for the appli-cation. End-devices of Class C listen almost continuously for downlink messages from a gateway, and only close when transmitting an uplink message [17].

2.2.2.2 Network topology and capacity

A LoRaWAN network consists of at least a network server, gateway and an end-device. In the network, the nodes are not associated with a specific gateway. A single end-device can be connected to several gateways. The gateways receive data from one or multiple end-devices which are connected to the gateways over LoRa. Additionally, the data is forwarded to the network server. Each gateway will forward the received packet to the cloud-based network server via TCP/IP which means that the gateway must be connected to the Internet in the same way. Afterwards, the network server makes the data available to an end-user/application [17].

LoRaWAN network have a star-of-stars network topology. A central server is a root or the center of the network. One or multiple gateways are then connected to the central server, creating a network with a star layout. Furthermore, each gateway has its own star-network, where the gateway is the central node and end-devices connect to it. It results in a star-of-stars topology [16].

(18)

To make a long-range star network available, the gateway must have a very high capacity or capability to receive messages from a very high volume of the nodes. High network capacity in a LoRaWAN network is achieved by utilizing adaptive data rate and by using a multichannel multi-modem transceiver in the gateway so that simultaneous messages on multiple channels can be received.

Since LoRa is a spread spectrum-based modulation, the signals are practically orthogonal to each other when different spreading factors are utilized. As the spreading factor changes, the effective data rate also changes. The gateway takes advantage of this property by being able to receive multiple different data rates on the same channel at the same time [17]. Adaptive data rate (ADR) is a mechanism for optimizing the data rates, the airtime and the energy consumption in the network [20]. If a node indicates that it wants to use ADR, the network will collect some information of transmissions from the node. The information contains the frame counter, signal-to-noise ratio (SNR) and several gateways that received each transmission. Based on this information, the network can calculate if there is a need to increase or decrease the data rate and power transmission. The potential space opens more for other nodes, by optimizing the data rate and the time on the air. Adaptive data rate also optimizes the battery lifetime of a node.

In LoRaWAN, the intelligence and complexity are pushed to the network server. In this way it manages the network and will filter redundant received packets. In addition, to per-form security checks, schedule acknowledgments through the optimal gateway, and perper-form adaptive data rate [17].

2.2.2.3 Security

Security is extremely important for any LPWAN platform. LoRaWAN utilizes two security layers: one for the network and one for the application. The network security handles authenticity of the node in the network. Whereas the application layer of security handles the network operator that does not have access to the end user’s application data. The LoRaWAN packets can be both signed and encrypted using security keys. Security keys that is used by LoRaWAN are explained in table 2. NwkSKey is used to encrypt the whole frame (headers + payload). When the data is sent, this key is used to sign the message which allows the network server to verify the identity of the device. AppSKey is used to encrypt the payload in the frame. This key doesn’t need to be known by the Network Server to be able to know where to forward the message to. Then, the application server decrypts the data using the same key [17].

(19)

Table 2: Security keys that are used in LoRaWAN

Contraction Explanation

DevEUI Device EUI - set by manufacturer, unique per device EUI Extendet Unique Identifier - a globally unique ID DevEUI Device EUI - set by manufacturer, unique per device AppEUI Application EUI - identifies the en application AppKey Application Key - used in OTAA to generate session keys DevAddr Device Address - identifies a devoce on a particular network NwkSKey Network Session Key - encrypts the packet metadata AppSKey Application Session Key - encrypts the packet payload

RxDelay Recieve Delay - time between transmit and recieve CFList Channel Frequency List - frequency settings for each channel

Nonce A number that is only used once in cryptographic messages AppNonce A nonce sent from network the device during a join response

that allows the device to generate the session keys

Security level depends on the activation method. In LoRaWAN there are two different activation methods. A node can join the network by Over-the-Air Activation (OTAA) or Activation by Personalization (ABP).

In OTAA, the end node must support the join function and be able to store dynami-cally generated keys. For activation, the device sends a join request with pre-programmed DevEUI, AppEUI and AppKey. Any gateway that manages the receiving of the packet, forwards it to the network. The network server receives a request and consults the entity associated with the AppEUI to validate the request. If the permission is granted, it re-sponds with a join-accept response. The join-accept response contains a NetID, a DevAddr and an AppNonce as well as some network settings like a RxDelay and an optional CFList. Only the gateway that receives the strongest signal, sends the response back. The device stores the NetID, DevAddr and network settings. Then, it uses the AppNonce to generate the session key, NwkSKey and AppSKey. OTAA is the preferred and most secure way to connect a network. A disadvantage with OTAA is that the device must implement some connection mechanism that adds an additional layer of complexity.

In ABP, a device does not need a DevEUI, an AppEUI or an AppKey. The session keys NwkSKey and AppSKey are preprogrammed into the device. The network server is also pre-configured with the device’s DevAddr, AppSKey and DevSKey so it recognizes the associated transmissions. When the device wants to communicate, it is using the session keys without having to use a join procedure first. ABP is an easy way to connect to the network, the device can be made operational in little time. The disadvantage is the encryption keys that enabling the communication with the network, are preconfigured in the device which is a weakens in the security [20].

(20)

2.2.2.4 LoRaWAN for Europe

The LoRaWAN specification varies from region to region. The LoRaWAN specification for Europe and North America is defined, but other regions are still being defined by the technical committee. In Europe, LoRaWAN defines ten channels and uses 867-869 Mhz frequency band [17]. There are duty cycle and maximum output power restrictions under ETSI. The maximum output power allowed by ETSI in Europe is +14dBM, apart from the 869.4MHz-869.65MHz band that allows +27dBm.

Table 3: LoRaWAN in Europe and North America

Europe North America

Frequency Band 867-869Mhz 902-928Mhz Channels 10 64+8+8 Channels BW Up 125/250kHz 125/500kHz Channels BW Dn 125kHz 500kHz Tx Power Up +14dBm +20dBm typ (+30 dBm allowed) Tx Power Dn +14dBm +27dBm SF Up 7-12 7-10 Data Rate 250bps-50kbps 980bps-21.9kbps Link Budget Up 155dB 154dB Link Budget Dn 155dB 157dB

According to the European regional parameters for LoRaWAN, all units must implement at least the three following frequency channels of 125 KHz width with center frequencies at 868.1 MHz, 868.3 MHz and 868.5 MHz with a duty cycle of 1% [16].

The duty cycle indicates that the fraction of time of a resource is busy. For instance, if a signal is on for 1 second during each period of 100 seconds, the duty cycle of the signal is 1/100 or 1%. The wait time between each transmission can be calculated as:

ToffSubband = TimeOnAirDutyCycle −TimeOnAir = 1

0.01− 1 = 99s

In the formula "ToffSubband" stands for wait time, and "TimeOnAir" stands for trans-mission time. Using the formula, the maximum transtrans-mission time for a channel that has duty cycle of 1% can be calculated as 36 sec /hour. Every device must be compliant with the regulated duty cycle limits. This applies to both nodes and gateways. In practice, this means that every device should be programmed in such a way, that they stay within the limits. The easiest way to do this is to check how much airtime each message consumes, and then uses that information to choose a suitable transmit interval [20] [16].

2.3 The Things Network(TTN)

(21)

network, the awareness should be raised for the security risks that could show up [19]. An example of a public network is The Things Network (TTN).

The Things Network is a public network that builds a network for the internet of things. The technology used for this network is LoRaWAN that allows the connection to the internet without 3G or Wi-Fi. Additionally, the technology provides low battery usage, long range and low bandwidth which is suitable to the Internet of Things. The process of TTN-connection: low power devices use long range gateways which are connected to an open-source network that exchanges data with the user applications as illustrated in figure 8 [20].

Figure 8: The Things network architecture

Table 4 is a list of frequency plan definitions used in The Things Network. These frequency plans are based on what is specified in the LoRaWAN regional parameters document. Additionally, on The Things Network’s public community network, there is a Fair Access Policy that limits the uplink airtime to 30 seconds per day (24 hours) per node and the downlink messages to 10 messages per day (24 hours) per node. If a device uses a private network, these limits do not apply, but it still has to be compliant with the governmental and the LoRaWAN limits.

Table 4: List of Europe frequency plan definitions used in The Things Network

Frequency Channel (MHz) Bandwith (Khz) Spreading Factors Duty Cycel

Uplink 868.1 125 7-12 %1 Uplink 868.3 125 and 250 7-12 %1 Uplink 868.5 125 7-12 %1 Uplink 867.1 125 7-12 %1 Uplink 867.3 125 7-12 %1 Uplink 867.5 125 7-12 %1 Uplink 867.7 125 7-12 %1 Uplink 867.9 125 7-12 %1 Uplink (FSK) 868.8 - - %0.1 Downlink 869.525 125 9 %1

(22)

3

Related Work

This chapter contains descriptions of previous works related to this thesis.

3.1 Early flood alerts using Short Message Service (SMS)

In 2015, an article [21] describing a flood warning system was published. According to the article, the existing flood warning systems lack basic abilities to monitor water level, to give immediate warning notifications and to offer a well-organized coordinations during the evacuation process. Therefore, the researchers wanted to design a new system that overcomes the lacks in the existing systems, reducing losses and effects caused by a flood. The designed pre-flood warning system consists of three primary systems; the identification system, the data processing system and the SMS transmission system. An ultrasonic sensor is installed at a riverbank to measure the water level. Signals from the ultrasonic sensor are sent to a microcontroller that processes and analyses the data with a reference to the past cases. Based on a comparative study, the researchers choose an Arduino UNO as a main microcontroller for this system. If the flood status is set to "dangerous", a warning message is sent to all registered users and local authorities. Warnings are sent in the form of a text message (SMS). The researchers choose the IComsat GSM modem to send the SMS. The GSM modem is connected to the nearest GSM base station to obtain a list of all registered users in an area. The system uses a solar panel as a main power source and rechargeable batteries are used as an additional power source.

There are two types of warning messages sent via SMS. The first warning message is sent when the water level rises to a dangerous level. The message informs the users that the water level has reached a dangerous level and that a flood may occur. Then, the users can prepare for the evacuation process. However, the system continues to collect new measurement data to determine the state of a flood risk. The second warning message is sent if the water level continues to increase within ten minutes after the first message has been sent. The second message informs the users to avoid being in the area or to go to the nearest evacuation center.

This article is only a conceptual framework and that is not yet validated according to the researchers. The next step in the research, the researchers want to implement and test the system. This article is relevant to this thesis since it helped with understanding the factors that should be examined while doing a comparative study for choosing the right sensor and the right microcontroller. The system should be built by using an ultrasonic sensor that measures the water level, which is used in this thesis. The system should send three warning messages and alert the users when the water level is reaching specific thresholds. The concept of measuring three different water levels is used in this thesis. The differences between this thesis and the conceptual work are, the developers use GSM as a communication link, not LoRa, and a solar panel as a power source.

3.2 A flood warning system to critical region

In this article [22], the authors describe a cheap variant of a flood warning system that may be used to reduce damage and loss caused by floods in the city center.

The system measures the water level using an ultrasonic sensor (HC-SR04). A microcon-troller (ESP8266 NODEMCU) is connected to the ultrasonic sensor. The microconmicrocon-troller

(23)

measurement is done periodically to calculate an average value. The reason for calculating the average value is to minimize errors due to current disturbances. The result of mea-surements is stored in a cloud database (Ubidots). Local area network (WiFi) is used to transmit data to the cloud database. Depending on the water level the system sends a warning message in the form of a short text message (SMS) or makes a telephone call to an emergency center using a GSM module.

For validation of the system, the researchers perform tests in a laboratory. The prototype is placed above a water tank, and the tank is filled with water by a water pump. The test result shows that the system detects the water level with ± 4 mm precision. The system manages to save the data in a cloud database, and the data is visualized by generating a graph in another platform.

The paper contributes to this thesis by giving a suitable example for testing water level measurement systems, and it visualize the data in real time. The difference between this thesis and the related work is, the researchers use a GSM module as a communication link while LoRa is used in this thesis. Before the installation of the LoRa gateway in Malmö city, the idea was to execute the building of the prototype in this thesis by using GSM as a communication link.

3.3 Design and development of a flood warning system via mobile and computer network

The article [23] is about designing and development of a flood warning system. The urgency of designing a warning system became more important after that Thailand experienced a flood in 2011. Rainfall was a main reason for the flood. It had increased and led to this flash flood in many provinces of Thailand.

The flood warning system is placed in a remote area to measure, transmit and store the data automatically on a database server. The server is for sending the warning notifications to the users if a flood may occur. A data acquisition module is chosen for the system. The module is an embedded system that measures amount of rainfall and water level with an image of the surrounding area. The embedded systems are classified in two platforms: microcontroller-based platform and microprocessor-based platform. The researcher aimed to use microcontroller-based which is Arduino. After testing, it showed up that Arduino modules that are qualified with the mobile network are limited and high in cost. In this case the developer decided to use raspberry pi modules which are microprocessor-based platform and more affordable. The data acquisition module can be settled anywhere with cellular data network coverage. The data transmission is over the internet via a cellular data network to the server. The server runs two applications; a web server application and a database application. The web server application has a set of REST based APIs. It is used of the acquisition module to transmit data to the server to store it in a database. The used web application is a user mobile application for view and receive warning messages. In this article the tests for the whole system are made in the laboratory. The tests per-formed by development of five stations. At each station the data measures of a bucket with an ultrasonic sensor. Test results contains 2% error. In some cases, the warning messages are not sent because the water level measurements are under the threshold which is 100 cm.

The researcher has approved that a flood warning system can be designed and developed by using a microprocessor-based embedded system with a mobile and a computer network. The article relates to this thesis by doing the same tests in the laboratory. Additionally, the way how the water is measured is same, by an ultrasonic sensor. The network used

(24)

is a cellular data network which differs from the network used in this thesis, LoRa. The other difference is, the warning messages are received and viewed in the user application. In this thesis, the measurement data is viewed in the current time on Cayenne dashboard.

3.4 On the application of IoT: Monitoring of troughs water level using WSN

The article [24] is about development of a system that is monitoring the water level of troughs. The inquire of a such system is increasing, as well as Wireless Sensor Network and Internet of Things. The cattlemen can use this system for monitoring the troughs connected to the portable personal devices.

In this system, the developer uses LoRa as a connection between the sensor hub and the nodes. For the reason to connect the nodes to a gateway which is already connected to the internet. The chosen communication topology between the hub and the nodes is the star topology. The developer refers a hub to the sensor hub and a node to the settled device at the trough to measure the water level. The measured data from the node is sent through the gateway to the server. The settlement of the gateway is on the roof of the cattlemen’s house.

The choice of the LoRa component with 915 MHz center frequency, is HopeRF RFM95. The reason of the choice for this LoRa component is to ease the transmission between the cattlemen’s house and barns that may be affected. Furthermore, for the node measurement, an Atmel ATmega328 is chosen as a controller to fulfill the requirement “low power system for remote area purpose”. Lastly Raspberry Pi Model B is used as a controller for the hub. The system works independently i.e. without any need of configuration. The beacon of the hub starts broadcasting to the air, at the same time the nodes are scanning to join the beacons. The node joins to a beacon which detect the highest Signal Strength Indicator(RSSI). The sending data from the node is in a periodic form and gives information about the water level status of the troughs in three conditions: underflow, normal and overflow.

The developer made first laboratory test that become successful, the transaction between hub and nodes is made. Some improvement is needed to connect a big number of nodes to a hub. On the other hand, the test made in the field shows that the antenna of a hub or of nodes should be lower, otherwise it leads to bad transmission quality.

The comparison between the built prototype in this thesis and the related work is that both of them use LoRa technology as a communication link. The developed software in the related work sends the data in three conditions, underflow, normal and overflow. In this thesis, the developed software sends also three states of measurement data; Low, Medium and High. Although the developer uses LoRa technology, the components used for building the prototype are different from the ones used in this thesis.

(25)

4

Method

This chapter presents the research method and the study approach. This research is based on a method for building a prototype, specified by Nunamaker et. al [25].

4.1 Method Description

A method is a developmental process including assumptions, values, and conditions that the researcher should carry out for analyzing the data. The method choice for this thesis is a system development method presented by Nunamaker et. al [25]. The reason for choosing this method is that it has an iteration ability, i.e. updating and editing in the previous steps of the method as shown in figure 9. The researcher obtains an opportunity to make improvements and changes, thus learning new things.

(26)

4.1.1 Construct a conceptual framework

First step of the method is to define the problem area and the research questions from the information given by Malmö City municipality [11]. To establish the background knowledge to be able to answer the RQ1.1-RQ1.3 in chapter 1, a literature study was done by searching through different databases with various keywords with the aim of reaching as few and relevant search results as possible. The databases that were used for the literature study are IEEE Xplore Digital library, Science Direct and ACM Digital library. The reason for using these databases is because they are reliable sources. Literature study for different parts of the system was done as shown below:

Measurement technique

• A comparative study for the measurement technique was made through a literature study and a comparison between the different techniques for water level measurement, e.g. infrared or ultrasound in section 5.1.2.

Visualization platform/dashboard

• A comparative study for the visualization dashboards was made for choosing the compatible dashboard for the chosen LoRa board, and it can integrate with TTN as presented in section 5.1.2.

4.1.2 Develop a system architecture

The next step in the system development method is to create a system architecture, which describes the various system functions. The architecture is an overall description of the system’s functionality. A problem breakdown was created in which the main functions are decided and then divided into partial functions, as seen in section 5.1.1. The components in the system originally decide the functions involved in the system architecture building. Therefore, a dynamic interaction between the system’s different components is important. The identification of the different system functions is determined by using the requirement specifications in chapter 1. The physical view of the system is presented in 4.1.4, while the logical view is presented in 5.2.2.

4.1.3 Analyze and design the system

At this stage of the system development method, some of the relevant components for the prototype are chosen, which are a relevant sensor and a microcontroller. Consequently, a software development environment was selected. Lastly, an uml diagram was designed based on the system architecture. An uml activity diagram was selected for displaying an overview of the software functions of the system, see figure 18. The reason for selecting the uml activity diagram was to decide the different steps of the software for the system functions.

4.1.4 Build the system

The system implementation depends on the design built from the previous step. Imple-mentation from the previous design gives insight into what problems that may occur, which

(27)

when using the system development method. Implementation of the system consisting of various parts besides system overview are explained below:

Hardware

• The main part of the entire system is hardware. The water level measurement in the wells uses a sensor connected to a microcontroller. According to the thesis limita-tions in 1.4, the communication link is LoRaWAN, which may either be built into a microcontroller or be built separately. In this step, the rest of the hardware part was determined for the product which consists of an encapsulation box and a battery. A battery with a long lifetime is necessary because it is difficult to change the battery often when the device is installed in the wells.

Visualization of data

• The data about the water level is visualized on a platform. The reason for visualizing the data is to act when the water level is higher than it is supposed to be. The plat-form, or “dashboard”, should be compatible with the limitation of the public network which is “The things network (TTN)”. TTN can integrate with the dashboards to display the data real-time as a chart form or as a value form. It is easier to choose the dashboard when it is limited to TTN. Examples of dashboards that can integrate with TTN are Cayenne and allThingsTalk maker.

System overview

• The system overview in figure 10 shows how the parts of the system are paired together to form the prototype. A more specific system overview is illustrated in section 5.4.1.

(28)

4.1.5 Observe and evaluate the system

In the last step of the system development method, the tests and the evaluations that were performed on the whole system. The tests were executed in a lab environment. All the made tests are presented in Appendix A.

4.1.5.1 Test for water level measurement

The water level measurement tests were performed as mentioned earlier in a lab environ-ment, namely, not in the water wells. This occurs by measuring the distance of a wall in a closed circumference to observe if the obtained measurement information from the sensor is correct. The second test was made outside in the water channel, to observe if the sensor is able to measure the water surface.

4.1.5.2 Test for LoRaWan Network

Since the LoRaWAN has recently been activated in Malmö city, the system was tested by connecting the LoRa module to TTN, and then it started to send and receive the measured data.

4.1.5.3 Test for visualization of data

The tests were performed by integrating the platform with TTN, and the platform shows the data for different heights of the water level in real-time.

4.1.5.4 System evaluation

Depending on the test results of the above made tests, the system can be updated if any adjustments are needed. There are some conditions in the system that cannot be tested, e.g. the prototype is resistant to different weather conditions. It is difficult to expose the prototype to these various conditions e.g. to tolerate -20 degrees. Therefore, there is no other choice than relying on the resources that market the components.

(29)

5

Results

This chapter presents the results of the thesis by following the steps of the system devel-opment method according to chapter 4.

5.1 Construct a conceptual framework

The research problem area was divided into three main subproblems shown in the figure below:

Figure 11: Main subproblems

Measuring the water level in the wells: The reason for obtaining information about the water level measurements is to take the necessary actions when the water level is higher than the predefined threshold value. Furthermore, minimizing the losses that occur associated with a high-water level.

Sending data to The Things Network through LoRa: The data from the water level measurements is sent to TTN through LoRa. According to the limitations in chapter 1, the public LoRa network that should be used is The Things Network(TTN).

Visualization of the measured data: The information obtained about the water level is visualized on a platform/dashboard. The importance of it is to have control over the water level in real-time.

(30)

5.1.1 Problem breakdown

To resolve the three defined subproblems, there are different steps to follow as seen in figure 12.

Figure 12: Problem breakdown • How to Measure the water level in the wells?

The water level is measured through two steps as illustrated in the figure below:

(31)

1. Selecting water level measurement technique:

The choice of the water level measurement technique is important because it is easing the process of choosing the sensor needed for the prototype. The choice of measurement technique is presented in section 5.3.1

2. Choosing a sensor:

Sensor selection is a crucial activity to be considered in any design system. It makes a great impact on the process system performance during its entire lifetime and could even have consequences related to the quality of a product. There are many sensors in the market. In order to choose the needed sensor for the prototype a comparison between them was made. The chosen sensor should fulfill the requirement specification for the sensor part in chapter 1. The choice of sensor is presented in section 5.3.2.

• How to send data to The Things Network through LoRa? Sending the data through LoRaWAN occurs by the steps shown below:

Figure 14: Second subproblem 1. Selecting a microcontroller with a LoRa module:

A microcontroller connects to the sensor, and it processes the measured data gathered from the sensor before the data is sent to TTN. The chosen microcon-troller with a LoRa module should fulfill the requirement specification. Other modules should be tested for a comparison, and then choosing the module needed. The choice of microcontroller is presented in section 5.3.2.

2. Software development:

To develop the code for the needed software, which are the sensor and commu-nication with the public LoRa network (TTN). How the code is developed is presented in section 5.3.4.

(32)

• How to visualize the measured data?

The visualization of data occurs through two simple steps shown in figure 15.

Figure 15: Third subproblem

1. Choosing a real-time data visualization platform:

Platform choice is bounded by the limitations for the public network which is The Things Network. The choice of sensor is presented in section 5.3.3.

2. Integration of The Things Network and the platform:

The integration occurs in The Things Network website, by choosing the desired platform to integrate with.

5.1.2 Literature study

A literature study of the different parts of the system was made as mentioned below. • Measurement technique

According to the design purpose of the prototype, it is necessary to select a measure-ment technique. Nowadays, many distance detection techniques are widely used in different areas. However, all the technologies are not suitable for water level detec-tion. For this reason, the first step is to decide what kind of techniques are suited for water level detection. The suited technique is shown in analyze and design the system step.

Due to physical conditions, such as the build up of salt or sand and such as the water current, it was decided to select a non-contact measurement technique for the prototype. For this reason, using a non-contact measurement technique is needed. Ultrasonic (US) and infrared radiation (IR) are very common types of techniques used for distance measurement. Water level sensors can also be used as a water level detection technique. An important factor that should be considered when selecting the measurement technique is the physical conditions in the wells as described earlier

(33)

A clear difference between US and IR distance measurement techniques is their out-put voltage characteristic. The analog voltage outout-put from the US based sensors gives a linear output characteristic. Whereas, the IR based sensors show a nonlinear output characteristic [26]. Due to the non-linearity of the analog output from the IR sensors, the data linearization must be applied to determine the measured dis-tance. The analog output from the US based sensors is dependent on the distance and the orientation of the target relatives to the sensor. Owing to the linear output characteristic, there is no need for a data linearization for the US based sensors [27]. Another difference between those two distance measurement techniques, is their per-formance dependency on different target types. Accuracy perper-formance of IR sensors is dependent on the reflectivity of the target, where surface color and smoothness do not have much effect on the accuracy of the US sensors. Brighter surfaces are easier for IR to detect than dark surfaces. Other factors that affect measurement performance for IR sensors are the target’s light absorption rate and environmental conditions such as sunlight. IR sensor values normally fluctuate in variant light con-ditions. Targets that have a high light absorption rate, affect the IR sensor accuracy in a negative way. Even so, the US distance measurement technique has also some drawbacks. Environmental parameters such as temperature and humidity may af-fect the accuracy of the US sensors, but it is not afaf-fected by poor light conditions and target surface color/reflectivity as much as IR sensors [27]. The result of the literature study for the measurement technique is presented in section 5.3.1.

• Visualization platform/dashboard

There are many visualization dashboards that can integrate with TTN. There are two types of dashboards, Cayenne and Allthingstalk maker. Both dashboards can integrate with TTN, but one of them should be chosen to view the data for the system depending on the chosen microcontroller. The chosen dashboard is shown in section 5.3.3.

(34)

5.2 Develop a system architecture

5.2.1 System functions

The achievement of the system using the problem breakdown is shown in figure 16

Figure 16: System function 5.2.2 The logical view of the system

Apart from the physical view of the system as shown in chapter 4, the logical view of the system is shown in figure 17. The logical view is done to illustrate the performance of the system divided into three parts which are: Backend connected devices, communication, and front-end.

(35)

• Back-end connected devices

The back-end connected devices include the microcontroller with LoRa connectiv-ity and the sensor. The sensor measures the data and the microcontroller reads it. Consequently, the data is sent from the microcontroller to the gateway through LoRa. • Communication

The communication part presents how the back-end part communicates with the front-end. The data sent from the microcontroller is received by the LoRa gateway that forwards the data to TTN. When TTN integrates with a dashboard, the data is sent further to it and visualized.

• Front-end

The front-end part presents how the sent data from back-end devices is visualized on a dashboard. The dashboard presents the data as a value or a chart.

5.3 Analyze and design the system

In this section, the choice for the different parts of the system is analyzed. 5.3.1 Measurement technique

There are a lot of limitations in IR distance measurement technique as mentioned above in Construct a conceptual framework. Water has a high light absorption that affects the accuracy of the IR sensors in a negative way. Light conditions in the wells are not good and can also affect the IR sensor performance for water level measurement. All these factors show that US distance measurement is much more reliable than IR if the target is water. For this thesis, US sensors are much more suitable than IR. The drawbacks of US distance measurement technique such as temperature and humidity will be considered in the sensor selection process.

5.3.2 Hardware

• Sensor

As explained above in in the subsection 5.3.1, it was decided to use an ultrasonic sensor for the prototype. For the chosen sensor, the most important requirement is that it must be waterproof and can measure distance up to 5 meters. There are many different models of ultrasonic sensors on the market, but all models are not waterproof. Research was conducted into the availability on the market and finally two different sensors were picked from different manufacturers, MaxSonar-MB7092 and MassaSonic Pulstar-Plus. Both sensors meet the requirements mentioned above. Based on the comparative study on two different ultrasonic sensors in table 5, MaxSonar-MB7092 is chosen to be installed in the well in order to measure the water level and send the data to the microcontroller for data processing. The ultra-sonic sensor MaxSonar-MB7092 was chosen in this thesis because of its low current consumption and low voltage requirement. The selected sensor is calibrated to 20◦C.

(36)

Table 5: Comparative study on two different ultrasonic sensors Area MaxSonar MB7092 [28] MassaSonic PulStar Plus [29] Range 20cm - 765cm 20cm - 600cm Resolution ± 1 cm ± 0.25 cm Update Rate 10Hz 0.1Hz - 20Hz

Output Analog output

(Vcc/1204) per cm

Analog output (0V-10V) or (4mA - 20mA)

Voltage Requirement 3V - 5V 12V - 24V

Current Requirement 2.4mA 30mA

Operational Temprature −40◦C to 70◦C −40◦Cto 70◦C

Sound Frequency 42kHz 95kHz

• Microcontroller with a LoRa module

The research was carried out on the modules that are available on the market. Three different development boards with LoRa connectivity were picked from different man-ufacturers. To make a comparison between the selected boards, some of the features were tested, such as power consumption and communication stability. The choice be-tween these three boards depends on if they already have built-in LoRa connectivity. Therefore, there is no need to waste time on building a new board with a separate microcontroller and a separate LoRa module.

The selected sensor has an analog output and voltage from this output scaling of (Vcc/1024) per cm which means, the selected development board must have an analog input with at least ten bits resolution in order to read measurement value in cm. Another important requirement for the selected development board is that the board should have a low current consumption when it is in standby mode. Since the device is battery powered and it is in standby mode in most of the time.

Based on the comparative study made on those different development boards in table 6, Adafruit Feather 32u4 has lowest current consumption when it’s in standby mode. This board has a LoRa transceiver (Semtech - SX1272) and needs a library to implement LoRaWAN stack. LMIC library which is provided by IBM is used to test the communication performance. During the communication test, it is noticed that communication is unstable. Especially, when receiving downlink messages and joining the network with ABP, because of these drawbacks this board is discarded. In this thesis Badgerboard is chosen as a development board because of the low power consumption. It easies the usage of LoRaWAN commands and provides stable communication with the network.

(37)

Table 6: Comparison between different development boards

Badgerboard [30] Arduino

MKR WAN 1300 [31]

Adafruit Feather 32u4 [32]

Microcontroller ATMega32U4 SAMD21 Cortex-M0+ ATMega32U4

Operating Voltage 3.3V 3.3V 3.3V

Analog Input Pins 5 (ADC 10 bit) 7 (ADC 8/10/12 bit) 12 (ADC 10 bit)

Analog Output Pins - 1 (DAC 10 bit)

-Flash Memory 32kB 256 KB 32kB SRAM 2 kB 32 kB 2 kB Clock Speed 8MHz 48 MHz 8MHz Carrier frequency 433/868/915 MHz 433/868/915 MHz 433/868/915 MHz Operating Temprature −20◦C - 65◦C - -Current Consumption Stand by mode 0.53 mA 1.70 mA 0.25 mA

MAC Layer LoRaWAN LoRaWAN

-Physical Layer LoRa LoRa LoRa

Device Class A A-C A-B

5.3.3 Real-time data visualization platform • Cayenne

Cayenne [33], is the first drag-and-drop project builder. It is a display dashboard to design prototypes to complete IoT solutions. The way how the Cayenne dashboard can be used in this thesis is through integration with TTN. The connections occur by registration of DevEUI when creating a new project in Cayenne. The viewed information is sent from the LoRa module in byte form through TTN to Cayenne. The chosen LoRa module is not listed in the list of devices in Cayenne. In this case, the user can choose The Cayenne Low Power Payload (LPP). Cayenne LPP library provides a convenient and easy way to send data over LPWAN networks, such as LoRaWAN. The Cayenne LPP is compliant with the payload size restriction, which can be lowered down to 11 bytes, and allows the device to send multiple sensor data at one time.

• Allthingstalk maker

Allthingstalk(ATT) maker [34], is a cloud instance, which is an IoT Application Enablement platform for prototyping and full-scale product deployment, by connect-ing devices to web services and visualizconnect-ing them on a web dashboard or a mobile. An integration between TTN and ATT-maker are available. The requirements for connecting a device in ATT-maker to TTN are the DevEUI, appEUI, deviceAdress, nwSkey and AppSkey. The Allthingstalk maker is not suitable for the system in this thesis because the chosen LoRa board is not compatible with ATT-maker. Addi-tionally, TTN updates the DevAdress, nwSkey and AppSkey every time the device is joined to the network. In this case, the ATT-maker user should change deviceAdress,

(38)

nwSkey and AppSkey manually every time the device restarts. For this reason, the Cayenne dashboard is chosen for the system in this thesis.

5.3.4 Software

To visualize data in Cayenne it is necessary to send at least 4 bytes of application payload, one byte for the Cayenne channel, one byte for the data type and 2 bytes for the water level percentage. In addition, LoRaWAN protocol adds at least 13 bytes to the application payload. The measurement value is sent in percentage form because it is easier to analyse the visualization for the different wells that have different sizes. The deepest level in the well is hardcoded in the software.

The first step in designing the software is to find out how often and how much data can be sent based on the LoRaWAN and TTN limitations, as mentioned in sections 2.2.2.4 and 2.3. To find out the number of allowed messages per day, a message was sent with different spreading factors. Additionally, the transmission time was read in TTN console, as shown in table 7.

Table 7: Number of allowed messages to TTN with different spreading factor. Transmitted application data is 4 bytes, CR is 4/5 and BW is 125khz

Spreading Factor

Transmission Time On The Air (TOA)

Data

Number of Allowed Messages Per Day

30.000ms/(TOA) SF7 31ms 967 SF8 62ms 483 SF9 124ms 241 SF10 206ms 145 SF11 414ms 72 SF12 827ms 36

As shown in the table above, the device can send a maximum of 36 messages per day. Each transfer takes 827ms in the worst case, which is SF12. Frequency channels that are used by TTN in Europe have a duty cycle of 1%. This means if the transmission time is 827ms, the device must wait at least 82.7 seconds between two transmissions if the SF is 12. According to the results, a software for the prototype was designed and represented as an activity diagram in figure 18. Furthermore, three different states were defined: Low, Medium and High. The low state means that the water level is between 0% to 50%. When it is between 51% to 75%, the state is Medium. The state is HIGH when the water level is between 76% to 100%. The prototype sends the measurement data once in a hour if the state of the water level is same as the previous state. If the state is not the same as the former state, a new message is sent without waiting one hour. In this way, the device sends at least 24 messages per day, and 12 messages will be saved for state changes in worst case scenarios. In that way, the device stays within the duty cycle and TTN limitations. Avoiding transmitting data often will help reduce the power consumption as well.

(39)

Figure 18: Activity diagram

To allow some time for assembly, the device sleeps 10 minutes before connecting to TTN. Thereafter, it tries to connect to TTN with OTAA. As activation method, OTAA was selected because it is the preferred and the most secure way to connect to the network. During the joining process, ADR was also activated to optimize the data rate, the SF and the transmission power.

Each uplink message sends with an acknowledgment (ACK) request i.e. the device wants to be sure that TTN received the message. If TTN receives the message, it sends back an ACK message to the device. If the device does not receive the ACK message, then it will continue sending the same message up to 10 times at 30 seconds interval. After 10 failure of transmissions, the device will reset the software.

The device will be in standby mode most of the time in order to reduce power consumption. The time interval between the two measurements depends on the state. If the state is Low,

(40)

the device will be in standby mode 15 minutes between two measurements. If it is Medium, the time interval is 10 minutes, and if it is High the time interval is 5 minutes.

5.4 Build the system

Implementing the whole system was done through establishing the components used for the prototype, which are the sensor, the development board, the battery and the encapsulation box as shown in the circuit diagram in Appendix B. The power source for the prototype is a lithium thionyl chloride D size battery (Saft LS33600). This battery has a 3.6V nominal voltage, and can operate between −60◦C and 80C. It has a low self-discharge rate less

than 1% after 1 year. The nominal capacity for this battery is 17Ah and the reason of choosing this battery is to achieve at least one year battery lifetime. The used antenna for the device has +3dBi active gain [35]. To use this antenna will improve the range and reliability.

Additionally, a power supply filter was used for ultrasonic sensor. The filter includes a 10Ω resistor and a 100 µF capacitor. The power supply filter helps to clean the noise from the power source that may affect the sensor to have unstable range reading.

For encapsulation, a polycarbonate enclosure that is made according to IP68 standards was used. IP68 means that the enclosure guarantees a protection in the water about 3 meters deep for two hours and it is resistant to dust. The final prototype figure when it is built is shown below:

(41)

Figure 20 shows how the received data from the sensor is displayed on the Cayenne dash-board. It clearly illustrates the position where the prototype is installed and the water level in percentage form. Moreover, the figure illustrates the received signal strength indicator and signal-to-noise ratio of the last received message.

Figure 20: Cayenne dashboard 5.4.1 System overview

An overview for the whole system is shown in figure 21, with the name of every chosen product.

(42)

5.4.2 Current consumption

To calculate the power consumption of the device for one year, it was necessary to make some measurements that show the current consumption for different functions of the proto-type. The current consumption was calculated by serial coupling of a 1Ω resistor with the development board and through measuring the voltage across the resistor. As described in the previous chapter, the device will be in standby mode in most of the time and it consumes 0.53 mA in standby mode.

The device will wake up every 15 minutes and make a measurement to calculate the water level, then it sleeps again if no new message is required. If the water level is high the device will sleep 10 or 5 minutes depending on how high the level is. On the other hand, the most used sleep period will be 15 minutes because the probability that the rainy hours are less than the others is quite large.

Figure 22 shows the power consumption when the device wakes up, then makes a measure-ment and sleeps again. Power consumption for the measuremeasure-ment process is calculated as shown in equation (1).

Figure 22: Current consumption while measuring water level

Ih = 12.4mA × 0.86s

Figure

Figure 2: Fifteen minutes precipitation for Malmö on Sunday 31 August 2014 [7].
Figure 3: Application areas for ultrasonic level measurement technology [12]
Figure 4: Speed of sound versus temperature in air [12]
Figure 5: Speed of sound variations with temperature and relative humidity [13]
+7

References

Related documents

Från den teoretiska modellen vet vi att när det finns två budgivare på marknaden, och marknadsandelen för månadens vara ökar, så leder detta till lägre

The increasing availability of data and attention to services has increased the understanding of the contribution of services to innovation and productivity in

Generella styrmedel kan ha varit mindre verksamma än man har trott De generella styrmedlen, till skillnad från de specifika styrmedlen, har kommit att användas i större

I regleringsbrevet för 2014 uppdrog Regeringen åt Tillväxtanalys att ”föreslå mätmetoder och indikatorer som kan användas vid utvärdering av de samhällsekonomiska effekterna av

a) Inom den regionala utvecklingen betonas allt oftare betydelsen av de kvalitativa faktorerna och kunnandet. En kvalitativ faktor är samarbetet mellan de olika

Parallellmarknader innebär dock inte en drivkraft för en grön omställning Ökad andel direktförsäljning räddar många lokala producenter och kan tyckas utgöra en drivkraft

Närmare 90 procent av de statliga medlen (intäkter och utgifter) för näringslivets klimatomställning går till generella styrmedel, det vill säga styrmedel som påverkar

I dag uppgår denna del av befolkningen till knappt 4 200 personer och år 2030 beräknas det finnas drygt 4 800 personer i Gällivare kommun som är 65 år eller äldre i