• No results found

Communications solution for refugee settlement: Investigation of nRF24L01+ modules for use in a communications network

N/A
N/A
Protected

Academic year: 2022

Share "Communications solution for refugee settlement: Investigation of nRF24L01+ modules for use in a communications network"

Copied!
45
0
0

Loading.... (view fulltext now)

Full text

(1)

TVE-F 18 003

Examensarbete 15 hp Juni 2018

Communications solution for refugee settlement

Investigation of nRF24L01+ modules for use in a communications network

Martin Engquist

Simon Bethdavid

(2)

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress:

Box 536 751 21 Uppsala

Telefon:

018 – 471 30 03

Telefax:

018 – 471 30 00

Hemsida:

http://www.teknat.uu.se/student

Abstract

Communications solution for refugee settlement

Martin Engquist & Simon Bethdavid

The main purpose of this thesis is to test a communications solution for the second to largest refugee settlement in the world, Bidi Bidi. A solution where it is possible to inform the refugees with necessary information, for example that the water at a specific location is currently contaminated or that food is provided at another location. The idea is to use nRF24L01+ modules which operate in the 2.4 GHz frequency band and send information through various ways. This includes turning LEDs' on and off, sending text Strings and streaming audio. The results showed that the modules are too unreliable for a refugee settlement. They also showed that it is not possible to send other types' of data while streaming audio, but there could be workarounds. It is clear that more knowledge and further investigations are needed.

ISSN: 1401-5757, TVE-F 18 003

Examinator: Martin Sjödin

Ämnesgranskare: Maria Strömme

Handledare: Uwe Zimmermann

(3)

Populärvetenskaplig sammanfattning

Det här projektet har undersökt en alternativ kommunikationslösning till FM-radio. En enhet har tagits fram som kan välja vilken address den ska skicka till och vilken infor- mation som ska skickas. Dessutom kan olika typer av information skickas genom en lätt modifikation av slutprodukten. Den kan dock inte skicka ljud och annan information sam- tidigt, vilket är ett problem. Kommunikationslösningen är nämligen tänkt till världens näst största flyktingläger, Bidi Bidi i Uganda. Där förväntas kommunikation och infor- mation ha olika former i och med att invånarna innehar olika mycket kunskap. Vissa kan läsa, andra inte. Dessutom förväntas produkten vara tålig, billig och lättanvänd så att den kan användas i stor skala. Produkten som tagits fram anses inte vara tillräckligt välfungerande i nuläget för att kunna användas i skarpt läge. Framförallt är hårdvaran opålitlig och dyr om fler enheter ska användas. Mer kunskap och vidareutveckling av produkten behövs därför.

Produkten är baserad på dels Arduino, som är en open source mikrokontroller dels sän- darmoduler kallade nRF24L01+ och diverse andra komponenter. Utöver dessa hård- varukomponenter baseras produkten på klasser designade för sändarmodulerna. Dessa har sedan används för att ta fram ny kod.

Trots att slutprodukten för projektet inte uppfyller de krav som finns för den tänka

applikationen är området som projektet berör intressant. Denna typ av lösning med

mikrokontrollers och sändarmoduler kan användas i diverse vardagssituationer. Ett ex-

empel kan vara att skapa ett nätverk som styr apparater i ett hem. För detta ändamål

kan lösningen fungera bra redan i nuläget. Detta kräver dock att kod skrivs för detta

ändamål.

(4)

Contents

Contents 2

1 Background 4

1.1 Introduction . . . . 4

1.2 Purpose . . . . 4

2 Theory 5 2.1 Hardware . . . . 5

2.1.1 Arduino . . . . 5

2.1.2 nRF24L01+ . . . . 6

2.2 Software . . . . 7

2.2.1 RF24 . . . . 7

2.2.2 RF24Network . . . . 7

2.2.3 RF24Mesh . . . . 8

2.2.4 RF24Audio . . . . 8

3 Method 8 3.1 List of components . . . . 9

3.2 RF24 . . . . 9

3.3 RF24Network . . . . 9

3.3.1 Test class 1 . . . . 9

3.3.2 Test class 2 . . . . 9

3.3.3 Test class 3 . . . . 10

3.3.4 Test class 4 . . . . 10

3.3.5 Range test . . . . 10

3.4 RF24Mesh . . . . 10

3.5 RF24Audio . . . . 10

4 Results 11 4.1 RF24 . . . . 11

4.2 RF24Network . . . . 11

4.2.1 Test class 1 . . . . 11

4.2.2 Test class 2 . . . . 12

4.2.3 Test class 3 . . . . 12

4.2.4 Test class 4 . . . . 13

4.2.5 Range test . . . . 14

4.2.6 General results . . . . 14

(5)

4.3 RF24Mesh . . . . 15

4.4 RF24Audio . . . . 15

5 Discussion 16 5.1 RF24Network . . . . 16

5.2 RF24Mesh . . . . 16

5.3 RF24Audio . . . . 17

5.4 General discussion of solution . . . . 17

6 Conclusion 18 References 19 A Appendices 22 A.1 RF24 test class . . . . 22

A.2 RF24Network test class 1 . . . . 25

A.3 RF24Network test class 2 . . . . 28

A.4 RF24Network test class 3 . . . . 30

A.5 RF24Network test class 4 . . . . 35

A.6 RF24Mesh test class 1 master . . . . 40

A.7 RF24Mesh test class 1 . . . . 41

(6)

1 Background

1.1 Introduction

In a world where conflicts arise forcing unintended migration, the need for refugee camps increases. With over 285000 South Sudanese refugees fleeing the crisis in South Sudan, Bidi Bidi refugee settlement is the second to largest refugee settlement in the world, located in northwestern Uganda [1], [2]. Engineers without borders Uppsala came in contact with a Non-governmental organisation (NGO), called Adventist Development and Relief Agency (ADRA) that works with Bidi Bidi and problems in the settlement were discussed. In present time the communication is carried out by using megaphones on motorbikes and/or by renting the local radio station for an hour or two daily. Not only is this unreliable, it is also economically unsustainable. From that a project idea was formed. The idea is to make communication in Bidi Bidi more reliable and cheaper in order to give the refugees all the information neccesary for their stay.

Therefore the objective is to find an effective, reliable and cheap communication solution for the settlement. With the hopes of making it adaptable for other refugee camps as well. At first the plan was to make use of FM-radio which has been a standard for communication for a long time. However, FM-radio has its’ downsides, such as its’

regulations for the power level and the limited amount of data types one can send.

However, Uwe Zimmermann, Senior Lecturer at Department of Engineering Sciences, Solid State Electronics at Uppsala University, suggested another solution. A solution using the 2.4 GHz frequency band instead of FMs’ 88 − 108 MHz. This solution would enable two way communication, with less regulations and the amount of data types that could be sent would not be as limited. However a few new problems would have to be solved, and that is the purpose of this project.

1.2 Purpose

A communication solution for Bidi Bidi is needed. Being the second largest refugee

settlement in the world with over 285000 refugees and as of 2016 measuring approximately

250 km

2

[3], the solution would have to meet a few requirements. Communication needs

to be available throughout the whole camp. It is essential for every member of the camp

to have the ability to communicate with another, since information streams can come

from anywhere and affect anyone. It is crucial to construct a communication device that

upholds 18 hours of communication a day. To make this possible, the device need to

be built weatherproof and to be able to hold up against any type of climate. It is also

(7)

important that information comes in different formats as the knowledge of the inhabitants of Bidi Bidi is varied.

