Internet of things for monitoring grazing animals

(1)

IN

DEGREE PROJECT INFORMATION AND COMMUNICATION TECHNOLOGY,

SECOND CYCLE, 30 CREDITS ,

STOCKHOLM SWEDEN 2016

Internet of things for

monitoring grazing animals

ALISHER ZAITOV

KTH ROYAL INSTITUTE OF TECHNOLOGY

(2)

(3)

Internet of things for monitoring grazing cattles

Master thesis in Embedded systems

Alisher Zaitov

Master of Science Thesis

School of Information and Communication Technology KTH Royal Institute of Technology

Stockholm, Sweden 10 October 2016

(4)

(5)

Abstract

Swedish agricultural industry is well known for it’s fair animal tending and ecological processes, the high standards comes at a cost of tough strict regulations. Laws were introduced to keep a low level usage of antibiotics and toxic products among the agricultural industry. The though competition from products imported from other countries with much less strict laws puts puts Swedish farmers under pressure and pushes them to keep an extra good eye on their animals in order to avoid sickness and injuries of their animals. This master thesis is focusing on investigating the possibility keep the low usage of antibiotics and maintaining the high level of standards by introducing new technology that can help the farmer to monitor their animals and keep them healthy.

The goal of this thesis is to develop a system that monitors grazing animals in the pasture land and helps farmer to detect injuries and diseases at an earlier stage. For the system to be viable and useful for the farmer it has to keep low power consumption and come at an affordable price.

The implemented system solution consists of a wireless sensor network that collects data about estimated position of the animal in the pasture land , interaction patterns and ambient sensor data of the environment. The data is then propagated using a opportunistic network protocol. Hardware prototype is tested using simulations, indoor tests, and field tests with cows on a farm in northern Sweden. The work is concluded with evaluations of the prototype based on requirements, scalability and cost.

(6)

(7)

Sammanfattning

Svenska lantbruksndustrin är väl känt för sin rättvisa djurhantering och ekoloiska metoder, den höga standared kommer till en priset av h˚arda stränga regler. Lagar infördes för att h˚alla en l˚ag användningsniv˚a av antibiotika och giftiga ämnen bland jordbruksindustrin. Vilket sätter jordbrukare under press och kräver dem att h˚alla ett extra gott öga p˚a sina djur för att undvika sjukdom och skador p˚a sina djur. Detta examensarbete fokuserar p˚a att undersöka möjligheten att h˚alla l˚ag användning av antibiotika men bibeh˚alla den höga standarder genom att införa ny teknik som kan hjälpa bonden att övervaka sina djur och h˚alla dem friska.

M˚alet med denna examensarbete är att utveckla en system prototyp som övervakar betande djur och hjälper bonden att upptäcka skador och sjukdomar i ett tidigare skede. För att systemet ska vara lönsamt och användbart för jordbrukaren behöver den h˚alla en l˚ag strömförbrukning och komma till ett överkomligt pris.

Den genomförda systemlösningen bygger p˚a ett tr˚adlöst sensornätverk som samlar in data om esitmerad position av djuret i betesmarken, interaktionsmönster och omgivnings sensordata av miljön. Prototypen testas med simuleringar, tester i labmiljö samt fälttester med kor p˚a en g˚ard i norra Sverige. Arbetet avslutas med utvärderingar av prototypen baserat p˚a systemkrav, skalbarhet och kostnad.

(8)

(9)

List of Figures

2.1 Monitoring system . . . 10

2.2 Broadcast transmissions are sent with each packets being resent for the whole wake-up period of the receiver. . . 14

2.3 Package is received send ack to sender and stop resending. . . 14

2.4 Rime layers . . . 17

3.1 System overview . . . 23

4.1 System overview . . . 29

4.2 Data flow during an encounter . . . 32

4.3 Data flow from WSN to Cloud . . . 35

5.1 Event 1 - simulated . . . 39

5.5 Indoor test node placement . . . 43

5.6 Node setup during field test . . . 47

5.7 Anchor node and base station . . . 48

5.8 Mobile nodes on collar . . . 48

6.1 Memory consumption of encounter data . . . 53

(14)

(15)

List of Tables

1.1 Use case 1: Installation . . . 4

1.2 Use case 2: Configuration. . . 4

1.3 Use case 3: Presentation . . . 5

1.4 Use case 4: Data collection . . . 6

2.1 The OSI Model . . . 11

2.2 Raspberry pie specification . . . 19

2.3 Pinoccio specification[1] . . . 20

3.1 Communication stack comparison . . . 27

4.1 Data structure of a separation . . . 31

4.2 Data structure of an encounter . . . 31

4.3 Merged data structure of an encounter . . . 34

5.1 Definition of simulated node types . . . 39

5.2 Merged encounter data structure . . . 42

5.3 Definition of indoor tested nodes . . . 43

5.4 Data verification. . . 46

5.5 Definition of field tested nodes . . . 48

6.1 Encounter data types . . . 52

6.2 Separation data types . . . 52

6.3 Maximal amount of encounters . . . 53

6.4 Component price . . . 55

(16)

(17)

List of Acronyms and Abbreviations

This document requires readers to be familiar with terms and concepts. For clarity we summarize some of these terms and give a short description of them before presenting them in next sections.

WSN Wireless sensor network

6LoWPAN IPV6 over Low power wireless Personal Area Networks CoAP Constrained application protocol

ID identifier

IoT Internet of Things

GPS Global positioning system

IDE Integrated development environment

DSP Digital signal porc

SDRAM Synchronous dynamic random-access memory CPU Central Processing Unit

MCU Micro Controller Unit

GPU Graphical Processing Unit GPIO General Purpose Input/Output

IEEE Institute of Electrical and Electronics Engineers

MAC Media Access Control

LLC Logical Link Control

(18)

OSPF Open Shortest Path First

BGP Border Gateway Protocol

RDC Radio Duty Cycle

RSSI Receiving Signal Strength Indicator

OS Operating System

(19)

Chapter 1 Introduction

1.1 Background

Swedish farming industry is well known for its fair animal tending, low usage of antibiotics or toxic products. To achieve these high standards the farmer is put under a lot of pressure and need to keep a good eye on the animals in order to avoid sickness and injuries. With the help of new technology combined with animal behavior analyses the animal tending and monitoring can be improved. By providing each animal with low–energy platforms, wireless communication modules and various sensors important data can be recovered and used for monitoring. This will hopefully relieve some of the pressure from individual farmers, increase the productivity and reduce the costs by detecting injuries and sickness of the animal in an earlier stage.

1.2 Purpose

• Strengthen Swedish research and development in the area of Internet of things and low-powered wireless communication

• Contribute to increased efficiency of Swedish agriculture

• Increase understanding and possibilities with IoT based technology among farmers.

1.3 Goal

The goal of this project is to design and develop monitoring components of a system that monitors farm animals. To reach the stated goal following sub goals