Because of the limited time and resources of this thesis the end product of this project will not meet all the requirements. Therefore the goal of this project is instead to develop a communications unit which can be used in a network. It also needs to be energy efficient and inexpensive. Hence the end product of this project is intended to be a solution with four nodes where every node can communicate with any other node. A solution which can be expanded to meet the required size. A solution that can send information in the form of signals, text and audio. Lastly, a solution which uses as little energy as a solar panel can produce in a day, and a solution which is affordable.

2 Theory

2.1 Hardware

2.1.1 Arduino

Figure 1: Arduino Uno Rev3 [7].

Arduino is a microcontroller card which is an open source when it comes to both hardware and software. It started of as an easy tool for prototyping but has now reached a wider community. It is designed to be cheap and simple to use [4]. Arduino is built around Atmel AVR [5], which sup- ports both inputs and outputs. It also comes with its’ own integrated develop- ment environment (IDE) and can be pro- grammed with its’ own simplified language of C/C++ [6].

The Arduinos used in this project are Arduino Uno Rev3 shown in figure 1 and Funduino Uno R3. Funduino Uno R3 is one hundred percent compatible with Arduino Uno Rev3 and has the same specifications [8].

In figure 1 the upper row of pins, 0 through 13 are digital pins whereas the lower row of

pins, A0 through A5, are analog pins. All of these pins can be used for inputs or outputs

to and from the board. However some pins have specialised functions. The digital pins

function at either 0 V or 5 V. The analog pins, which have 1024 possible values, function

(8)

between 0 V and 5 V (per default). A USB B port is used for uploading code and for supplying power to the Arduino. Power can also be supplied with a DC connector or a battery. The voltage supply needs to range between 6 V and 20 V. However, if supplied with less than 7 V or more than 12 V the Arduino may not function as it should [9].

2.1.2 nRF24L01+

nRF24L01+ is a transceiver module that can be used with an Arduino. It works in the 2.4 GHz ISM band and frequencies ranges from 2.4 GHz to 2.4835 GHz which are sepa- rated into 126 different channels. nRF24L01+ can handle on-air data rates of 250 kbps, 1 Mbps and 2 Mbps. It is also drop-in compatible with nRF24L01 and on-air compati- ble with nRF2401, nRF2402, nRF24E1 and nRF24E2. The module has a supply range between 1.9 V to 3.6 V [10]. This can be achieved by using a voltage adapter [11]. There are two different module types’, as shown in figure 2, one with the option to add an external antenna and one with an integrated antenna. The module which supports an external antenna will be used in this project. The nRF24L01+ module is connected to the Arduino according to table 1 but the CE and CSN pins can be configured [12].

Table 1: How to connect nRF24L01+ to Arduino Uno Rev 3 and Fundiono Uno R3 [12].

PIN nRF24L01+ Arduino Uno Rev3 Funduino Uno R3

1 GND GND GND

2 V

CC

3.3 V 3.3 V

3 CE digIO 7 digIO 7

4 CSN digIO 8 digIO 8

5 SCK digIO 13 digIO 13

6 MOSI digIO 11 digIO 11

7 MISO digIO 12 digIO 12

8 IRQ - -

(a) nRF24L01+ with integrated antenna [13].

(b) nRF24L01+ with option to add ex- ternal antenna.

Figure 2: The different nRF24L01+ module types’.

(9)

2.2 Software

2.2.1 RF24

RF24 is a library that drives the nRF24L01/nRF24L01+ modules [14], [12]. Other classes use this class as a core library, for example RF24Audio [15], RF24Network and RF24Mesh [16], which will all be covered further below. With this class the user creates the setup for communication by creating a radio object. To send data the class includes methods for creating reading and writing pipes on which data is sent between different addresses.

Other methods include for example radio.available() which checks if there are data packets available to read [17].

2.2.2 RF24Network

00

03 01

011 013 023

0111 0211 0123 0223

Figure 3: Network structure of RF24Network.

RF24Network is a class used to create a network of nodes which can communicate with each other [18]. The routing works similar to how the internet works as the network is built like a tree with a maxi- mum of 3125 nodes [19]. The master node, called 00, is the root of the tree and from there it can branch out into five nodes called 01 through 05. These nodes be- come children of the master and parents to the next layer. Thereafter each parent can branch out into another layer of five

children. For example the children of 03, are called 013, through 053 and similarly for all the other children of the master. Figure 3 shows an example setup of nodes. Even though two nodes, for example 013 and 0211, can theoretically be within each others range, 013 can not communicate with 0211 directly. Communication has to be routed through 03 → 00 → 01 → 011 → 0211. Routing is a feature built in the RF24Network class [20].

When a packet is to be sent from 023 to 011 the user needs to define the packet, the

packet size and the header of its destination [21]. Given that all the required parents

and the master node are active the packet will be routed correctly. A downside to a

tree structure is that the network is exposed to nodes breaking down. For example, if 01

breaks down, there is no way for packets from that branch to reach the 03 branch [20].

(10)

2.2.3 RF24Mesh

1

9

2

3

4

5

7 6 8

Figure 4: Network structure of a mesh net- work.

RF24Mesh is an alternative network solu- tion that is designed to interface directly with RF24Network but works in a different way [22], [16]. The idea is that instead of a static network the mesh can adapt when new nodes enter the network or when a node goes offline. Here each node is given an address and can be connected directly to other nodes as shown in figure 4. These nodes are not constant but instead changes depending on connectivity. This means that if a node, for example node 1 in figure

4, wants to send a data packet to node 3, the packet will be routed through node 2 → 3.

However if node 2 breaks down, node 1 will reconfigure and try to find another node, in this case 9, that can reach the final destination 3 by routing through 9 → 8 → 7 → 5 → 3.

This is called dynamic routing. This type of routing is more reliable compared to the RF24Network class as it works as a mesh, which implies that there is often more than one path between source and destination, as seen in both the example and figure 4. The user defines the destination of the packet and the class routes the packet in the best way possible [23]. This means that a mesh in theory can be more efficient than a tree layout since a packet will not need to be routed through as many nodes. It also means that if a node breaks down, the class will find a new way of routing automatically. One limita- tion of RF24Mesh is however that it only supports 255 nodes compared to RF24Network which supports 3125 nodes [16].

2.2.4 RF24Audio

RF24Audio is a class used to stream audio with nRF24L01(+) modules [24], [15].

3 Method

Various methods were used to investigate different software solutions. Hardware was

installed to meet the requirements of the software. The tests cover different types of

data, input methods and different ways of routing.

(11)

3.1 List of components

• 2 Arduino Uno Rev3

• 2 Funduino Uno R3

• 4 nRF24L01+

• 4 antennas for nRF24L01+

• 4 voltage adapters for nRF24L01+

• 28 male-to-female jumper wires

• 20 buttons

• 20 10 kΩ resistors

• 4 220 Ω resistors

• 4 LED

• multiple male-to-male jumper wires

• 4 USB-B to USB 2.0 cables

3.2 RF24

To comprehend how the nRF24L01+ modules function a class that sends data between two Arduinos was created. Two buttons were installed on each Arduino, one button for turning on an LED on the other Arduino and one button for turning it off. The test was made to learn how information is sent and to test a method of displaying information.

3.3 RF24Network

Based on the theory of RF24Network and its ability to support many nodes, it seemed like a possible solution. In order to understand more thoroughly how RF24Network works, several test classes with different purposes were created.

3.3.1 Test class 1

The first class that was created with RF24Network is similar to the test class made with RF24. The hardware setup was identical and the buttons had the same function. The test was made to see the difference between sending data with RF24 and RF24Network.

3.3.2 Test class 2

The second class is similar to the first one. It connects two nodes with RF24Network but

instead of sending a command, this class sends a String input from the user. The idea is

similar to the LED, having various ways of distributing information due to the variety of