(20)

need to be completed

• Investigate and analyze different hardware platforms in order to find the optimal platform for the system based on performance, energy efficiency and durability.

• Implement an opportunistic network protocol for an embedded system with low-energy wireless communication and determining the position of each node.

• Design and develop a fixed-point main node that packs the network data and forwards to a cloud-based database using 3g-network.

• Prepare the partly developed prototype for a demo in April 2016. • Set up the prototype for a field tests.

• Document the outcome of the project covering methods, implementation, analysis, and results in a written report.

1.4 Requirements

The end product of the master thesis should consists of a monitoring system that meets the requirements presented below.

• The sensor network is able to collect following data:

1. Estimated position of animal - Information about where in the pasture land the animal were seen last.

2. Encounter data - Record every interaction between two animals and store it with a time-stamp.

3. Separation log - Record how many times animals been separated and for how long.

4. Sensor readings - Collect ambient sensor data such as temperature and activity indicators

• Collected data is propagated trough the network using opportunistic protocol without the need of every node having internet connectivity.

• Gateway node with 3-g connection posts the data to an cloud platform for further analysis.

(21)

1.5. RISKS, CONSEQUENCES ANDETHICS 3

1.5 Risks, Consequences and Ethics

Risk: Implementation of pre-study shows that the technical solution is not relevant nor applicable for the target group.

Mitigation: Researchers in both agriculture and technology are involved in the project which indicates that if difficulties are encountered during the pre-study the final prototype design can be adjusted and form new requirements.

Risk: Implementation of the prototype fails.

Mitigation: Sics and Luda have great knowledge in embedded systems and network communication. By working in close collaboration with both parts and ask for consulting when needed the risk of prototype failure can be decreased. Risk:Failure of field tests.

Mitigation:Dackeg˚arden will provide us with a farm and assist us during the field tests which gives us the possibility to test the prototype in an operative environment. Animal rights need to be respected and the prototype can under no circumstances harm the animal in any way. It’s important to tests the prototype in lab environment before attaching it to the animal.

1.6 Methodology/Methods

The project will take a more quantitative and test driven research approach. Where the data collection and research strategies will consist of experiments and testing in order to achieve the desired goals. All of the test results and data collection will be documented and presented in a way so that other researchers can replicate the work and use it for quality reliability improvements.

Some use scenarios and use cases will be presented in the section below, these use cases is what will drive the design and development of the system.

1.7 Use cases

(22)

Table 1.1: Use case 1: Installation

Name Installation and initialization

Description All of the hardware is updated with latest software and initialized with standard values. The anchor node placement are strategically chosen for optimal coverage.

Primary Actor Developer

Precondition None

Minimal guarantees The hardware is delivered and installed with initial software Success guarantees The hardware if well prepared and

ready for of the shelf deployment and no additional configuration is

required

Trigger User orders a monitoring system

Table 1.2: Use case 2: Configuration

Name System Configuration

Description The system is customized for the user

Primary Actor Developer and User

Preconditions The installation needed additional configuration

Minimal guarantees The system is configured based on the shape and size of the pasture land and cattle size

Success guarantees All of the nodes are configurable wirelessly and do need to be detached from collars for further adjustments Trigger Of the shelf deployment not possible

(23)

1.7. USE CASES 5

Table 1.3: Use case 3: Presentation

Name Data Presentation

Description Collected data is presented for the user

Primary Actor Front end system

Preconditions Cloud platform has accessible and readable data

Minimal guarantees Cloud data is presented as list of entry’s gathered form the cloud database. User can define the time span and excursively choose which of nodes to be presented

Sucess guarantees Data presented in a informative manner with graphics, illustrations and animations to make it easier fro the user to see movement patterns and progression of sensor values.

(24)

Table 1.4: Use case 4: Data collection

Name Data Collection

Description Sensor data is collected from each node and propagated

opportunistically through the sensor network to the cloud platform

Primary Actor System

Preconditions System installed and customized Minimal guarantees Any data stream that reaches the cloud platform each time a node passes the gateway node(water station)

Success guarantees All of the following data streams are properly read and stored on each node

1. Encounter data - Record every interaction between two animals and store it with a time-stamp.

2. Separation log - Record how many times animals been separated and for how long. 3. Sensor readings - Collect

ambient sensor data

Trigger System deployed by user

1.8 Usage scenario

This section will describe a typical user scenario of the end system, how a the system can be installed, used and interpreted.

Desir´e is a agriculturist who mends 170 cows and 40 of these cows are about to be released into the pasture land. This time a new system is about to be deployed that will help Desir´e to monitor her cows in the pasture land.

Every cow has been equipped with a collar with a micro controller on it and some anchor nodes has been placed out in the grazing area. A gateway node with 3G-connectivity need to be placed in a strategic place where cows pass by regularly, preferably a water source where cows drink.

(25)

1.8. USAGE SCENARIO 7

(26)

(27)

Chapter 2 Technical Background

This chapter introduces the relevant concepts and technologies that can be used to develop the prototype. Former researches done in related areas are summarized. The chapter also presents and compares several hardware platforms together with communication protocols. The goal of this chapter is to investigate optimal components and communication technologies for the prototype based on: power consumption, computation performance, price and sensor compatibility.

(28)

2.1 A monitoring system

A typical monitoring system would consist of measuring equipment or sensors that collect data about the object that is being monitored. Data that is being collected by the sensors needs to be processed and sent to a central database where it is compiled and presented to the observer. An operating system is needed to schedule process of and define communication protocols of the hardware platform.

Figure 2.1: Monitoring system

2.2 WSN - Wireless Sensor Network

A wireless sensor network consists of small sensor nodes communicating among themselves using radio signals. Nodes are equipped with different sensors with an objective of monitoring the physical or environmental conditions of the surrounding. Sensor nodes are essentially small computers with basic functionality consisting of:

• Processing unit • Memory • Power source

(29)

2.3. COMMUNICATION STACK 11

The processing units main task is to process locally sensed information and store or forward it to other nodes. Keeping the processing unit in sleep mode for as long as possible is crucial from a power consumption point of view. Memory is used to store both the data from sensors and program that is running on the node. The sensor nodes are meant to be deployed in remote regions where power outlets are not available or applicable. WSN nodes are therefore usually equipped with rechargeable batteries or solar cells depending on the usage. Sensors comes in different shapes and types capable of monitoring a wide variety of conditions where most common sensing parameters are temperature, humidity, light, pressure, acceleration and soil moisture[3].

2.3 Communication stack

2.3.1 OSI model - Open System Interaction model

This section will introduce the basic concepts of the OSI model and point out main layers that this research will encounter.

The OSI model is an model that characterizes and standardizes the communication functions by dividing it into seven different abstraction layers. Each layer implements it’s own functionality and protocols independent of underlying layers[4]. Data that is created by an application will start in the top layer and then propagate down through every abstraction layers utilizing the protocols each layer has to offer. The two layers of most interest for this project is Data link layer and the Network layer.

# Layer 7 Application 6 Presentation 5 Session 4 Transport 3 Network 2 Data link 1 Physical

Table 2.1: The OSI Model

2.3.1.1 Data link layer

(30)

errors that may occur in the physical layer. The data link layer is responsible for establishing a protocol that will open and close a connection between two physically connected devices. The flow control on each link is also decided by the Data link layer[4]. Media Access Control (MAC) and Logical Link Control (LLC) are the two sub-layers to data link layer. These two sub-layers have an internal hierarchy, where LLC is n top of MAC. LLC provides data link control and addressing while MAC controls which of the devices in the network that may access the medium and who has the permission to transmit/receive. Carrier sense multiple access with collision avoidance (CSMA/CA) is an protocol that only allows transmits when the channel is sensed to be in the idle state . Other examples of protocols that operates in the Data link layer are HDLC, ARP and PPP [5].

2.3.1.2 Network layer

Network Layer is arguably considered one of the most complex layers that has a main responsibility of providing a host to host communication service. This basically means to move a packet from a sending host to a receiving host thorough multiple hops. The service can be divided into two key network-layer functions, forwarding and routing. When a package arrives at a router’s input link, the router needs to forward the package to the appropriate output link based on the implemented algorithm on the router. Routing - the network layer must determine the route or path taken by packets as they flow through the network. The path is decided by the routing algorithms. RIP, OSPF and BGP are some of the most common routing algorithms in the Internet network.

The network layer complexity can vary depending on the size and architecture of the network. The network service model determines the characteristics of the services the network has to offer. Some examples of such services may be:

• Guaranteed delivery

• Guaranteed delivery with bounded delay • In-order packet delivery

• Bandwidth guarantee

(31)

2.3.2 IEEE 802.15.4

The IEE 802.15.4 is an standard that specifies the physical layer and media access control. It was designed in 2003 by the IEE 802.15 working group to address the need for low cost, low power wireless standard optimized for monitoring and control applications. The main differences to other wireless IEEE-standards is it’s fast power-on latency and support of mesh-networking. The 802.15.4 standard has became an strong alternative for for low rate wireless solutions within the IoT domain. Communication protocol stacks on higher levels such as ZigBee, 6LoWPAN and WirelessHART are based on this IEE standard [7]. IEE 802.15.4 uses an carrier sense multiple access with collision avoidance (CSMA-CA) method to access the physical medium. The standard also supports optional message acknowledgment to ensure package delivery, energy detection to pick channels and link quality readings to determine the signal strength. All of these features contribute to a more reliable data delivery even in environments with high interference levels[8].

2.3.3 MAC Layer in WSN

In an WSN the main medium used in the network is the radio frequency module which is also the biggest energy consumer of an wireless node. Consequently the MAC protocol has additional important functionality to fulfill in an wireless network. Controlling the radio unit is an crucial part when managing the power consumption of any unit using wireless communication.

The MAC protocol is mainly responsible for the power consumption in WSN The media that is accessed in an WSN is the Radio Frequency (RF) module. The radio interface is usually the main energy consumer in an typical IoT device and the most common way of reducing energy consumption is to turn off the RF module when it’s not used. This however leads to synchronization challenges between the devices in the network. Each node need to know when to expect new data to be transmitted from it’s neighbors before turning on the RF module. The time percentage each node has its RF module turned is called duty cycle. With proper configuration of the radio duty cycling (RDC) that fits the system design the energy consumed by the network can be reduced.

2.3.3.1 ContikiMAC

(32)

The most fundamental principles behind the RDC protocols is described in the figures below. Figure 2.2 illustrates how the receiver nodes sleep most of their time and only turned on periodically to check weather there is any activity on the radio channel. If radio activity is detected by looking at the Radio Received Signal Strength (RSSI) the receiver will stay awake until the next package is delivered. The sender however will keep sending the same package until the link layer acknowledgment is received. Figure 2.3 illustrates how the sender behaves when an acknowledgment is received.

Figure 2.2: Broadcast transmissions are sent with each packets being resent for the whole wake-up period of the receiver.

(33)

found can be found in Adam Dunkles artice The contikimac radio duty cycling protocol [9].

2.3.4 Opportunistic Networks

Opportunistic network is considered as an subclass of Delay-Tolerant Network (DNT) where the nodes lack continuous stable connectivity. The link performance between an end-to-end path in such network will either have long delays or not be stable enough for conventional protocols that depend heavily on quick acknowledgment replies[10].

In opportunistic networks nodes will either move out of connectivity range, power down to conserve energy or links may be disrupted or shut down periodically. Infrequent and sporadic connectivity between nodes will lead to network partitions. In order to still be able to send messages from one point to another despite the connectivity issues there are some functionalities that need to be utilized. Data to be delivered to its final destination can be stored locally on a intermediate node until an possible path is available. This will require forwarding and storage ability of bypassing data from each node in the network. The solution presented above only addresses the issue with complicated applicability of acknowledgment based protocols, the delay between end-to-end nodes will still remain the same, thus opportunistic network architecture is only applicable in delay-tolerant systems [11].

2.3.5 ZigBee

The ZigBee is a standard that defines a set of communication protocols for low-data-rate short range wireless networking. The standard builds on IEE standards 802.15.4 which defines the physical and MAC layers. On top of this the ZigBee protocol defines application and security layer specifications enabling wireless communication between platforms developed by different manufacturers.The ZigBee wireless devices operates well in harsh radio environments using the 858MHz,915MHz and 2,4GHz frequency bands.

(34)

in applications. In most ZigBee based applications the duty cycle is less than 1% to ensure long battery life[7].

Main characteristics: • Low power usage

• Supports a wide range of different network topologies,including point-to-point, peer to peer and mesh network.

• Highly reliable and secure • Cost effective

• Scalable and easy deployment • 250 kbps data rate

2.3.6 6LoWPAN

6LoWPAN -IPv6 over Low-power Wireless Personal Area Networks is as ZigBee also a set of communications protocols defined by IETF(Internet Engineering Task Force). The 6LoWPAN stack can in addition to the IEE 802.15.4 run on any IP-based physical links such as WiFi and Ethernet[3]. In comparison to ZigBee the 6LoWPAN offers better interoperability with other devices in the IP-network due it’s efficient use of IPv6. In an 6LoWPAN every unit has its own IPv6 address and can communicate with any other device connected to the IP-network. While the ZigBee network requires a translation gateway or proxies to bridge each device to the IP-network[12].

2.3.7 Rime

(35)

2.4. CONTIKI- OPERATING SYSTEM FORIOT 17

Figure 2.4: Rime layers

next layer reliable transmission is achieved by adding additional headers to the message, sequence number and acknowledgment.

2.4 Contiki - Operating system for IoT