knowledge by the potential users.

(12)

3.3.3 Test class 3

The third class uses the same concepts as the first two but this time combined, i.e.

sending commands and Strings within the same class. Four buttons were installed on each Arduino. The data type was set to a struct, in order to send different types of data at once.

3.3.4 Test class 4

In order to test the routing of packets in a bigger network, the two node network was expanded into a four node network. A test class similar to the first test class was then created. The class sends commands via button presses that turns LEDs on or off in different parts of the network. Buttons were also installed to set destination address.

3.3.5 Range test

Lastly, test class 4 was tested outside for range and routing. Initially with antennas and two nodes. One node was stationary while the other was mobile, moving away radially from the stationary node. The connection was tested by sending button presses from and to the stationary node before the distance was increased. The test was then expanded into three nodes, one that was stationary and two that were moving away from it (each from different network branches). Both tests were then replicated without antennas.

3.4 RF24Mesh

As stated in the theory, RF24Mesh is an alternative to RF24Network. Therefore the intention was to conduct the same test classes as in RF24Network, but this time imple- menting RF24Mesh. The only class that ended up being created is the equivalent of the first RF24Network test class.

3.5 RF24Audio

The purpose of testing RF24Audio was to find out how it functions and if it is possible to implement it with RF24Network and/or RF24Mesh. Therefore the first test was to stream audio by connecting a speaker to one Arduino and an auxiliary port (AUX) to another and running an example class called Getting started [25].

The second test used the same example but it was modified to see what happened after

RF24Audio was started.

(13)

4 Results

4.1 RF24

Figure 5: Circuit sketch for the RF24 class, test class 1 with RF24Network and test class 1 with RF24Mesh [26].

This test class sends an integer array from one Arduino to another Arduino at the press of one of the two buttons. The integer array size is two, the first index indicates that the ’On’ button has been pressed by setting it to 1 and the sec- ond index indicates that the ’Off’ but- ton has been pressed by setting that to 1 . The code is written so that an array value of (1, 1) or (0, 0) is impossible to send. This data is sent to the other Ar- duino by opening a writing and reading pipe on each nRF24L01+ and then writ- ing on that pipe. This only happens when a button has been pressed. The informa- tion is then received and processed so that it turns on an LED at the recipient if the integer array is (1, 0) and turns it off if the

integer array is (0, 1). The code can be found in appendix A.1 and the hardware setup is shown in figure 5. As illustrated, two buttons are installed along with one LED and the nRF24L01+ module. The sketches however do not include the voltage adapter, it is instead illustrated by the 8-pin header.

This test class worked like expected and it worked well. The only problem that occurred was the occasional freezing of the Arduinos. The reason behind this was not found but a reboot solved it temporarily.

4.2 RF24Network

4.2.1 Test class 1

Test class 1 with RF24Network uses the same principles as the RF24 test class. The hardware setup is exactly the same, see figure 5, and the code works in a similar way.

Only two nodes are used at this point, and the nodes are connected by one being the

(14)

others parent, see figure 3 in the theory section. The code for this class can be found in appendix A.2. The class differs from the one with RF24 in that instead of choosing a writing and reading pipe, the code sets the channel for both Arduinos so that they transmit and listen to the same frequencies. Similar to the RF24 test class, the address of the recipient is hard coded. When uploaded the network.begin() method is used and it only takes a few seconds to run. When the class is ready for inputs, a button press will set and send an integer array of size two just like the RF24 class.

When running this class at a short range of approximately 50 cm apart it was shown to be mostly stable and the only complications were a few button failures and freezing similar to the RF24 test class.

4.2.2 Test class 2

Figure 6: Circuit sketch for test class 2 with RF24Network [26].

The second class reads input from the se- rial monitor of each Arduino and saves it into a String. If the String is not empty the variable containing the String is sent to the receiving node, which in return reads and displays the String on its own serial monitor. The String is sent as a char ar- ray which has a maximum size of 64. If a String input is larger than the maximum size, the String is simply cut off at the point of which the String is too large. The code can be found in appendix A.3 and the circuit sketch is shown in figure 6. Similar to the first class only two nodes were used which means that they are connected di- rectly. This class worked well and packets were rarely lost.

4.2.3 Test class 3

The third class is a combination of the previous two, meaning that it reads input from the serial monitor and button pressing. Analogously, the destination was hard coded.

This class uses four buttons. One for LED ON, one for OFF, one to read the input from

the serial monitor and one to send the input from the serial monitor.

(15)

Figure 7: Circuit sketch for test class 3 with RF24Network [26].

The user can also input a String be- fore pressing the third button. Pressing any button except the one that reads the String input, will also trigger the module to send the information over to the receiv- ing node. The recipient reads the incom- ing information and switches the LED ON or OFF and/or prints the String on its se- rial monitor. The code can be found in appendix A.4 and the circuit is shown in figure 7. This class worked as expected but just like before the Arduinos froze oc- casionally.

4.2.4 Test class 4

Figure 8: Circuit sketch for test class 4 with RF24Network [26].

The fourth class took the concept of the first class and expanded it, making it pos- sible for the user to choose its recipient by pressing a button. Since there were four nodes five buttons were installed, one for LED ON, one for OFF and one for each destination. Each destination button has its address set when the user uploads the class, this is because the addresses are de- pendent on which address the user has.

When uploaded the user tests it by first pressing one of the destination buttons.

That sets the destinatiokkn, thereafter the user presses ON or OFF to send. The code for this test class can be found in appendix A.5 and the hardware setup is illustrated in figure 8. The realisation of the sketch is shown in figure 9.

Without the antennas and at short range this worked mostly well, but with antennas it

only worked when one of the nodes was without an antenna. The cause of this was not

found even after trying all the different antennas with all the different Arduinos.

(16)

Figure 9: Hardware setup for test class 4.

However when switching the nRF24L01+ mod- ules between the Arduinos it was clear that one of the modules was malfunctioning, but only when an antenna was connected to it. Just like test class 1 this class also froze occassionally.

4.2.5 Range test

The first outdoor test, with two nodes and an- tennas, showed that the range reached roughly 300 meters (measured with Google maps). At this range both nodes could send and receive information at a relatively stable rate. Mov- ing further away caused packets to be lost at a very high rate. There was clear sight between the nodes and both nodes were at a height of

roughly 1 meter above ground. The same test without antennas showed that the range reached roughly 28 meters.

The second outdoor test with all four nodes was very unsuccessful. The stationary node, 00 , could send and receive to and from two of the other nodes, 02 and 012, but nothing could be sent or received from node 05 when the antennas were used. When the antenna from node 05 was taken off it could receive and send data but the range was less than 28 meters. Node 05 also displayed a lot of freezing both with and without the antenna. At this point one of the other modules started to malfunction as well which meant the test with antennas would not yield any useful results. Without the antennas the four node test worked, except for when 05 froze. However, the range was very low and also varied between the nodes. Node 02 reached a distance of about 28 meters (like the previous test) from 00 (stationary) whereas 05 could only reach a distance of about 14 meters from 00 before packets were lost at a very high rate.

4.2.6 General results

One of the reoccurring problems for all of the different test classes is the freezing. Some-

times, after running a class for a while, the program freezes and can not take any more

inputs. Neither a button press or a String input from the serial monitor is registered and

sent. Even though a lot of debugging of the code and hardware was done an explanation

was never found. This problem also seemed to occur more often with some Arduinos

than others, even though the circuits connected to each board were identical.

(17)

4.3 RF24Mesh

The first class, test class 1, that was created was a button press class that should work similar to RF24Network test class 1. The class never successfully worked even after alterations. In lack of time a decision was made to move on.