Contiki is an open source operating system specially customized to run Internet of Things applications. It low-power communication by connecting low-power micro-controllers to the internet using the IPv6 and IPv4 standards along with the most recent low-power wireless standards:ZigBee, 6LoWPAN,RPL, CoAP.

Contiki applications are written i standard C and the OS comes with Cooja simulator. The simulator allows networks to be emulated before uploaded into the hardware. Whole development environment can be set up in a single download.

The OS is designed to run on tiny systems having only few kilobytes of memory available by implementing highly memory efficient allocation methods. This makes it possible for the Contiki OS to be used in a wide range of hardware platforms[14]. There are however a set of platforms that are more popular and are tagged as primary Contiki platforms.

2.5 Hardware platforms for WSN

(36)

2.5.1 Arduino

Arduino is an open source hardware and software platform. It was introduced in 2005 and was designed with the goal of making the hardware and software easy to use and available to the widest audience possible. The Arduino platform has an growing community of contributors and a lot of information and tutorials can be found on their website to help people getting started with their development. Arduino also provides a development environment called Arduino IDE which is basically a text editor with limited set of functions designed to support compilation and loading of sketches. The IDE is supported on Linux, Mac and Windows computers. [15]

There are several Arduino board models available for purchase.Some of them are equipped with more powerful processors that can be compared with Raspberry Pi units while others are single purpose processors configured for special applications.The variety of different models is big but they all follow a basic layout where every board consists of a USB connection, a power connector and a standardized set of pins for shield attachments. Shields are modular circuit boards that can add extra functionality to the platform.For instance wireless communications modules such as XBee, Bluetooth and WiFi can be added to Arduino platforms using shields.

2.5.2 Xbee

The Xbee is a RF-module developed by Digi that provides embedded solutions for wireless endpoint connectivity for different devices. These modules uses the IEEE 802.15.4 networking protocol based on the ZigBee standard.

There are different types of Xbee modules mainly divided in regular and pro versions. The regular module is more energy efficient and cheaper compared to the pro model. It uses the 2.4GHz frequency and has a range limit up to 300m in line of sight. Xbee Pro versions uses the 900MHz frequency which extends the range of the communication and increases object penetration.

Xbee modules are highly compatible with many different hardware platforms and XBee shields makes it easy to add wireless communication to Arduino and Raspberry Pi based projects.

Developer kit XKP9-DMB0 consisting of items below will cost around 330USD. Same kit with the cheaper module costs 100USD[16].

• 3x Programmable XBee-PRO 900HP modules • 3x XBee USB interface board

(37)

2.5. HARDWARE PLATFORMS FOR WSN 19

• 2x USB Cables

• Antennas and Accessories

2.5.3 Raspberry PI

The Raspberry Pie is a credit sized single-board computer. It was developed in the UK with the intention to teach the basics of computer science in schools. Today the board is widely used around the world and in June 2015 about five to six million Raspberry Pie units has been sold[17].

The latest Raspberry Pi 2 unit has uses an Broadcom BCM2835 SoC model that includes: CPU,GPU,DSP,SDRAM and one USB port. The CPU is an 900Mhz quad-core Arm processor which is similar chip that is used in older generation of smartphones.The Raspberry platform primarily runs with Linux-kernel based operating systems such as Arch Linux ARM, Raspbian, and RISC OS.

The price of a Raspberry pie unit varies between 20-35 USD depending on the model.Unfortunately the Raspberry Pie models does not provide any built- in wireless communication and will require an external adapter which will increase the cost.

Table 2.2: Raspberry pie specification Raspberry Pi2 Model B Connections 900MHz quad-core ARM Cortex-7 17 GPOI pins GPU with 1080p H.264/MPEG-4 encoding USB2.0 port

1GB SDRAM memory shared with GPU HDMI Video Output 15-pin MIPI camera interface 10/100Mbit/s Ethernet

MicroSDHC slot 3,5mm Audio output

Powered with 5V via Micro USB Micro USB port for programming

2.5.4 Texas Instruments SensorTag

Texas Instrument offers a sensor tag platform that powers the IoT development. The platform supports several wireless low energy protocols such as,Bluetooth Smart, 6LoWPAN and ZigBee. The battery life of a platform running low energy protocols is estimated to one year with a 1 second report interval.

(38)

• 9-axis Motion Sensor MPU-950

• Infrared and Ambient Temperature Sensor • Humidity Sensor

• Barometric Pressure Sensor

SensorTag has a total of 670KB of memory where is 158KB comes from the cc2560 MCU and the remaining 512KB come from the serial flash memory chip attached to the SensorTag [19]. On top of everything the platform comes with an IOs and Android apps where the sensor data can be presented and controlled with a user interface.The price of one unit is roughly 30USD.

2.5.5 Pinoccio

Pinoccio is an open source hardware and software platform with built in 2.4GHz radio communication module using the 802.15.4 IEEE standard(same as the ZigBee). It has an on-board temperature sensor and a battery with and recharging circuit.

The Pinoccio platform is Arduino compatible and allows the usage of Arduino IDE together with most of the packages provided for Arduino development. The platform seems to fit very well for prototype development because of it’s complete package, delivering low-energy wireless communication,built-in battery and arduino compatibility. The price for one unit is roughly 50USD while a unit that supports WiFi costs 120 USD

Table 2.3: Pinoccio specification[1]

Microcontroller(Atmel ATmega256RFR2) Connections

Built-in radio for mesh networking 17 digital I/O pins, including four with PWM

16MHz MCU 8 analog input pins

256k Flash 2 hardware UART serial ports

32k SRAM Hardware SPI port

8k EEPROM Dedicated I2C port

(39)

2.6. RELATED WORK 21

2.6 Related work

2.6.1 ZebraNet

ZebraNet is a wireless sensor network project made by graduates and professors at Princeton university in collaboration with researchers at Mpala Research center in Kenya. The goal of the ZebraNet was to develop a system that gathers GPS position samples from zebras over a wide range(100-1000 square kilometers) of open lands. The data is then collected and presented to researchers so that they can learn more about movement patterns, especially during long-term migration.

The study focuses on smart ways to solve wireless communication challenges while maintaining low power usage. The resulting collar design uses both long range and short range radio units where the short range device focuses on error correction and data packaging. The long range radio device is necessary when communicating with base station during data collection. Since zebras has a huge grazing area GPS is used to track the animals and data collection has to done actively by researches by either bus or flying drones[20].

2.6.2 Seal-2-Seal

Seal-2-seal research focuses on application of opportunistic networking techniques to wildlife monitoring. The paper presents a solution based on a protocol where every node is able to log contact with other nodes and then disseminate that data further to sink nodes using intermittently connected network. The protocol utilizes a novel mechanism that creates efficient data summaries that reduces the amount of data that need to be disseminated by every node.