Another attempt at creating the class was made at the end of the project, this time with success. A two node mesh network was possible to use if and only if one of them were the master node. Otherwise there had to be three nodes, one master and two other nodes.

In the case of the three node network the master was only needed for management of the mesh. The code for the master node can be seen in appendix A.6. The only important part in the master node class was to call mesh.update() and mesh.DHCP() regularly. The hardware setup for the master is the same as in RF24Network test class 2, see figure 6.

The other two nodes have code and hardware that works similar to RF24Network test class 1. The hardware setup is exactly the same, see figure 5 and the code can be found in appendix A.7. The buttons also have the same functions as in RF24Network test class 1 and sending data has similarities. The only difference is that mesh.write() is used instead of network.write() and if it fails to send data, it checks to see if it is still connected to the mesh. If the node fails to send because it is not connected, it runs mesh.renewAddress() which renews its address with the help of the master.

No attempts at making test class 2, 3 and 4 with RF24Mesh were made since there was not enough time, same regarding an attempt at expanding the class so that a mesh could uphold more than 255 nodes.

4.4 RF24Audio

The first test class showed that streaming sound was possible and simple to do. The node which was equipped with an AUX only had to initialise the radio and then sound could be played and streamed. The receiving Arduino with the speaker simply had to start listening and everything worked like expected. The code used was a example class called Getting started [25]. The sound quality was good enough for speech but there was noise.

The second test was unsuccessful. It was based on Getting started [25] but a print to the

serial monitor each loop was added. The print showed that once RF24Audio was initiated

it stopped looping. This means that once it is initiated nothing except RF24Audio could

run at the same time. Therefore no other types of data could be either sent nor received.

(18)

5 Discussion

5.1 RF24Network

The theory of RF24Network looked both promising and concerning. The amount of possible nodes on each channel was the main reason why RF24Network was the prime candidate for the communications network in the refugee camp. However the tree struc- ture of the network is concerning as it means that every device needs to be very reliable in terms of connectivity. There was not enough time to develop a way of solving the issue of nodes breaking down. But a way to handle this was thought of. When a node within the tree (a node which is a parent to at least one node) breaks down it somehow needs to be replaced, otherwise all traffic to and from that branch will be lost. One possible solution could be that the connection is always checked. Whenever connection is lost between a node and either its parent or child for a period of time, one of its children could take its’ place by changing node address. For example, when 02 goes down and is down for 5 minutes, 012 could change its’ address to 02 temporarily. However, this solution only works if the nodes are close together, which might not always be case.

In the results one can see that most of the tests of RF24Network were successful. A class which could send both commands and Strings at the same time was developed, as well as a class which could choose the destination node in a simple way.

5.2 RF24Mesh

As seen in the results and theory section RF24Mesh came with a few disadvantages.

Firstly, the amount of possible nodes are too few to cover the whole camp, which means that the class has to be modified for it to work. However, as seen in the results, such a modification has not been implemented in this project. The reason being is because of other problems that occurred in the initial testing of the class. When RF24Mesh was first tested with a button press class it was not successfully working, even after a lot debugging.

As can be seen in the results, the reattempt at creating the test class was successful. It

was clear that the problem before was that there was no master node. However, it only

worked when mesh.DHCP() was called regularly by the master node. This brought a new

problem to attention, the master node seems to be crucial for the mesh to work. When

there is no master node to manage the mesh, nothing else works. This should not be

necessary in a mesh network.

(19)

5.3 RF24Audio

RF24Audio worked well when it was used alone and it was very simple to setup. However, it did not work in combination with RF24Network nor RF24Mesh i.e they could not be run at the same time. This is a problem for the application of this project since there needs to be various ways to distribute information. This is because of varied knowledge by the potential users.

This problem can probably be solved by redesigning RF24Audio and RF24Network into one combined class. But that would require a lot more time and knowledge.

5.4 General discussion of solution

The results of this project has shown how nRF24L01+ can be used and how to use them.

It has also shown the limitations and highlighted the problems that needs to be solved for it to work. The purpose of the project was to develop a communications solution between four nodes with communication being possible between all nodes. The solution also had to be expandable to cover the whole refugee camp, inexpensive and energy efficient.

Instead the results has shown that nRF24L01+ has a few problems that are considered to be unacceptable for refugee camps. The biggest issue was that the antennas did not work with all of the modules. This is a big problem as the range without the antennas according to the results reached roughly 28 meters. There is probably an explanation for the antennas malfunctioning but after many attempts to find it, none could be found.

Another issue that the results showed was that the Arduinos occasionally froze. The reason behind this was never found.

Even if the explanations for these problems are found and the problems are solved there is still a lot of work that needs to be done before the communication solution meets all the requirements. The Arduino board is too expensive for a large scale network which means that a cheaper, streamlined version, needs to be used. It also needs to be possible to send audio and other types of data at the same time. Alternatively find a workaround. Because of these issues a decision was made that the energy consumption of this temporary solution was not of interest as there is much else that is missing and that is not working.

Which of RF24Network or RF24Mesh should be used in the future is not one hundred

percent clear. This project has come furthest with RF24Network, but as RF24Mesh is

designed to interface directly with RF24Network it should be far easier to create classes

similar to RF24Networks test class 2, 3 and 4 using RF24Mesh. Therefore the choice be-

tween them is right now only dependent on the size of the network, in which RF24Network

(20)

is far superior, unless RF24Mesh can be expanded somehow.

6 Conclusion

This project has led to a lot of knowledge and insight about programming of Arduinos and the nRF24L01+ modules, but the end product is not as planned. The closest to an end product the project has achieved is a unit which can choose address from a list of three and send a command to that address. A way to send Strings to a unit has also been developed, however that requires a computer and may not be possible to implement at every node in future applications. One of the most important parts of the end product was the ability to send many types of data at the same time, namely audio, text and commands and the project has achieved only two. A way to stream audio has been found but it only works by itself. Because of the lack of completeness of the end product an investigation of the energy use and the cost has not been made.

Other than the end product a few insights about this type of solution have been gained.

The nRF24L01+ modules are unreliable which means that unless that can be fixed, they

are not suitable for this application. Despite the modules being unreliable further research

needs to be made. To dismiss or accept this solution one needs to know what causes the

problems with antennas and if and how it can be fixed.

(21)

References

[1] UNHCR [Internet]. UNHCR; 2018-04-25. Uganda Country Refugee Response Plan.

Available from: https://data2.unhcr.org/en/documents/details/63273, (2018- 06-07)

[2] Beaubien, Jason. Monsoon Rains Could Devastate Rohingya Camps. Na- tional Public Radio [Internet]. 2018-02-07. Available from: https://www.npr.

org/sections/goatsandsoda/2018/02/07/583419363/monsoon-rains-could- devastate-rohingya-camps , (2018-05-29)

[3] Leithead, Alastair. South Sudan refugee crisis: The wooden bridge between death and safety . BBC News [Internet]. 2016-12-16. Available from: https://www.bbc.com/

news/world-africa-38328811 , (2018-06-07)

[4] Arduino [Internet]. Arduino; 2018. What is Arduino? Available from: https://

www.arduino.cc/en/Guide/Introduction , (2018-05-17)

[5] Arduino [Internet]. Arduino; 2018. AVR Code. Available from: https://

playground.arduino.cc/Main/AVR , (2018-05-17)

[6] Arduino [Internet]. Arduino; 2018. Frequently Asked Questions. https://www.

arduino.cc/en/Main/FAQ , (2018-05-17)

[7] Arduino. Arduino; 2018. Arduino Uno Rev3 [Image on internet]. Available from: https://store-cdn.arduino.cc/uni/catalog/product/cache/1/image/

1000x750/f8876a31b63532bbba4e781c30024a0a/a/0/a000066_front_1.jpg , (2018- 05-22)

[8] Eezone [Internet]. Eezone; 2018. Funduino Uno R3 – ATmega328P. Available from:

http://eezone.co.uk/blog/arduino/funduino-uno-r3-atmega328p.html , (2018- 05-18)

[9] Arduino [Internet]. Arduino; 2018. Arduino Uno Rev3: documentation. Available from: https://store.arduino.cc/arduino-uno-rev3, (2018-05-17)

[10] Nordic Semiconductor [Internet]. Nordic Semiconductors; 2008. nRF24L01+ Sin- gle Chip 2.4GHz Transceiver . Available from: https://www.nordicsemi.com/eng/

Products/2.4GHz-RF/nRF24L01P , (2018-05-18)

[11] m.nu [Internet]. m.nu; 2017-06-12. Socket/Voltage Adapter for 8Pin NRF24L01.

Available from: https://www.m.nu/breakout-boards/socket-voltage-adapter-

for-8pin-nrf24l01 , (2018-05-18)

(22)

[12] GitHub [Internet]. Tmrh20; 2016-11-05. Optimized High Speed Driver for nRF24L01(+) 2.4GHz Wireless Transceiver . Available from: https://tmrh20.

github.io/RF24/ , (2018-05-24)

[13] m.nu. m.nu. nRF24L01+ [Image on internet]. Available from: https://images.m.

nu/data/product/1076f860/no_name_nrf24l01.jpg , (2018-05-22)

[14] GitHub [Internet]. Tmrh20; 2018-05-05. nRF24 / RF24. Available from: https:

//github.com/nRF24/RF24 , (2018-04-01)

[15] GitHub [Internet]. Tmrh20; 2014-04-27. RF24Audio - Realtime Audio Streaming Library for Arduino . Available from: https://tmrh20.github.io/RF24Audio/, (2018- 05-24)

[16] GitHub [Internet]. Tmrh20; 2015-11-27. Mesh Networking Layer for RF24 Radios.

Available from: https://tmrh20.github.io/RF24Mesh/, (2018-05-24)

[17] GitHub [Internet]. Tmrh20; 2016-11-05. RF24 Class Reference. Available from:

http://tmrh20.github.io/RF24/classRF24 , (2018-05-24)

[18] GitHub [Internet]. Tmrh20; 2018-05-05. nRF24 / RF24Network. Available from:

https://github.com/nRF24/RF24Network , (2018-04-09)

[19] GitHub [Internet]. Tmrh20; 2016-09-20. Network Layer for RF24 Radios. Available from: https://tmrh20.github.io/RF24Network/, (2018-05-24)

[20] GitHub [Internet]. Tmrh20; 2016-09-20. Performance and Data Loss: Tuning the Network . Available from: http://tmrh20.github.io/RF24Network/Tuning, (2018- 05-24)

[21] GitHub [Internet]. Tmrh20; 2016-09-20. RF24Network Class Reference. Available from: https://tmrh20.github.io/RF24Network/classRF24Network, (2018-05-24) [22] GitHub [Internet]. Tmrh20; 2018-02-27. nRF24 / RF24Mesh. Available from:

https://github.com/nRF24/RF24Mesh , (2018-04-05)

[23] Cisco Networking Academy [Internet]. Cisco Network Academy; 2014-03-23.

Cisco Networking Academy’s Introduction to Routing Dynamically . Available from:

http://www.ciscopress.com/articles/article.asp?p=2180210&seqNum=4 , (2018- 05-24)

[24] GitHub [Internet]. Tmrh20; 2016-08-15. nRF24 / RF24Audio. Available from:

https://github.com/nRF24/RF24Audio , (2018-05-02)

[25] GitHub [Internet]. Tmrh20; 2016-08-15. RF24Audio / examples. Available from:

https://github.com/nRF24/RF24Audio/tree/master/examples , (2018-05-10)

(23)

[26] Autodesk Tinkercad [Internet]. Autodesk; 2018. Circuits has arrived on Tinker-

cad . Available from: https://www.tinkercad.com/circuits, (2018-05-20)

(24)

A Appendices

A.1 RF24 test class

1

#i n c l u d e <SPI . h>

#i n c l u d e <RF24 . h>

3

RF24 radio (7 , 8) ; // CE & CSN radio pins to use

5

const byte address [ ] [ 6 ] = {" 00001 " , " 00002 " } ; // Define a d d r e s s e s

7

const i n t LED = 2 ; // Define LED pin

9

const i n t buttons [ 2 ] = {5 , 6 } ; // Define button pins

11

i n t l o c al B u t t o n S t a t e [ 2 ] ; // Local button array i n t incButtonState [ 2 ] ; // Incoming button array

13

bool sendButtonState ( ) ; // Declare f u n c t i o n f o r sending button s t a t e

15

void setLED ( ) ; // Declare f u n c t i o n f o r r e c e i v i n g and s e t t i n g LED

17

/∗∗

19

∗ Setup code here , to run once :

∗/

21

void setup ( ) {

S e r i a l . begin (115200) ;

23

SPI . begin ( ) ; // Bring up the RF network radi o . begin ( ) ;

25

radi o . openWritingPipe ( address [ 0 ] ) ; // Write on 00001 radi o . openReadingPipe (1 , address [ 1 ] ) ; // Read on 00002

27

radi o . setPALevel (RF24_PA_MIN) ; // Set t r a n s m i s s i o n power l e v e l

29

pinMode (LED, OUTPUT) ;

31

pinMode ( buttons [ 0 ] , INPUT) ; pinMode ( buttons [ 1 ] , INPUT) ;

33

}

35

/∗∗

∗ Loop code here , to run r e p e a t e d l y

37

∗/

void loop ( ) {

39

radi o . s t o p L i s t e n i n g ( ) ; // Stop l i s t e n i n g

41

/∗∗

∗ I f −statement that runs when one o f the buttons has been

(25)

43

∗ pressed . When pressed the sendButtonState ( ) f u n c t i o n

∗ runs . Another i f − statement that p r i n t s to the

45

∗ s e r i a l monitor weather sendButtonState ( ) r e t u r n s true or

∗ f a l s e

47

∗/

i f ( d i g i t a l R e a d ( buttons [ 0 ] ) == HIGH | | d i g i t a l R e a d ( buttons [ 1 ] ) == HIGH) {

49

i f ( sendButtonState ( ) ) {

S e r i a l . p r i n t l n ( " Payload sent " ) ;

51

}

e l s e {

53

S e r i a l . p r i n t l n ( "∗∗∗ Payload not sent ∗∗∗" ) ; }

55

}

delay ( 5) ;

57

radi o . s t a r t L i s t e n i n g ( ) ; // Start l i s t e n i n g f o r incoming message

59

/∗∗

61

∗ I f −statement that runs setLED ( ) i f radio . a v a i l a b l e ( ) i s true .

∗/

63

i f ( radio . a v a i l a b l e ( ) ) { setLED ( ) ;

65

}

delay ( 5) ;

67

}

69

/∗∗

∗ Function c a l l e d sendButtonState ( ) that s e t s the button

71

∗ s t a t e and w r i t e s on the piped that was d e f i n e d b e f o r e

∗/

73