The Seal 2 Seal protocol [21] is based on two phases, contact detection, and dissemination. During the contact detection nodes periodically listens to signals from other nodes within the transmission range. If a signal is detected the event is logged as an new contact. Dissemination phase is initiated when new contact is logged and neighboring nodes start to exchange information.

(40)

(41)

Chapter 3 System Design

This chapter will describe the architecture of the experimental desgin of a system monitoring of cows grazing over pasture lands. It will give a detailed description of the underlying platforms as well as the technology behind the design. The architecture will be explained with a top down approach. Starting out with outer abstract components and then moving down to into more technical segments.

The design goals and decisions were mainly driven by the use cases mentioned in chapter 1.

Figure 3.1: System overview

(42)

3.1 System architecture overview

The system is divided in three main parts

1. Core WSN - Network of wirelessly connected nodes using opportunistic communication.

2. Back-end - Cloud platform for storing and analyzing the data generated by the WSN.

3. Front-end - Web Page requesting data from the cloud platform and presents it to the end user.

3.1.1 Core WSN

The core WSN network consists of mobile devices attached to animals, anchor nodes placed in the pasture land and a main sink with internet connectivity placed near a water station. Main responsibility of the WSN network is to collect and distribute the data that is generated by the animals. Information such as ambient sensor data, latest interaction between animals as well as separation time between animals is the kind of data that is collected by each mobile node.

3.1.2 Back End

The main sink/base station transfers the data further to the back end system consisting of a cloud platform. The cloud platform is responsible for filtering and analyzing the data. The goal of the analysis is to from the raw data input acquire connectivity patterns between animals and anchor nodes. The patterns can show anomalies in social interactions and indicate on health related problems.

3.1.3 Front End

(43)

3.2. SYSTEM ELEMENTS 25

3.2 System elements

The system can be broken down further into following elements 1. Mobile node

2. Anchor node

3. Sink node / Base station 4. Cloud platform

5. Web interface

Both the mobile and anchor node types use same hardware and run similar software. The important factors of these nodes is the radio communication and storage possibilities. The mobile nodes are attached to a collar around the neck of the animal preferably on top of the neck. Cows are massive animals and and their bodies can thus absorb or disturb the radio signals. By having the nodes attached on top of the neck the interference rate of the signals can be reduced.

The anchor nodes should have the identical functionality as the mobile nodes but instead of being attached to animals the nodes are placed on fixed locations in the pasture land. All nodes keep record of interaction with other devices and by knowing when a certain animal had an interaction with an anchor node the location of the animal can be deduced.

Based on the use cases and requirements the data acquired by the mobile nodes can be divided in three different types:

1. Ambient sensor data is collected using sensors that come with the hardware device. It should however be possible to add external sensors and connect them to the mobile node device. Temperature sensor and accelerometer are common sensors that can be used in the experimental prototype.

(44)

3. Separation Data is created when two nodes been apart from each other for a predefined period of time. The data consists of two node IDs and two time-stamps. The first time-stamp tells when the nodes were separated and the second time-stamp when they met again.

Sink node is also similar to both mobile node and anchor with a main difference having a wired connection to the base stations. The sink listens and receives the data floating int the WSN in same way as the mobile nodes but instead of sending the data further wirelessly it pushes the data to the base station using serial communication to. Sink acts as an gateway node being the only point where the data can leave the WSN.

The base station should be a more powerful device than the nodes in WSN and since it will remain stationary near a water station it can have better power supply. The data it receives from the sink node need to be passed further to the cloud platform via Cellular network. Cellular network connection can be established using a 3g-dongle.

3.3 Choice of technology

3.3.1 Texas Instrument Sensor Tag with Contiki

All nodes in the WSN runs on the Texas instrument sensorTag using the Contiki operating system. There is an active community that continues to develop Contiki. The light weight and flexible Operating system was developed to support the WSN development. It offers great tools and protocols for a wide range of IoT devices with sensorTag being one of them. Communication is a fundamental concept in this project and Contiki provides communication protocol implementations from the application layer down to the physical layer.

The choice behind using sensorTag as the main hardware unit is based on it being an primary Contiki platform. The sensorTag platform is actively supported and included in the current Contiki code tree. The sensorTag also comes for a reasonable price considering it being equipped with 6 different sensors and supporting IEE 802.14.5, ZigBee and 6LoWPAN.

3.3.2 Communication stack protocol

(45)

3.3. CHOICE OF TECHNOLOGY 27

Table 3.1: Communication stack comparison

Feature IEE 802.15.4

Rime

6loWPAN ZigBee

Possible network topologies

Star Tree, Mesh Mesh

Over the air programming

No No Yes

IPv6 compatible No Yes No

Maximal number of nodes Implementation dependent 64000 64000 nodes Preferred field of application Point to point connections WPAN with IP connectivity Home automation WSN

Taking a look on the ZigBee stack that looks very promising offering useful features. ZigBee was designed specifically to achieve high standards in both power consumption and scalability. Despite the perks that ZigBee has to offer the system in this project will be using the Rime communication stack on top of the IEE 802.15.4 standard. Reasoning behind this decision is based on ZigBee being proprietary, controlled by the ZigBee alliance group. ZigBee alliance offers several applications and network standards. However the source code for the standards can not be viewed or edited without being a ZigBee alliance member. These restrictions would make it hard to customize the standard to fit the desired functionality of the system. Rime does not offer same amount of features as the ZigBee stack but allows more flexibility in the implementation.

3.3.3 Raspberry pie as the base station

(46)

(47)

Chapter 4 Implementation

This chapter will describe how the technologies and the equipment were used to develop the experimental prototype of the system. Additionally the implementation of data structures and data dissemination will be explained in detail.

4.1 System overview

Figure 4.1: System overview

(48)

4.1.1 Contiki build system

The Contiki build system is based on configuring project header files or customizing Makefiles. In the project header file the developer is able to specify the network related parameters such as network stack, RDC check rates or Radio frequencies. The WSN nodes in this project used the NETSACK with Rime configuration and RDC check rate of 16 which was an default value that. Down below is an extraction of configurations in the header files used during implementation of the system.

CONTIKI_WITH_RIME = 1

define NETSTACK_CONF_RDC contikimac_driver define NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE 16

The Makefile specifies where the Contiki source code resides in the native system and includes platform specific libraries defined by the BOARD parameter.

make BOARD=sensortag/cc2650

After running the make file an image file is compiled containing the Contiki OS with the developed program ready to be uploaded to the hardware platform.

4.1.2 Data generation and representation

According to the system design the system need to collect three types of data. 1. Ambient sensor data

2. Encounter data. 3. Separation data.

Ambient sensor data is acquired by using the Texas instrument library functions. In order to read the values the sensors need to be activated and then initiated with sample rate timer. The register that holds the sensor measurement value is then read periodically.

(49)

4.1. SYSTEM OVERVIEW 31

more than once only the latest one will be kept in the encounter list with an updated time-stamp.

The separation data structure is similar to the encounter list and also utilizes the beacon signal. Separation entry is created when the times-stamp difference between two encounters is bigger than a predefined value. Separation data entry is also represented using a struct containing node ID, separated node ID, starting time-stamp and ending time-stamp. Starting time-stamp holds information about when two nodes were separated and ending time-stamp tells when they got back together. Similarly to the encounter list the separation entry is added to a linked list called Separation list.

Table 4.1: Data structure of a separation

Node ID Separated ID Starting time-stamp Ending time-stamp

(50)

4.2 Data collection and dissemination

Each of the data streams need to be collected and propagated with an opportunistic approach. One way of doing this as mentioned in section 2.2.4 having each node have a copy the data that needs to be disseminated. How the data is disseminated will be explained by describing the processes that run on each node. Rime that is mentioned in section 2.2.7 is used for establishing communication and exchanging data between nodes.

Figure 4.2 illustrates important data structures and processes that are implemented on each node and how the data is flowing when two nodes are within radio communication range.

Figure 4.2: Data flow during an encounter

Data structures used in the implementation are following:

• Broadcast beacon - Struct consisting of senders ID a time-stamp

• Unicast message - Same structure as an entry in the encounter list or history log.

(51)

4.2. DATA COLLECTION AND DISSEMINATION 33

Every node runs 5 processes and implementations of these processes sets the core functionality of the WSN. The processes are defined and implemented following Contiki guidelines with an event or timer triggered processes.

4.2.1 Send Broadcast

This processes simply sends a a broadcast beacon every t second to every address in the neighbor list. Sensor values that are read locally from each node are packed and added to the broadcast beacon message.

4.2.2 Receive Broadcast

When a node receives a broadcast message it parses the data from it and creates new entries to the neighbor list and encounter list. Receiving a broadcast message corresponds to an encounter between nodes and a new encounter entry can only be created by this process. Each broadcast message comes with the senders physical address which is stored in the neighbor list. If the broadcast is received for the first time from the senders node a new entry is created and added to the encounter list otherwise the old entry is overwritten with new time-stamp and sensor values. An entry in the local separation list list is also created by this process. The entry is created based on two conditions. Receiver node already encountered the sender before and the time-stamp difference between the first and second encounter is bigger than a predefined value t.

4.2.3 Send Unicast

The process iterates though the neighbor list and encounter lists and sends whole encounter list to every neighbor in the neighbor list. When this is done the neighbor list is wiped out, this allows a more dynamic tracking of neighbors where the data is only sent to current neighbors. The encounter list is chopped down to smaller fragments where each entry in the encounter list is packed into a single unicast message. For example if a node has 10 encounters stored in the encounter list with two neighbors it would need to in total send 20 unicast messages.

4.2.4 Receive Unicast

(52)

4.2.5 Sensor readings

This process activates and reads sensor values from the hardware. Also used for troubleshooting and printing current state of each data structure. Time-stamp counter is incremented by this process.

4.3 Optimization and improvements

This section describes the improvements and optimization during the second cycle of prototype development. After the first cycle the prototype the nodes were able to communicate and acquire the data that specified in the minimal requirements. Through out the second cycle functionality optimization were added to the prototype continuously that mainly targeted the resource and power management.

4.3.1 Merging data

Initially the first prototype had a third data structure that needed to be sent across the network holding sensor readings similar to the encounter and separation lists. Improvements could be made by merging the sensor data stream together with the encounter which eliminated the need of additional data structure and lead to reduced memory usage and lower power consumption due to smaller overhead in messages. The merged encounter data structure went from having three elements to seven.

Table 4.3: Merged data structure of an encounter

Node A Node B Time-stamp Temp A Temp B Activity A Activity B

4.3.2 Allow easy configuration

(53)

4.4. BASE STATION AND SINK NODE 35

processes run less frequently means higher chance of missing an encounter or nodes having to old data. Keeping this in mind during deployment and allow easy configuration of how often processes are allowed to use the radio unit will make it easier to find optimal values that keeps same functionality level and preserves power usage.

4.3.3 Data sent tracking

The first implementation of unicast processes was basically iterating through the current neighbor list and sending data to each of the neighbor nodes. This meant that if a node only had one neighbor it would keep sending same data to same node over and over again. Adding a small times-tamp entry to the neighbor struct that keeps track on when last data was sent to that node allows the unicast process to discard the neighbor if the data already been sent to that node recently.

4.4 Base station and sink node

As stated before the difference between a sink node and a mobile node i very small. The sink node need to have an debugger attached to it so that it can use the serial output and the send unicast process can be deleted because the sink do not need to send the data back to the WSN. The sensor reading process is replaced with serial print process. The process continuously iterates through the local encounter and separation lists and prints its content to the serial output.

The base station in our case an Raspberry pie unit is connected to the sink node serially and reads the incoming data with a python script. The data is then parsed, converted into a JSON objects and sent to the cloud over the 3G network.

(54)

(55)

Chapter 5 Testing and deployment experience

This chapter describes three different tests that were used during the project and drove the development forward. The test setup and test scenario will be presented together with the results from each testing method. The goal of the tests is to assure that the system works as intended and keep improving it until the requirements in the user cases are met

5.1 Cooja simulation tests

Cooja simulator comes together with the Contiki development environment can fully simulate 11 different hardware platforms[14]. Unfortunately the sensorTag that is used in this project is not fully supported meaning that the platform specific libraries such as sensors and buttons can not be simulated properly. The network related modules however such as Rime and RDC and ContikiMAC[9] can still be tested by running the simulation for a platform similar to the sensorTag.

5.1.1 Simulator advantages

The development was test driven where every small functional progress was tested using the simulation environment, especially during the network related tasks. The simulator is great tool and saved a lot of time. Running the tests directly on the hardware would complicate a lot of the work. Without the simulator every small change in the code would require that the new updated image would have to be uploaded on every unit. Flashing a single device takes about 2 minutes and testing some of the data collecting functions would require minimum of 5 sensor Tags, meaning that it would take around 10 minutes to update the system or fix a bug. Another big problem that got simplified by using the simulator was the test based on he wireless connectivity range. A great deal of tests were based on

(56)

having two nodes going out of connectivity range in order to test the generation of encounter data and separation log. Without the simulator the tests would require to physically walk away with a node until the signal was lost and then walk back again which would also lead to a very time consuming testing method.

Cooja simulator comes with an informative and intuitive graphical user interface. When a node is uploaded to the environment it appears as an mote object in the graphical grid. When clicking on a mote the connectivity range is visible as bigger circle around the mote. The motes are also easy movable out of each others connectivity range. Updates of code versions can simply uploaded to every mote in the grid by clicking the reload button.

5.1.2 Simulation test setup

As previously mentioned a great deal of functionality was tested using the simulation tool, this section will describe one specific test that was done in later stage of development. Starting off with the test case setup and then moving on to the test results that will be presented using screenshots and system print outs.