bool sendButtonState ( ) {

i f ( d i g i t a l R e a d ( buttons [ 0 ] ) == HIGH) {

75

l o c al B u t t o n S t a t e [ 0 ] = HIGH;

l o c al B u t t o n S t a t e [ 1 ] = LOW;

77

S e r i a l . p r i n t ( "Button 1 (ON BUTTON) : " ) ; S e r i a l . p r i n t l n ( l o c a l B u t t o n S t a t e [ 0 ] ) ;

79

S e r i a l . p r i n t ( "Button 2 (OFF BUTTON) : " ) ; S e r i a l . p r i n t l n ( l o c a l B u t t o n S t a t e [ 1 ] ) ;

81

i f ( rad io . wri te (& localButtonState , s i z e o f ( l o c a l B u t t o n S t a t e ) ) ) {

83

return true ;

}

85

e l s e {

return f a l s e ;

87

}

}

(26)

e l s e i f ( d i g i t a l R e a d ( buttons [ 1 ] ) == HIGH) {

91

l o c al B u t t o n S t a t e [ 0 ] = LOW;

l o c al B u t t o n S t a t e [ 1 ] = HIGH;

93

S e r i a l . p r i n t ( "Button 1 (ON BUTTON) : " ) ; S e r i a l . p r i n t l n ( l o c a l B u t t o n S t a t e [ 0 ] ) ;

95

S e r i a l . p r i n t ( "Button 2 (OFF BUTTON) : " ) ; S e r i a l . p r i n t l n ( l o c a l B u t t o n S t a t e [ 1 ] ) ;

97

i f ( rad io . wri te (& localButtonState , s i z e o f ( l o c a l B u t t o n S t a t e ) ) ) {

99

return true ;

}

101

e l s e {

return f a l s e ;

103

}

}

105

}

107

/∗∗

∗ Function c a l l e d setLED ( ) that reads from the reading pipe

109

∗ that was d e f i n e d b e f o r e . incButtonState i s s e t to the

∗ value o f the incoming data . I f −statements then determines

111

∗ whether the LED should be turned On or Off .

∗/

113

void setLED ( ) {

while ( radi o . a v a i l a b l e ( ) ) {

115

radi o . read(&incButtonState , s i z e o f ( incButtonState ) ) ; i f ( incButtonState [ 0 ] == HIGH) {

117

d i g i t a l W r i t e (LED, HIGH) ;

S e r i a l . p r i n t l n ( "Turn LED ON" ) ;

119

}

i f ( incButtonState [ 1 ] == HIGH) {

121

d i g i t a l W r i t e (LED, LOW) ;

S e r i a l . p r i n t l n ( "Turn LED OFF" ) ;

123

}

}

125

}

(27)

A.2 RF24Network test class 1

1

#i n c l u d e <RF24Network . h>

#i n c l u d e <RF24 . h>

3

#i n c l u d e <SPI . h>

5

RF24 radio ( 7 , 8 ) ; // CE & CSN radio pins to use RF24Network network ( radio ) ;

7

// These are the Octal a d d r e s s e s that w i l l be as s i g n e d

9

const uint16_t node_address_set [ 1 0 ] = {00 , 02 , 05 , 012 , 015 , 022 , 025 , 032 , 035 , 045};

11

// Use numbers 0 through to s e l e c t an address from the array uint8_t NODE_ADDRESS = 1 ;

13

uint8_t END_NODE_ADDRESS = 0 ;

15

uint16_t this_node ; // Our node address

uint16_t other_node ; // The other node address

17

const i n t LED = 2 ; // Define LED pin

19

const i n t buttons [ 2 ] = {5 , 6 } ; // Define button pins i n t l o c al B u t t o n S t a t e [ 2 ] ; // Local button array

21

s t r u c t inc_payload_t { // Incoming payload

23

i n t incButtonState [ 2 ] ; // Incoming button array } ;

25

bool outgoingButtonState ( ) ; // Declare f u n c t i o n f o r sending button s t a t e

27

void incomingButtonState ( ) ; // Declare f u n c t i o n f o r reading // the incoming button s t a t e

29

/∗∗

31

∗ Setup code here , to run once :

∗/

33

void setup ( ) {

S e r i a l . begin (115200) ;

35

S e r i a l . p r i n t l n ( "RF24Network t e s t c l a s s 1" ) ;

37

this_node = node_address_set [NODE_ADDRESS] ; // Which node are we?

other_node = node_address_set [END_NODE_ADDRESS] ; // Which node are they ?

39

SPI . begin ( ) ; // Bring up the RF network

41

radi o . begin ( ) ;

network . begin (/∗ channel ∗/ 100 , /∗ node address ∗/ this_node ) ;

(28)

45

pinMode (LED, OUTPUT) ;

pinMode ( buttons [ 0 ] , INPUT) ;

47

pinMode ( buttons [ 1 ] , INPUT) ; }

49

/∗∗

51

∗ Loop code here , to run r e p e a t e d l y

∗/

53

void loop ( ) {

network . update ( ) ; // Update the network r e g u l a r l y

55

/∗∗

57

∗ I f −statement that runs when one o f the buttons has been

∗ pressed . When pressed the outgoingButtonState ( ) f u n c t i o n

59

∗ runs . Another i f − statement that p r i n t s to the

∗ s e r i a l monitor whether outgoingButtonState ( ) r e t u r n s true or

61

∗ f a l s e

∗/

63

i f ( d i g i t a l R e a d ( buttons [ 0 ] ) == HIGH | | d i g i t a l R e a d ( buttons [ 1 ] ) == HIGH) { i f ( outgoingButtonState ( ) ) {

65

S e r i a l . p r i n t l n ( " Payload sent " ) ; S e r i a l . p r i n t ( " Desti na tio n node : " ) ;

67

S e r i a l . p r i n t l n ( other_node ) ; }

69

e l s e {

S e r i a l . p r i n t l n ( "∗∗∗ Payload not sent ∗∗∗" ) ;

71

}

73

}

delay ( 5) ;

75

/∗∗

77

∗ I f −statement that runs incomingButtonState ( ) i f network . a v a i l a b l e ( ) i s

∗ true .

79

∗/

i f ( network . a v a i l a b l e ( ) ) {

81

incomingButtonState ( ) ; }

83

delay ( 5) ; }

85

/∗∗

87

∗ Function c a l l e d outgoingButtonState ( ) that s e t s the button

∗ s t a t e and w r i t e s the payload to i t s ’ d e s t i n a t i o n

89

∗/

bool outgoingButtonState ( ) {

(29)

91

i f ( d i g i t a l R e a d ( buttons [ 0 ] ) == HIGH) { l o c al B u t t o n S t a t e [ 0 ] = HIGH;

93

l o c al B u t t o n S t a t e [ 1 ] = LOW;

S e r i a l . p r i n t ( "Button 1 (ON BUTTON) : " ) ;

95

S e r i a l . p r i n t l n ( l o c a l B u t t o n S t a t e [ 0 ] ) ; S e r i a l . p r i n t ( "Button 2 (OFF BUTTON) : " ) ;

97

S e r i a l . p r i n t l n ( l o c a l B u t t o n S t a t e [ 1 ] ) ;

99

RF24NetworkHeader header (/∗ to node ∗/ other_node ) ;

i f ( network . write ( header , &localButtonState , s i z e o f ( l oc a l B u t t o n S t a t e ) ) ) {

101

return true ;

}

103

e l s e {

return f a l s e ;

105

}

}

107

e l s e i f ( d i g i t a l R e a d ( buttons [ 1 ] ) == HIGH) { l o c al B u t t o n S t a t e [ 1 ] = HIGH;

109

l o c al B u t t o n S t a t e [ 0 ] = LOW;

S e r i a l . p r i n t ( "Button 1 (ON BUTTON) : " ) ;

111

S e r i a l . p r i n t l n ( l o c a l B u t t o n S t a t e [ 0 ] ) ; S e r i a l . p r i n t ( "Button 2 (OFF BUTTON) : " ) ;

113

S e r i a l . p r i n t l n ( l o c a l B u t t o n S t a t e [ 1 ] ) ;

115

RF24NetworkHeader header (/∗ to node ∗/ other_node ) ;

i f ( network . write ( header , &localButtonState , s i z e o f ( l oc a l B u t t o n S t a t e ) ) ) {

117

return true ;

}

119

e l s e {

return f a l s e ;

121

}

}

123

}

125

/∗∗

∗ Function c a l l e d incomingButtonState that reads the incoming payload

127

∗ I f −statements then determines whether the LED should be turned On or Off

∗/

129

void incomingButtonState ( ) { while ( network . a v a i l a b l e ( ) ) {

131

RF24NetworkHeader header2 ;

inc_payload_t payload ; // Create the incoming payload

133

network . read ( header2 , &payload , s i z e o f ( payload ) ) ; i f ( payload . incButtonState [ 0 ] == HIGH) {

d i g i t a l W r i t e (LED, HIGH) ;

(30)

S e r i a l . p r i n t l n ( "Turn LED ON" ) ;

137

}

i f ( payload . incButtonState [ 1 ] == HIGH) {

139

d i g i t a l W r i t e (LED, LOW) ;

S e r i a l . p r i n t l n ( "Turn LED OFF" ) ;

141

}

}

143

}

A.3 RF24Network test class 2

1

#i n c l u d e <SPI . h>

#i n c l u d e <RF24 . h> // Include the RF24 l i b r a r y

3

#i n c l u d e <RF24Network . h>

5

RF24 radio (7 , 8) ; // CE & CSN radio pins to use RF24Network network ( radio ) ;

7

// These are the Octal a d d r e s s e s that w i l l be as s i g n e d

9

const uint16_t node_address_set [ 1 0 ] = {00 , 02 , 05 , 012 , 015 , 022 , 025 , 032 , 035 , 045};

11

// Use numbers 0 through to s e l e c t an address from the array uint8_t NODE_ADDRESS = 1 ;

13

uint8_t END_NODE_ADDRESS = 0 ;

15

uint16_t this_node ; // Our node address

uint16_t other_node ; // The other node address

17

s t r u c t inc_payload_t { // Incoming paylod

19

char incText [ 6 4 ] = "" ; // Incomoing char array with t e x t } ;

21

s t r u c t out_payload_t { // Outgoing payload

23

char outText [ 6 4 ] = "" ; // Outgoing char array with t e xt } ;

25

out_payload_t outPayload ; // Create the outgoing payload

27

29

bool s e n d S t r i n g s ( ) ; // Declare f u n c t i o n f o r sending S t r i n g

31

void r e a d S t r i n g s ( ) ; // Declare f u n c t i o n f o r reading S t r i n g

(31)

33

/∗∗

∗ Setup code here , to run once :

35

∗/

void setup ( ) {

37

S e r i a l . begin (115200) ;

S e r i a l . p r i n t l n ( "RF24Network t e s t c l a s s 2" ) ;

39

this_node = node_address_set [NODE_ADDRESS] ; // Which node are we?

41

other_node = node_address_set [END_NODE_ADDRESS] ; // Which node are they ?

43

SPI . begin ( ) ; // Bring up the RF network radi o . begin ( ) ;

45

network . begin (/∗ channel ∗/ 100 , /∗ node address ∗/ this_node ) ; radi o . setPALevel (RF24_PA_MIN) ;

47

}

49

/∗∗

∗ Loop code here , to run r e p e a t e d l y

51

∗/

void loop ( ) {

53

// put your main code here , to run r e p e a t e d l y : network . update ( ) ; // Update the network r e g u l a r l y

55

delay ( 5) ;

57

/∗∗

∗ I f −statement that runs when s e n d S t r i n g s r e t u r n s true

59

∗/

i f ( s e n d S t r i n g s ( ) ) {

61

S e r i a l . p r i n t ( "To " ) ; S e r i a l . p r i n t ( other_node ) ;

63

S e r i a l . p r i n t ( " : " ) ;

S e r i a l . p r i n t l n ( outPayload . outText ) ;

65

}

delay ( 5) ;

67

/∗∗

69

∗ I f −statement that runs incomingButtonPress ( ) i f network . a v a i l a b l e ( ) i s true

∗/

71

i f ( network . a v a i l a b l e ( ) ) { r e a d S t r i n g s ( ) ;

73

}

delay ( 5) ;

75

}

77

/∗∗

∗ Function c a l l e d s e n d S t r i n g s ( ) that reads the input from

(32)

79

∗ the s e r i a l monitor and w r i t e s the payload to i t s ’

∗ d e s t i n a t i o n

81

∗/

bool s e n d S t r i n g s ( ) {

83

S t r i n g message = S e r i a l . r ea d S tr i n g ( ) ; i f ( message != "" ) {

85

char copy [ message . length ( ) + 1 ] ;

message . toCharArray ( copy , message . length ( ) + 1) ;

87

strcpy ( outPayload . outText , copy ) ;

RF24NetworkHeader header (/∗ to ∗/ other_node ) ;

89

i f ( network . write ( header , &outPayload , s i z e o f ( outPayload ) ) ) { return true ;

91

}

e l s e {

93

S e r i a l . p r i n t l n ( "∗∗∗ Message not d e l i v e r e d ∗∗∗" ) ; return f a l s e ;

95

}

}

97

e l s e {

return f a l s e ;

99

}

}

101

/∗∗

103

∗ Function c a l l e d r e a d S t r i n g s ( ) , that reads the incoming

∗ message

105

∗/

void r e a d S t r i n g s ( ) {

107

while ( network . a v a i l a b l e ( ) ) { RF24NetworkHeader header2 ;

109

inc_payload_t incPayload ; // Create the incoming payload network . read ( header2 , &incPayload , s i z e o f ( incPayload ) ) ;

111

S e r i a l . p r i n t ( "From " ) ; S e r i a l . p r i n t ( other_node ) ;

113

S e r i a l . p r i n t ( " : " ) ;

S e r i a l . p r i n t l n ( incPayload . incText ) ;

115

}

}

A.4 RF24Network test class 3

#i n c l u d e <RF24Network . h>

2

#i n c l u d e <RF24 . h> // Include the RF24 l i b r a r y

#i n c l u d e <SPI . h>

(33)

4

RF24 radio ( 7 , 8 ) ; // CE & CSN radio pins to use

6

RF24Network network ( radio ) ;

8

// These are the Octal a d d r e s s e s that w i l l be as s i g n e d

const uint16_t node_address_set [ 1 0 ] = {00 , 02 , 05 , 012 , 015 , 022 , 025 , 032 , 035 , 045};

10

// Use numbers 0 through to s e l e c t an address from the array

12

uint8_t NODE_ADDRESS = 3 ; uint8_t END_NODE_ADDRESS = 1 ;

14

uint16_t this_node ; // Our node address

16

uint16_t other_node ; // The other node address

18

const i n t LED = 2 ; // Define LED pin

const i n t buttons [ 4 ] = {3 , 4 , 5 , 6 } ; // Define button pins

20

s t r u c t out_payload_t { // Outgoing payload

22

i n t outButtonState [ 2 ] ; // Outgoing button array char outText [ 6 4 ] ; // Outgoing char array with t e x t

24

} ;

26

out_payload_t outPayload ;

28

s t r u c t inc_payload_t { // Incoming payload

i n t incButtonState [ 2 ] ; // Incoming button array

30

char incText [ 6 4 ] ; // Incomoing char array with t e xt } ;

32

void setButtonState ( ) ; // Declare f u n c t i o n f o r s e t t i n g the outgoing button

s t a t e // s t a t e s

34

void s e t S t r i n g ( ) ; // Declare f u n c t i o n f o r s e t t i n g the outgoing S t r i n g

36

void sendPayload ( ) ; // Declare f u n c t i o n f o r sending the payload

38

void incomingPayload ( ) ; // Declare f u n c t i o n f o r reading the payload

40

/∗∗

42

∗ Setup code here , to run once :

∗/

44

void setup ( ) {

S e r i a l . begin (115200) ;

46

S e r i a l . p r i n t l n ( "RF24Network t e s t c l a s s 3" ) ;

this_node = node_address_set [NODE_ADDRESS] ; // Which node are we?

(34)

other_node = node_address_set [END_NODE_ADDRESS] ; // Which node are they ?

50

SPI . begin ( ) ; // Bring up the RF network

52

radi o . begin ( ) ;

network . begin (/∗ channel ∗/ 100 , /∗ node address ∗/ this_node ) ;

54

radi o . setPALevel (RF24_PA_MIN) ;

56

pinMode (LED, OUTPUT) ;

f o r ( i n t i = 0 ; i < s i z e o f ( buttons ) / s i z e o f ( i n t ) ; i++) {

58

pinMode ( buttons [ i ] , INPUT) ; }

60

}

62

/∗∗

∗ Loop code here , to run r e p e a t e d l y

64

∗/

void loop ( ) {

66

network . update ( ) ; // Update the network r e g u l a r l y

68

/∗∗

∗ I f −statement that runs when one o f the buttons has been

70

∗ pressed . When pressed the setButtonState ( ) f u n c t i o n

∗ runs

72

∗/

i f ( d i g i t a l R e a d ( buttons [ 0 ] ) == HIGH | | d i g i t a l R e a d ( buttons [ 1 ] ) == HIGH) {

74

setButtonState ( ) ; }

76

/∗∗

78

∗ I f −statement that runs when the button has been

∗ pressed . When pressed the s e t S t r i n g ( ) f u n c t i o n

80

∗ runs

∗/

82

i f ( d i g i t a l R e a d ( buttons [ 2 ] ) == HIGH) { s e t S t r i n g ( ) ;

84

}

86

/∗∗

∗ I f −statement that runs when one o f the buttons has been

88

∗ pressed . When pressed the sendPayload ( ) f u n c t i o n

∗ runs

90

∗/

i f ( d i g i t a l R e a d ( buttons [ 3 ] ) == HIGH | | d i g i t a l R e a d ( buttons [ 1 ] ) == HIGH | | d i g i t a l R e a d ( buttons [ 0 ] ) == HIGH) {

92

sendPayload ( ) ; }

94

delay ( 5) ;

(35)

96

/∗∗

∗ I f −statement that runs incomingPayload ( ) i f network . a v a i l a b l e ( ) i s true

98

∗/

i f ( network . a v a i l a b l e ( ) ) {

100

incomingPayload ( ) ; }

102

delay ( 5) ; }

104

/∗∗

106

∗ Function c a l l e d setButtonState ( ) that s e t s the button

∗ s t a t e f o r the LED on the other node

108

∗/

void setButtonState ( ) {

110

i f ( d i g i t a l R e a d ( buttons [ 0 ] ) == HIGH) { outPayload . outButtonState [ 0 ] = HIGH;

112

outPayload . outButtonState [ 1 ] = LOW;

S e r i a l . p r i n t ( "Button 0 : " ) ;

114

S e r i a l . p r i n t l n ( outPayload . outButtonState [ 0 ] ) ; S e r i a l . p r i n t ( "Button 1 : " ) ;

116

S e r i a l . p r i n t l n ( outPayload . outButtonState [ 1 ] ) ;

118

}

e l s e i f ( d i g i t a l R e a d ( buttons [ 1 ] ) == HIGH) {

120

outPayload . outButtonState [ 1 ] = HIGH;

outPayload . outButtonState [ 0 ] = LOW;

122

S e r i a l . p r i n t ( "Button 0 : " ) ;

S e r i a l . p r i n t l n ( outPayload . outButtonState [ 0 ] ) ;

124

S e r i a l . p r i n t ( "Button 1 : " ) ;

S e r i a l . p r i n t l n ( outPayload . outButtonState [ 1 ] ) ;

126

}

}

128

/∗∗

130

∗ Function c a l l e d s e t S t r i n g ( ) that reads the input from the

∗ s e r i a l monitor

132

∗/

void s e t S t r i n g ( ) {

134

S t r i n g message = S e r i a l . r ea d S tr i n g ( ) ; i f ( message != "" ) {

136

char messageCopy [ message . length ( ) + 1 ] ;

message . toCharArray ( messageCopy , message . length ( ) + 1) ;

138

strcpy ( outPayload . outText , messageCopy ) ;

S e r i a l . p r i n t ( "Message to be sent : " ) ;

S e r i a l . p r i n t l n ( outPayload . outText ) ;

(36)

}

142

}

144

/∗∗

∗ Function c a l l e d sendPayload ( ) that w r i t e s the payload to i t s ’

146

∗ d e s t i n a t i o n

∗/

148

void sendPayload ( ) {

RF24NetworkHeader header (/∗ to node ∗/ other_node ) ;

150

i f ( network . write ( header , &outPayload , s i z e o f ( outPayload ) ) ) { S e r i a l . p r i n t l n ( "∗∗∗ Sending payload ∗∗∗" ) ;

152

return true ;

}

154

e l s e {

S e r i a l . p r i n t l n ( "### Payload NOT sent ###" ) ;

156

return f a l s e ; }

158

}

160

/∗∗

∗ Function c a l l e d incomingPayload ( ) , that reads the incoming ∗ payload

162

∗/

void incomingPayload ( ) {

164

while ( network . a v a i l a b l e ( ) ) { RF24NetworkHeader header2 ;

166

inc_payload_t payload ;

network . read ( header2 , &payload , s i z e o f ( payload ) ) ;

168

S e r i a l . p r i n t l n ( "−−− Reading payload −−−" ) ; i f ( payload . incButtonState [ 0 ] == HIGH) {

170

d i g i t a l W r i t e (LED, HIGH) ;

S e r i a l . p r i n t l n ( "Turn LED ON" ) ;

172

}

i f ( payload . incButtonState [ 1 ] == HIGH) {

174

d i g i t a l W r i t e (LED, LOW) ;

S e r i a l . p r i n t l n ( "Turn LED OFF" ) ;

176

}

i f ( s t r l e n ( payload . incText ) != 0) {

178

S e r i a l . p r i n t ( " Incoming message : " ) ; S e r i a l . p r i n t l n ( payload . incText ) ;

180

}

}

182

}

References

Related documents

McIntosh and Munk (forthcoming) claim that the class schema that we have developed (Erikson and Goldthorpe 1992) lacks validity and should not be taken as a basis for studies

The invariance of(1.1) with respect to the most general Lie point symmetry generator, Lie symmetry algebras ofrelativistic invariance, and conditional invariance is considered..

Extended objective of conducting two phase II clinical trials: After the company obtained positive results in a preclinical study in nephrotic syndrome (NS), where dosing

1962 Ford Thunderbird--- John Wagner, Athens, GA Repeat Preservation.. 1963

As concluded in the results section, the University of Gothenburg, Lund University, Stockholm University, Umeå University and Uppsala University legitimize their practices, and

Code Static data Heap Stack date desc. As

• Constructing the date object on the stack requires knowledge in compile time. How big is the object to put on

In the block marked RATIO record the ratio o f the absolute value of the coefficient o f each term over the number o f variables, both original and y„ in that term....