Test case for the simulation tool consists of 7 motes in total: 3 anchor motes, 1 sink mote and 3 mobile motes. To simplify the testing scenario lets divide the test in four events.

1. Event 1- Initial state, all of he mobile motes start out within a range of the sink node.

2. Event 2- Move to anchor node, mobile motes move out of the sink node to different anchor nodes

3. Event 3- Gather up, all mobile motes gather up at one anchor 4. Event 4- One mote goes back to sink mote.

The deployment of this testing scenario will cover the minimal requirements of the system. The test covers the events of two or more node encounters which should generate data in the encounter list and nodes benign separated for a while and then getting back together should create data in the separation log. Unfortunately sensor readings can’t be tested with this test since Cooja not fully supporting the sensorTag platform. The simulation platform used in this case was an Tmote Sky mote which uses similar radio module as the sensorTag.

5.1.3 Simulation results

(57)

5.1. COOJA SIMULATION TESTS 39

out of from the sink node. The print out of the sink node is the data that would be sent further to the base station (Raspberry pie).

Table 5.1: Definition of simulated node types Sink Node 7

Anchor Nodes 1 2 3 Mobile Nodes 4 5 6

5.1.3.1 Event 1

Initial state, mobile nodes are started within the communication range of the sink node. Event 1 is ongoing between time-stamp 0 and 50.

Figure 5.1: Event 1 - simulated

(58)

5.1.3.2 Event 2

Mobile nodes are spread to different anchor nodes. The sink node is not receiving any new data and only the current time-stamp of the system is printed. Event 2 is ongoing between time-stamp 50 and 100.

Current Timestamp: 100

5.1.3.3 Event 3

(59)

5.1. COOJA SIMULATION TESTS 41

5.1.3.4 Event 4

Mobile node 5 is moved back to sink node and sends the data it has collected between event 1 and 3 to the sink.

(60)

Encounter list:

ENCOUNTERS 0: COW ID 7.0 Encounter 5.0, with timestamp235 ENCOUNTERS 1: COW ID 7.0 Encounter 6.0, with timestamp46 ENCOUNTERS 2: COW ID 7.0 Encounter 4.0, with timestamp46 ENCOUNTERS 3: COW ID 5.0 Encounter 6.0, with timestamp39 ENCOUNTERS 4: COW ID 5.0 Encounter 4.0, with timestamp39 ENCOUNTERS 5: COW ID 4.0 Encounter 6.0, with timestamp37 ENCOUNTERS 6: COW ID 5.0 Encounter 3.0, with timestamp169 ENCOUNTERS 7: COW ID 6.0 Encounter 1.0, with timestamp106 ENCOUNTERS 8: COW ID 4.0 Encounter 2.0, with timestamp109 ENCOUNTERS 9: COW ID 3.0 Encounter 4.0, with timestamp162 ENCOUNTERS 10: COW ID 6.0 Encounter 3.0, with timestamp163 History log:

COW ID 7.0 was separated from 5.0, during timestamps:48-170 COW ID 5.0 was separated from 4.0, during timestamps:46-109 COW ID 5.0 was separated from 6.0, during timestamps:48-110 COW ID 6.0 was separated from 4.0, during timestamps:46-109 Current Timestamp: 200

5.2 Indoor test

The indoor test was carried out inside the SICS building to assure a test that cover the whole system functionality. Unlike the simulation test the sensors and the base station together with cloud platform could be tested properly.

5.2.1 Setup

To make it easier to interpret and compare test results the indoor test used the same four event based test case as in the simulations test. There are however some differences on how the data represented, each encounter post has 5 additional elements in its structure. Node ID and Encounter ID together with a time-stamp has the same structure but in the indoor test additional data could be acquired. As mentioned in section 4.3.1 the ambient sensor data is merged with encounter data.

Table 5.2: Merged encounter data structure

(61)

5.2. INDOOR TEST 43

and 0 means a reading error from the sensor . To catch precise activity movement required higher sample rate which could not be applicable together with other processes, more about this issue will be discussed in the evaluation chapter.

Same amount of nodes were used in the indoor test as in the simulation but the nodes are named after their rime addresses.

Table 5.3: Definition of indoor tested nodes Sink Node 40.131

Anchor Nodes 100.1 133.133 213.5 Mobile Nodes 203.133 227.128 56.128

How the anchor nodes and the sink node were placed in the building i illustrated in the figure 5.5.

Figure 5.5: Indoor test node placement

5.2.2 Deployment

(62)

format. Data from the Encounter list is labeled as DATA and Separation list data is labeled as HISTORY. Each entry in respective lists are separated by semicolon. The test was deployed in similar manner as in the simulation, starting of the mobile nodes within the range of the sink node. Start the anchor nodes in different locations show sown in figure 5.5. When the anchor nodes were setup the test continued with moving the mobile nodes according to the events described 5.1.2.

5.2.3 Results

5.2.3.1 Event 1

The mobile node are uploaded with the new code and started close to the sink node. This action generated following data that was sent to the base station. Timestamp 10 -60 DATA:40.131; 203.133; 53;30.812;27.62;37;0;65506 DATA:227.128; 203.133; 47;26.843;27.187;115;0;65518 DATA:40.131; 56.128; 52;30.812;27.00;37;105;65505 DATA:40.131; 227.128; 52;30.812;26.843;37;116;65503 DATA:203.133; 56.128; 44;27.218;27.125;0;114;65529 DATA:227.128; 56.128 45;26.832;27.122;115;114;65512 5.2.3.2 Event 2

All mobile nodes were moved to respective anchor nodes at time-stamp 60-130. No new data for the sink node to print.

203.133 -> 133.133 56.128 -> 100.1 227.128 -> 213.5

5.2.3.3 Event 3

All mobile nodes moved to the anchor node 100.1. The results from this test may differ from the simulations because there was no way to get node 203.133 to 100.1 without passing the sink node due to the shape of the building. Time-stamp 130 -270.

5.2.3.4 Event 4

(63)

5.2. INDOOR TEST 45 HISTORY:40.131;227.128;84;238 HISTORY:227.128;203.133;77;128 HISTORY:203.133;56.128;88;129 HISTORY:227.123;56.128;77;128 HISTORY:227.128;100.1;90;129 HISTORY:203.133;40.131;87;122 DATA:40.131; 203.133; 53; 30.812;27.62;37; 0; 65506 DATA:203.133; 113.133; 30; 0.000; 0.00; 0; 99; 65446 DATA:227.128; 40.131; 80;26.593;30.968;118;3;65503 DATA:227.128; 203.133; 59; 26.781;27.00;113;0;65509 DATA:40.131; 56.128; 89; 30.937;26.500;31;116;65448 DATA:40.131; 227.128; 271; 30.593;25.156;95;113;65508 DATA:227.128; 113.133; 44; 26.937;24.906;113;98;65447 DATA:203.133; 56.128; 64;26.937;26.750;0;105;65503 DATA:56.128; 227.128; 64;26.750;26.718;105;117;65515

5.2.4 Verification and data analysis

The test case was created using a controlled and predefined events to ensure that the system produces a very specific output that can easily be verified. Additionally same test case was used in two different testing environments to simplify the comparison of the test results. Since there are three different types of data that was generated the verification can be done separately for each one of the data streams.

Encounters verification can be done by taking a closer look at what happened during event one and four. In the first event when all mobile nodes are deployed close to the sink and the expected outcome should have six encounters - sink node encountering with three mobile nodes and three encounters between mobile nodes.

During the fourth event the expected outcome should have five additional encounters. Three encounters are added when each of the mobile nodes encounter the anchor nodes and additional two encounters when mobile nodes gather up close to a single anchor node during the third event. The expected outcome should have a total of 11 unique encounters during the fourth event. The table 5.4 illustrates a comparison between expected outcome and test results.

(64)

an anchor node. The separation list does not reach the sink node until the fourth event which also should add one entry to the separation list. The course of events should in total generate 4 entries in the separation log, three between the mobile node and one when one of the mobile nodes get back to the sink.

Table 5.4: Data verification

Expected outcome Simulation results Indoor test result Encounters during event 1 6 6 6 Encounters during event 4 11 11 12 Separations during event 4 4 4 6 Temperature sensor 25-27C - 25-30C Activity sensors 80-120 - 0 -120

Deviation in the indoor results were caused due to the shape of the building. One separation log was created between the first third event when node 227.128 had to pass additional anchor node 100.1 in the middle of the hallway before reaching it’s final destination. The second separation log was added during the third event when node 203.133 had to pass the sink node on the way to the anchor node 100.1.

The time-stamps for both encounter and separation data show that the course of events uphold the correct order. Separation logs show that three mobile nodes were separated between time-stamps 80 -130 which corresponds to separation at start of second event and the meet up at the third event.

Ambient sensors was not the main scope for the test and had a lower priority nevertheless there seem to bee a small deviation in the temperature values between the sink node and all other nodes. This was caused due to the debugger attached to the sink node which affected the ambient temperature measurement.

5.3 Field test

(65)

5.3. FIELD TEST 47

we could prepare and plan the deployment of the test. Additional sensroTags were ordered for the final test, ending up with a total of 18 sensorTag units.

5.3.1 Setup

The grazing land was empty upon our arrival which allowed us make last minute configuration and setup the anchor nodes. Initially range tests were made in the grazing environment in order to decide on where to set up the anchor nodes.

Range test result showed that the communication range between two nodes could go up to 30 meters. Based on these results the anchor nodes were placed according to the map in the figure below.

Figure 5.6: Node setup during field test

A total of 18 sensorTags were used during the field test: 1 sink node, 6 anchor nodes and 11 mobile nodes.

5.3.2 Deployment

(66)

Table 5.5: Definition of field tested nodes Sink Node 40.131

Anchor Nodes 100.1, 133.133, 213.5, 56.128, 227.128, 148.5

Mobile Nodes 203.133, 163.13, 5.3, 207.2, 144.1, 124.113, 191.6, 130.2, 159.2, 108.3, 102.1

participating in the test. A selection of roughly 30 cows were going to be released into the prepared grazing area. 10 of those cows were equipped with sensorTag collars. The cows were released after the anchor nodes, sink node and base station were up and running.

Figure 5.7: Anchor node and base station

Figure 5.8: Mobile nodes on collar

5.3.3 Results

(67)

5.3. FIELD TEST 49

station. The front end is in this case a website that fetches data from the cloud platform and presents it for the user. The layout of the website and how the data is presented is illustrated appendix A.

5.3.4 Problems during field test

The results showed that the separation log was not properly disseminated and only local separation records from the sink node appeared appeared in the cloud. Unfortunately when the error was detected there was not much that could be done to address the issue. Dismantling every node from each cow could not be done easily without having to bring the cows back to the barn.

Range tests were executed before the anchor nodes were placed to avoid having a fully connected network. The range tests showed that nodes had a a connectivity range between 30-40 meters but the test results however showed continuous encounters between the sink node an anchor node that was 100 meters away. The main difference between that specific anchor node compared to other was that it was attached to a tree at high altitude which greatly increased the wireless connectivity range.

(68)

(69)

Chapter 6 Evaluation

The developed experimental prototype of the system, will be evaluated based on the requirements described by the user cases in chapter 1. This chapter will also discuss the scalability, performance and precision of the system.

6.1 Requirements evaluation

This section will reflect back to the user cases presented in chapter one and evaluate them. Initially four user cases were defined to clarify what is to be expected from the experimental prototype. Use cases are evaluated by looking on results of the system and discussing how well the requirements are met.

1. Installation ad initialization . Test results from the field test show that the anchor placement is an crucial part during the installation. Line of sight and altitude differences in the environment need to be taken into account which makes it hard to prepare the software for of the shelf deployment. It’s preferable examine and run range tests on the pasture land before installation.

2. System configuration. Current implementation of allows configuration of key parameters but it can not be done wirelessly. Every node has to be detached from the collars and reprogrammed with a PC that has Contiki environment.

3. Data collection.

The indoor test results show that the system is capable of collecting the encounter data separation log and ambient sensor readings. However during the field test when more nodes were added to the system the requirement for the use cases was not fully met and only parts of data stream were collected properly.

Internet of things for monitoring grazing animals

Internet of things for

monitoring grazing animals

ALISHER ZAITOV

Internet of things for monitoring grazing cattles

Abstract

Sammanfattning

Contents

List of Figures

List of Tables

List of Acronyms and Abbreviations

Chapter 1

Introduction

1.1

Background

1.2

Purpose

1.3

Goal

1.4

Requirements

1.5

Risks, Consequences and Ethics

1.6

Methodology/Methods

1.7

Use cases

1.8

Usage scenario

Chapter 2

Technical Background

2.1

A monitoring system

2.2

WSN - Wireless Sensor Network

2.3

Communication stack

2.3.1

OSI model - Open System Interaction model

2.3.2

IEEE 802.15.4

2.3.3

MAC Layer in WSN

2.3.4

Opportunistic Networks

2.3.5

ZigBee

2.3.6

6LoWPAN

2.3.7

Rime

2.4

Contiki - Operating system for IoT

2.5

Hardware platforms for WSN

2.5.1

Arduino

2.5.2

Xbee

2.5.3

Raspberry PI

2.5.4

Texas Instruments SensorTag

2.5.5

Pinoccio

2.6

Related work

2.6.1

ZebraNet

2.6.2

Seal-2-Seal

Chapter 3

System Design

3.1

System architecture overview

3.1.1

Core WSN

3.1.2

Back End

3.1.3