UPTEC E 18 020

Examensarbete 30 hpJuni 2018

UWB-based wireless sensor network with medical application

Joakim Lindström

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

UWB-based wireless sensor network with medicalapplication

Joakim Lindström

This master thesis aims to develop a prototype of a wireless sensor network (WSN)using ultra wideband (UWB) radio and communication. The WSN consists of fivesensor nodes and one sink which is connected to an Android smartphone. Thesmartphone acts as a sensor data management unit and has the ability to displaysensor measurements. The sensor nodes include the sensors of an inertialmeasurement unit, an electrocardiogram (ECG) electrode set, a temperature sensor,a humidity sensor, and three ultrasonic sensors, and they are responsible for makingmeasurements, sending the measurements to, and forwarding the measurements fromother sensor nodes to the destination. The sink node receives the measurementsfrom the sensor nodes, and the measurements are displayed on the smartphone. The sensor nodes and the sink are equipped with DecaWave's DWM1000 UWBtransceiver which is compliant with the IEEE 802.15.4-2011 communication standardand enables the UWB communications, and a microcontroller, ATmega328, thathandles sensor data reading and transmission. Due to UWB pulses having high timeresolution, a location-based routing protocol based on time of flight distanceestimates is implemented. A prototype of a UWB-based WSN has been developed,tested and evaluated. The resulting prototype can operate in a peer-to-peer topologywith multi-hop capabilities. The results of the evaluation show that lower data rate,lower center frequency and wider bandwidth increases radio range and a longerpreamble sequence increases ranging accuracy. This comes at the cost of increasedtime of channel occupation and power consumption. From this thesis project it is indicated that UWB radio is a good choice forshort-distance radio communication applications such as WSNs. The measurementerrors in range estimates can be within 10 cm in line-of-sight. Networks compliantwith the IEEE 802.15.4-2011 communication standard should have low throughputrequirements as channel access mechanisms and functions related to reliable datatransfers introduce latency.

ISSN: 1654-7616, UPTEC E 18 020Examinator: Tomas NybergÄmnesgranskare: Ping WuHandledare: Håkan Sjörling

Populärvetenskaplig sammanfattning

Trådlösa sensornätverk är ett område som uppmärksammats mycket på senare år.

Användningsmområdet är brett tack vare ett stort utbud av sensorer och sträcker sig

från övervakning av jordbruk, aktiva vulkaner och krigszoner till medicinsk övervakn-

ing och patientlokalisering. Ett trådlöst sensornätverk kan bestå av ett fåtal till tusen-

tals så kallade sensornoder. Sensornoderna kan mäta en eller flera fysiska parame-

trar i sin omgivning och kommunicera trådlöst. Olika användningsområden ställer

olika krav på sensonoderna och nätverket. Vanligt förekommande krav är energief-

fektivitet, möjlighet att samexistera med befintliga trådlösa kommunikationssystem

samt små och billiga sensornoder. Dessa krav medför strikta restriktioner på bland

annat batterikapacitet, beräkningskapacitet och den trådlösa kommunikationen. Ul-

tra wideband är en trådlös kommunikationsteknologi som sänder information i korta

pulser. Korta pulser använder stor bandbredd vilket medför att tekniken kan sända

information med låg effekt, effekten kan vara så låg att befintliga kommunikation-

ssystem inte kan detektera signalen och därmed inte störas av den. Eftersom att

pulserna är korta i tid har ultra wideband en hög tidsupplösning. Detta medför att det

är möjligt att uppskatta avståndet mellan en sändare och en mottagare med hög nog-

grannhet. Med strikta krav på trådlösa sensornätverk kan ultra wideband teknologin

vara ett bra val för den trådlösa kommunikationen.

Syftet med detta examensarbete är att utveckla en prototyp av ett trådlöst sensornätverk

som använder ultra wideband teknologin för att sända information trådlöst. Proto-

typen ska baseras på en kommunikationsstandard, IEEE 802.15.4-2011, som lämpar

sig väl för trådlösa sensornätverk. Målet med prototypen är att sensornoder i nätver-

ket ska skicka sensordatan till en sink som är kopplad till en smartphone som kan

visa sensordatan. I många användningsområden ska ett stort område täckas och det

krävs routers för att datan från en sensornod ska kunna nå en sink. Ett krav på nätver-

ket är därför att alla noder ska kunna kommunicera med varandra genom routers

i nätverket. Eftersom att ultra wideband bidrar med möjlighet att noggrannt upp-

skatta avstånd mellan sändare och mottagare ska det utnyttjas för att avgöra vilken

väg datan ska överföras i nätverket.

Den utvecklade prototypen uppnår projektspecifikationerna och tillåter uppmätt sen-

sordata att skickas från sensornod till sink. Vägen till sinken baseras på avstånden

mellan noderna. Noggrannheten på distansmätningarna visar sig vara inom 10 cm

även upp till 30 m avstånd mellan sändare och mottagare. Kommunikationsstan-

darden bidrar med pålitlig dataöverföring inom nätverket men lämpar sig endast för

nätverk med låga krav på datagenomströmning och överföringshastighet.

Preface

This master thesis has been performed at Syntronic AB in Gävle during the spring of

2018 as the final part of the Master Programme in Electrical Engineering at Uppsala

University.

I would like to thank Ping Wu at Uppsala University for his continuous support, in-

spiration and will to be a part and contribute to this thesis.

Acknowledgements to Håkan Sjörling and Kent Zetterberg at Syntronic AB for taking

an interest in this thesis and providing me with the means to conduct this work at the

office in Gävle.

Uppsala, June 2018

Joakim Lindström

Contents1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Purpose and project specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Tasks and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Wireless sensor networks 6

2.1 Node architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Location-based routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Communication interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Serial Peripheral Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Inter-Integrated Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Ultra wideband communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.1 Ultra wideband signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.2 Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.3 Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.4 Ranging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6 IEEE 802.15.4-2011 communication standard . . . . . . . . . . . . . . . . . . . 18

2.6.1 Device types and classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6.2 Network topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6.3 Operational overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6.4 Ultra wideband physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.6.5 MAC protocol data unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Hardware implementation 29

3.1 Overview of the nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Arduino Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 DWM1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4.1 Inertial measurement unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4.2 Single lead heart rate monitor . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4.3 Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4.4 Temperature and humidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4.5 Ultrasonic sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Software implementation 42

4.1 Integrated development environment . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Overview of node operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Reading sensor data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 Transmission of sensor data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4.1 Network discovery and association . . . . . . . . . . . . . . . . . . . . . . 45

4.4.2 Communication on the network . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5 Sensor data collection and presentation . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Results and discussion 49

5.1 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.2 Routing protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3 Sensor measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Conclusions and future work 59

References 61

List of Figures1.1 Structure of the intended prototype, based on figure 1.2 in [1] . . . . . . . . 2

2.1 Architecture of a sensor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Seven layer OSI model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Service access points between the PHY, MAC and upper layers [5] . . . . . 10

2.4 Service primitives [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Gaussian pulse in time and frequency domain . . . . . . . . . . . . . . . . . . . 15

2.6 Binary phase-shift keying on a Gaussian monopulse [4] . . . . . . . . . . . . 15

2.7 Burst position modulation on a Gaussian monopulse [4] . . . . . . . . . . . 16

2.8 Spectrum allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.9 Single-sided two-way ranging [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.10 Double-sided two-way ranging using three messages [9] . . . . . . . . . . . . 17

2.11 IEEE 802.15.4 architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.12 IEEE 802.15.4 Star and peer-to-peer topologies [5] . . . . . . . . . . . . . . . . 21

2.13 The hidden terminal problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.14 The exposed terminal problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.15 IEEE 802.15.4-2011 UWB symbol structure . . . . . . . . . . . . . . . . . . . . . . 26

2.16 IEEE 802.15.4 UWB PPDU format [5] . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.17 IEEE 802.15.4 UWB PHY header [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.18 IEEE 802.15.4 MAC protocol data unit consisting of the MAC header,

MAC payload and MAC footer [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Overview of the sensor nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Overview of the sink node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 A sensor node consisting of (i) DWM1000 UWB transceiver, (ii) Arduino

Nano board and (iii) a sensor which is the ECG AD8232 heart rate monitor 30

3.4 The sink consisting of the DWM1000 UWB transceiver and Arduino Nano

board connected to a Huawei Honor 5X smartphone . . . . . . . . . . . . . . 31

3.5 Arduino Nano board [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6 DWM1000 module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.7 DWM1000 high level block diagram [13] . . . . . . . . . . . . . . . . . . . . . . . . 34

3.8 Geeetech 10 DOF Inertial Measurement Unit . . . . . . . . . . . . . . . . . . . . 36

3.9 AD8232 sensor breakout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.10 DS18B20 sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.11 DHT11 sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.12 HY-SRF05 sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Flow chart of sink node operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Flow chart of sensor node operation . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Discover and join network message chart between a sensor nodes layer

entities and a sinks layer entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4 Message chart between a sensor nodes layer entities transmitting data

and a sink layer entities receiving data . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 The prototype consisting of (i) ECG sensor node, (ii) sink, (iii) Huawei

Honor 5X smartphone, (iv) ultrasonic sensor node, (v) IMU sensor node,

(vi) temperature sensor node and (vii) humidity and temperature sen-

sor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Android application menus to view sensor measurements . . . . . . . . . . 50

5.3 Electrocardiogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.4 Accelerometer measurements during a transition between vertical and

horizontal position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 DHT11 sensor measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.6 DS18B20 temperature measurements . . . . . . . . . . . . . . . . . . . . . . . . . 58

List of Tables2.1 IEEE 802.15.4 UWB PHY frequency bands . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Arduino Nano specifications [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 DWM1000 pin description of used pins and the corresponding Arduino

Nano connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 DWM1000 supported channels and preamble codes . . . . . . . . . . . . . . . 35

3.4 Geeetech 10 DOF IMU pin description and connections . . . . . . . . . . . . 36

3.5 Sparkfun AD8232 description and connection of used pins . . . . . . . . . . 38

3.6 DS18B20 pin description and connections . . . . . . . . . . . . . . . . . . . . . . 39

3.7 DHT11 pin description and connections . . . . . . . . . . . . . . . . . . . . . . . 40

3.8 HY-SRF05 description and connection of used pins . . . . . . . . . . . . . . . 41

5.1 Performance metrics between two nodes in line-of-sight at different

distances operating at 1331.2 MHz bandwidth with center frequency

3993.6 GHz, 1024 preamble length, 0.11 Mbps data rate and 16 MHz PRF 51

5.2 Latency due to the CSMA/CA channel access mechanism from request-

ing to transmit before the first symbol is transmitted . . . . . . . . . . . . . . 52

5.3 Accuracy of the ranging protocol between two nodes in line-of-sight

at different distances operating at 1331.2 MHz bandwidth with center

frequency 3993.6 GHz, 1024 preamble length, 0.11 Mbps data rate and

64 MHz PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

AbbreviationsACL Access control list

ADC Analog-digital converter

AGV Automated guided vehicle

AOA Angle of arrival

BPM Burst position modulation

BPSK Binary phase-shift keying

CAP Contention access period

CCA Clear channel assessment

CFP Contention-free period

CRC Cyclic redundancy check

CSMA/CA Carrier-sense multiple access with collision avoidance

CSS Chirp spread spectrum

CTS Clear to send

DAC Digital-analog converter

DQPSK Differential quadrature phase-shift keying

DSSS Direct sequence spread spectrum

DSTWR Double-sided two-way ranging

ECG Electrocardiogram

FCS Frame check sequence

FFD Full-function device

GTS Guaranteed time slot

I2C Inter-integrated circuit

IC Integrated circuit

IDE Integrated development environment

IMU Inertial measurement unit

ISI Inter-symbol interference

MAC Medium access control

MCU Microcontroller unit

MEMS Microelectromechanical systems

MFR MAC footer

MHR MAC header

MISO Master input slave output

MOSI Master output slave input

MPDU MAC protocol data unit

MSDU MAC service data unit

NSDU Network service data unit

O-QPSK Offset quadrature phase-shift keying

OSI Open systems interconnection

PAN Personal area network

PCB Printed circuit board

PHR Physical header

PHY Physical

PIB PAN information base

PPDU Physical protocol data unit

PRF Pulse repetition frequency

PSD Power spectral density

PSDU Physical service data unit

PSR Preamble symbol repetitions

RF Radio frequency

RFD Reduced-function device

RSS Received-signal-strength

RTLS Real time location systems

RTS Request to send

RTT Round trip time

SAP Service access point

SCK Serial clock

SDA Serial data

SECDED Single error correct, double error detect

SFD Start of frame delimiter

SHR Synchronization header

SPI Serial peripheral interface

SS Slave select

SSTWR Single-sided two-way ranging

TOF Time of flight

USART Universal synchronous and asynchronous receiver-transmitter

UWB Ultra wideband

WSN Wireless sensor network

1. IntroductionThis section presents the background motivating this thesis, project specifications

and goals, tasks required to fulfill the specifications, how the thesis work is planned

and an outline of the report.

1.1 Background

Networks and wireless communications have become a large part of modern society,

enabling multiple users to share information and services. Networks with sensors

and actuators have existed for many years and such control systems can often be seen

in the industry, monitoring manufacturing equipment or industrial processes. Con-

ventionally, these networks are wired with physical cables connecting the devices [1].

Wired networks require large amounts of cables which come with a number of down-

sides. Cables require connectors that can become loose or break and are expensive

due to materials, labor and verification. Cable deployment further limits the appli-

cations of wired sensor networks. Deployment in rotating machinery and difficult

terrain, which are intended applications for wireless sensor networks (WSNs), may

in many cases be impossible. A wireless solution using radio waves significantly in-

creases the usefulness of sensor networks.

Advances in wireless communications, microelectromechanical systems (MEMS) and

integrated circuits (ICs) enable integration of wireless communications, processing

capabilities and sensors in a single low-cost and small sized package, called sensor

nodes [1]. WSNs have enormous potential for both consumer and military applica-

tions [2] and have been considered as one of the most important technologies for the

twenty-first century [3]. WSNs have received attention from both academia, where a

large amount of research activities have been carried out, and industry [3]. Wireless

networks of hundred of sensor nodes are already being used to monitor large geo-

graphical areas for modeling and forecasting environmental quantities such as pollu-

tion and flooding, collecting structural health information on bridges and controlling

usage of water [3]. Energy efficiency, security, interference, large-scale deployment

and self-managing are important aspects of WSNs which impacts the hardware and

software design.

The ultra wideband (UWB) technology has recently turned focus to consumer elec-

tronics and communications [4]. Along with the increase of wireless connections and

a crowded radio frequency spectrum, the UWB technology offers a solution by be-

1

ing able to coexist with current radio systems. Compared to the existing dominant

wireless communication today, which are mostly based on narrowband radios, UWB

communication has an advantage in terms of data rate, equipment cost, ranging ca-

pabilities and power consumption. Along with the increased market for low power,

low cost wireless devices with positioning capabilities, UWB systems is an attractive

option for current and future wireless applications [4].

The challenges of WSNs partially overlaps with the benefits of UWB communication,

making WSNs an interesting application of UWB communications.

1.2 Purpose and project specifications

The purpose of this thesis is to develop a prototype of a wireless sensor network using

ultra wideband radio. The WSN consists of sex nodes, five sensor nodes and one sink.

The sink is connected to a sensor data management unit which is a smartphone. The

structure of such a UWB-based WSN is shown in figure 1.1.

Figure 1.1: Structure of the intended prototype, based on figure 1.2 in [1]

Nodes consist of a microcontroller unit (MCU) and a UWB wireless communication

module, including antenna, and if the node is a sensor node, one or more sensors.

Communication interfaces between MCU, sensors and the communication module

is inter-integrated circuit (I2C), serial peripheral interface (SPI) or unique one-wire

protocols related to specific sensors. The UWB wireless communication module al-

lows wireless communication between nodes on the network.

The core hardware is the DecaWave’s DWM1000 module which is an IEEE 802.15.4-

2011 compliant wireless UWB transceiver. Therefore, the protocol stack should be

2

based on the IEEE 802.15.4-2011 communication standard.

The prototype should fulfill the following criteria:

• The network consists of at least five nodes, including the sink

• The sink is connected to a smartphone which has the ability to display received

sensor measurements in an Android application

• The network operates in a peer-to-peer topology with multi-hop capabilities

• The routing protocol is location-based due to the precise positioning capabili-

ties supplied by the UWB radio

The developed prototype should use sensors related to medical monitoring as long as

it is possible. However, the potential applications of the prototype is wider due to the

ability to change sensors to fit other applications. The project includes a performance

evaluation of the prototype.

1.3 Tasks and scope

The tasks of this thesis work can be divided into four categories, literature study, hard-

ware related work, software related work and evaluation. The development of the An-

droid application is not included in this thesis, nor is the performance of the Android

application, implementing signal processing and management of sensor data.

The literature study aims to present relevant theory and existing projects related to

WSNs or UWB communications. The tasks of the study includes:

• Studying theory and concepts related to WSNs and UWB communications

• Studying the IEEE 802.15.4-2011 communication standard

• Investigating relevant existing projects

To have functional nodes which together forms the network, these nodes have to be

constructed. The hardware part of the project includes the following tasks:

• Solder the DWM1000 communication modules to printed circuit boards (PCBs)

• Construct sensor nodes consisting of one or more sensors, a MCU and a UWB

transceiver

• Construct one sink consisting of a MCU and a UWB transceiver

3

The main part of this thesis is implemented in software. The software is responsible

for all functionality once the hardware components are connected and includes the

following tasks:

• Implement DWM1000 and sensor drivers

• Implement the communication between sink and smartphone

• Implement a MAC layer based on the IEEE 802.15.4-2011 communication stan-

dard

• Implement a network layer enabling a peer-to-peer multi-hop network includ-

ing a routing protocol based on UWB ranging

The evaluation aims to measure the performance of the communication, implemented

protocols and ranging accuracy.

1.4 Method

The first part of this thesis was the literature study. By studying theory and concepts

related to WSNs and UWB communications, and the IEEE 802.15.4-2011 communi-

cation standard, an overview of the intended prototype is obtained. Studying relevant

existing projects gives an introduction to challenges that may arise while implement-

ing a UWB-based WSN and provides information on useful software libraries.

After the literature study, implementing the basis of the network was in focus. Nodes

consisting of a microcontroller and a UWB transceiver were constructed. The goal

of this phase was to get a functional network in star topology and then extend the

network to peer-to-peer topology. The location-based routing protocol was imple-

mented based on UWB ranging during this phase.

When the network operated as specified in the project specifications, the nodes were

equipped with one sensor each. The sink was connected to a smartphone with an

Android application installed, capable displaying sensor measurements in real-time.

This phase included verification of all intended functionality, including protocols in

the stack, communication between the sink and the smartphone and functionality of

the sensors.

The remaining part of the thesis was to evaluate the prototype, focused on the per-

formance of the communications and UWB ranging accuracy.

4

1.5 Outline

Chapter 1 presents the background and motivation for this thesis, project specifica-

tions, tasks and workflow. Chapter 2 aims to present relevant theory and concepts

related to wireless sensor networks and ultra wideband communications, and in-

troduce the reader to the IEEE 802.15.4-2011 communication standard. Chapter 3

presents the implementation of the hardware components which together forms the

nodes on the network. Chapter 4 describes the software implementation of the pro-

totype and details on network operation. Chapter 5 presents the resulting prototype

and the results from the evaluation along with a discussion of the results. Chapter 6

contains conclusions related to the results and suggestions for further work.

5

2. Wireless sensor networksThis section presents the necessary theory and concepts related to wireless sensor

networks and ultra wideband communications. An overview of the IEEE 802.15.4-

2011 communication standard is given.

A wireless sensor network usually consists of a number of low-cost and low-power

sensor nodes. The sensor nodes are deployed in a region of interest, called the sensor

field. Figure 1.1 illustrates a WSN where sensor nodes collect data about the physical

environment in the sensor field and transmit the data to a sink. Nodes communicate

through the wireless medium over short distances to accomplish their tasks such as

transmitting and relaying data. Nodes are divided into categories based on their ob-

jective:

• A sensor node is equipped with one or more sensors intended to measure phys-

ical quantities

• A router is designed to relay data between other nodes

• A sink is a destination node, responsible for receiving data from the sensor nodes

A WSN consists of a few sensor nodes up to thousands of sensor nodes and one or

multiple sinks. The sensor nodes provide data on the network while the sink ac-

quires data. A router enables nodes which are out of radio range to communicate with

each other and presents alternative communication paths between sensor nodes and

sinks. A sensor node can also function as a router, relaying data from other sensor

nodes towards the sink. The sink is the destination of the sensor network and can be

equipped with sensors, be able to send control signals based on received data or it

can be deployed outside of the sensor field acting as a gateway to another network

such as the Internet. A sensor network on its own is insufficient, the network has to

be able to interact with other devices and/or networks.

A network can be classified as a single-hop or multi-hop network. In single-hop net-

works, the sensor nodes send the data directly to the sink. In multi-hop networks,

routers exist and allow multiple hops between sensor nodes and sink. An illustration

of a multi-hop communication path is shown in figure 1.1. In many WSN applica-

tions, direct communication between all sensor nodes and sinks is not possible. The

WSN may be deployed in harsh environments with poor channel conditions or cover

a large area where sensor nodes and sinks are not in radio range. Furthermore, the

channel between nodes may be attenuated due to obstacles in the radio path. Multi-

hop networks present a solution to such problems and are particularly suitable for

6

WSNs since sensor nodes can act as routers themselves.

Wireless communication enables the operation of WSNs. Most wireless networks use

radio waves to communicate since radio waves do not require line-of-sight between

transmitters and receivers. Other alternatives, such as optical communication, exists.

Optical communication has advantages in terms of size and transmission efficiency

but requires line-of-sight between transmitters and receivers. Different synchroniza-

tion, modulation and antenna techniques have been designed over the years with

efficient communication protocols. Many communication protocols, such as cellu-

lar systems and wireless local area networks do not consider the unique character-

istics of WSNs [3]. Other protocols developed with respect to WSN characteristics,

where the most crucial part is energy efficiency, are needed. Other important char-

acteristics are dynamic and unreliable environment, dense and random deployment,

self-managing, scalability and frequent topology changes [1][3].

The application areas of WSNs is determined by the range of available sensors. Due to

a large variety of sensors, the application areas are wide and can be both indoors and

outdoors. Applications include continuous monitoring, event detection, mobile tar-

get tracking and localization and automation control [1]. In the industry, WSNs can

be deployed to monitor the condition of manufacturing equipment, monitor man-

ufacturing processes or track an industrial automated guided vehicle (AGV) inside

the sensor field. Military applications include battlefield monitoring, enemy track-

ing and detection of chemical attacks. WSNs for medical monitoring, monitoring vi-

tal signs such as heart rate, respiratory rate and temperature, would increase patients

comfort and is an intended application of WSNs.

2.1 Node architecture

The nodes in a WSN have to meet specific application requirements but generally

consist of four subsystems [1]:

• The power subsystem which provides power to the node

• The sensing subsystem consisting of one or more sensors to monitor physical

properties

• The computing subsystem consisting of a microcontroller, which include mem-

ories to process and store data

• The communication subsystem consisting of radio frequency (RF) hardware for

wireless communication

7

Sensors Microcontroller Transceiver

Power supply

Figure 2.1: Architecture of a sensor node

The power subsystem is a crucial part of the node and is responsible for storing and

providing power. Energy scavenging techniques is an active research subject to ex-

tend the capacity of the power subsystem. However, most nodes are simply powered

by a battery. The sensing subsystem is optional, depending on the intended func-

tion of the node, and includes one or more sensors which acquire information from

the physical surrounding. The sensing subsystem must provide a communication

interface compatible with the microcontroller, possibly the communication inter-

faces described in section 2.4 or simply an analog signal if the microcontroller has

an analog-digital converter (ADC) peripheral. The computing subsystem is respon-

sible for all of the computing tasks such as data processing, controlling sensors and

executing protocols. The communication subsystem enables wireless communica-

tion between nodes on the network through the transmission medium. Nodes are

required to have a transmitter and a receiver, referred to as a transceiver, to commu-

nicate on the network. The architecture of a sensor node is shown in figure 2.1.

The hardware is an important part of WSN design. Nodes have to be cheap and small

to facilitate node deployment in harsh or hostile environments. This constraint limits

the battery capacity and usually excludes a main power source. The sensor nodes may

be deployed in locations that are difficult for human access and replacing batteries

could be impossible, meaning that the lifetime of the sensor node relies on the initial

power supply provided. To have a reasonable sensor node lifetime, the node must

be energy efficient. Low power consumption comes with more constraints, the com-

puting subsystem has low computational ability and the communication subsystem

should utilize low power by using low transmission power and limiting the amount of

time with the receiver enabled. Interference by other wireless systems operating on

a similar frequency band can reduce the performance of the WSN which introduces

the challenge of coexistence with other communication systems in the vicinity.

8

Physical layer

MAC layer

Network layer

Transport layer

Session layer

Presentation layer

Application layer

Figure 2.2: Seven layer OSI model

2.2 Protocol stack

The open systems interconnection (OSI) seven-layer model, shown in figure 2.2, forms

the basis of the WSN protocol stack [1]. The OSI model divides the network functions

into seven layers, the physical (PHY) layer, medium access control (MAC) layer, net-

work layer, transport layer, session layer, presentation layer and application layer.

Each layer in the stack is responsible for performing a set of tasks independently of

upper or lower layers in the stack and has a fixed interface between layers to exchange

data. The interface between layers conceptually includes two service access points

(SAP). Adjacent layers can exchange data between the layers through the correspond-

ing SAPs. Due to the SAPs, protocols at any layer can operate without knowledge of

protocol details at other layers. An illustration of the conceptual SAPs is shown in

figure 2.3.

The service provider provide the user with services through service primitives, illus-

trated in figure 2.4. A primitive can be one of four generic types:

• Request: The user requests the provider for a specific service

• Confirm: The provider gives the result of a previously requested service to the

user

• Indication: The provider notifies the user that an event related to a specific ser-

vice occurred

• Response: The user responds to a previously indicated internal event

The set of protocols associated with all layers is referred to as the protocol stack. The

seven-layer model is overly complex and difficult to implement due to too many lay-

ers [1] and a reduced protocol stack is adopted by WSNs. The WSN protocol stack

9

Figure 2.3: Service access points between the PHY, MAC and upper layers [5]

Figure 2.4: Service primitives [5]

10

consists of five layers, the PHY layer, MAC layer, network layer, transport layer and

application layer [1][2][3]. Some WSNs do not adapt the transport layer and use a

protocol stack of four layers, e.g. personal area networks compliant with the IEEE

802.15.4-2011 communication standard [5]. A quick summary of each layer in the

WSN protocol stack is given below.

The PHY layer is responsible for transmission and reception of bit streams over the

physical medium. This task includes frequency selection, modulation, encoding, de-

coding, and signal detection. The MAC layer is responsible for allowing multiple de-

vices to successfully share the physical medium. This task includes channel access

control, reliable delivery and error detection. The network layer is responsible for

establishing communication paths between nodes in the network and successfully

routing packets along these paths. The transport layer is responsible for providing

nodes with reliable and transparent end-to-end communications. The application

layer is closely related to the network user and is primarily responsible for encryp-

tion, processing and storage of data.

2.3 Location-based routing protocols

The routing protocol is an algorithm, part of the network layer, responsible for decid-

ing the transmission path from sensor nodes to sinks.

A proactive routing protocol determines the routes before they are needed and stores

the routes in a route table. The route table can be updated periodically or when the

topology changes. A reactive routing protocol invoke a route discovery procedure

on demand. A proactive routing protocol adds no additional latency for data delivery

but are not suitable for networks with frequent changes in topology [1]. Furthermore,

routing protocols can be classified as structure-based or operation-based. Location-

based routing protocols are a subset of structure-based routing protocols. The idea of

a location-based routing protocol is to utilize the advantage of node positions to route

data. Location of nodes may be determined by signal strengths, ranging exchanges

or any other positioning system.

If all ranges between nodes on the network is known, a node wishing to transmit data

to the sink can choose to forward the data to one of its neighbors closest to the sink,

minimizing the remaining distance the data has to travel. This scheme is known as

most forward within r, where r indicates the maximum radio range. Different types

of this scheme exists, e.g. choosing the nearest neighbor that has a smaller distance

to the sink but necessarily not the smallest possible distance.

11

2.4 Communication interfaces

The serial peripheral interface (SPI) and inter-integrated circuit (I2C) protocols are

well suited for communication between integrated circuits and on-board peripherals.

SPI is often used in embedded systems requiring high bit rates, e.g. between a MCU

and an ADC or a digital-analog converter (DAC). SPI is capable of achieving high bit

rates but is limited to small-sized networks. I2C is a protocol widely used as interface

between a MCU and sensors. I2C cannot achieve as high bit rate as SPI and is more

complex but does not have the same limitation on network size.

2.4.1 Serial Peripheral Interface

SPI is a synchronous four-wire bus protocol for short distance, full duplex commu-

nication [6]. The master of the bus is responsible for generating the clock signal on

the serial clock (SCK) line, synchronizing all the slaves connected to the bus. Two

wires are dedicated for transmitting and receiving data, the master input slave out-

put (MISO) line and the master output slave input (MOSI) line. The master transmits

data on the MOSI line and receives data transmitted by the slave on the MISO line.

The fourth wire is the slave select (SS) line, determining the slave currently active on

the bus. All devices on the bus can share MISO, MOSI and SCK lines but each device

requires a dedicated SS line.

Data transactions on the bus occur on the edge of the timing clock. On one edge of

the clock, the device sets one bit for output, and on the next edge of the clock, the

device reads one bit as input. Thus, both the master and the slave trade bits with

each other during data transactions.

One additional SS line per device keeps SPI limited to small-sized networks. SPI is a

fast protocol due to almost no overhead in the transactions and it is not uncommon

to have SPI buses in consumer electronics devices running as fast as 50 - 100 MHz

[6].

2.4.2 Inter-Integrated Circuit

I2C is a synchronous two-wire bus protocol for short distance, half duplex commu-

nication [6][7], synchronizing the connected devices and a serial data (SDA) line for

data transactions.

Communication between two devices starts with any device pulling the SDA line low

12

and generating a clock signal on the SCL line, becoming the master of the bus. The

overhead is 8 bits, consisting of a 7-bit address and one bit for read/write direction.

The address lets the master select the slave it intends to communicate with and the

read/write direction determines if the master wishes to transmit data to, or receive

data from the slave. When the transaction is finished, the master stops the clock and

releases the SDA line.

Acknowledgement is used to detect errors. After every byte, the receiving device sends

a bit indicating if the byte has been received successfully or not.

Multiple devices, up to 128 in the standard I2C protocol, can connect to the two-wire

bus with no additional wires due to the addressing scheme.

2.5 Ultra wideband communication

UWB signals use a large bandwidth to directly transmit a digital sequence of short

pulses of RF energy. Due to the short time duration, the UWB pulses spread their en-

ergy across a wide range of frequencies with low power spectral density (PSD). This of-

fers several advantages over conventional narrowband communication systems such

as large throughput, coexistence with other radio systems and robustness to jam-

ming and eavesdropping due to low probability of detection. The short pulse du-

ration leads to high time resolution, making UWB signals less sensitive to multipath

interference than traditional narrowband systems. The low-frequency components

of the pulses have high penetration abilities, allowing the pulses to propagate effec-

tively through materials such as trees and ground surfaces. UWB transmitters and

receivers can be made smaller, cheaper and consume less power compared to nar-

rowband communication systems [4]. UWB is regulated around the world by differ-

ent agencies depending on region. The federal communications commission in the

U.S. allocated 3.1 - 10.6 GHz to UWB communications and limited the allowed trans-

mission power to -41.3 dBm/Hz. The power regulation limits the propagation range

of UWB signals which limits UWB systems to short-distance communication.

2.5.1 Ultra wideband signals

Signals can be classified as narrowband, wideband or ultra wideband by fractional

bandwidth. The bandwidth is defined as the frequency band bounded by the points

that are 10 dB below the highest radiated emission, based on the complete trans-

mission system including the antenna. The upper boundary is denoted fh , the lower

13

boundary is denoted fl and the fractional bandwidth, denoted F B , is defined in equa-

tion (2.1).

F B = 2fh − fl

fh + fl(2.1)

A signal with fractional bandwidth less than 1% is classified as a narrowband signal,

between 1% and 20% is classified as a wideband signal and signals with larger frac-

tional bandwidth than 20% is classified as a UWB signal [8]. A signal is also classified

as a UWB signal if the bandwidth is equal to or greater than 500 MHz [4].

The Shannon Capacity, equation (2.2), where C is the capacity, B is the bandwidth

and SN R is the signal-to-noise ratio illustrates that the channel capacity, or data rate,

increases linearly with the bandwidth. UWB systems which utilize large bandwidth

can expect high-capacity channels. Since the channel capacity is logarithmically de-

pendent on the SNR, UWB systems can operate in harsh channels with low SNR and

still maintain large channel capacity [4].

C = Bl o g2(1+SN R ) (2.2)

UWB signals often consist of a Gaussian pulse shape, shown in figure 2.5, because

the shape is easily generated [4]. The first derivative, a Gaussian monocycle, or the

second derivative, Gaussian doublet are commonly used.

2.5.2 Modulation

Digital information must be added to the analog pulse by modulating the pulse. There

exists several modulation methods for UWB systems, including time-based and shape-

based techniques.

2.5.2.1 Binary phase-shift keying

Binary phase-shift keying (BPSK) is a modulation scheme where information is con-

veyed by the polarity of the pulse. For a pulse p (t ), the symbols si is modulated by

si =σi p (t ) where σi = {−1, 1}. An unmodulated pulse train and a pulse train modu-

lated with BPSK is shown in figure 2.6.

14

0 5 10 15 20 25 30 35 40 45 50

Time (fs)

-1

-0.5

0

0.5

1A

mplit

ude

Gaussian pulse

0 200 400 600 800 1000 1200 1400 1600 1800

Frequency (THz)

0

0.1

0.2

0.3

Magnitude

Frequency spectrum

Figure 2.5: Gaussian pulse in time and frequency domain

Figure 2.6: Binary phase-shift keying on a Gaussian monopulse [4]

2.5.2.2 Burst position modulation

Burst position modulation (BPM) conveys information by the position of the pulse.

For a pulse p (t ), the symbols si is modulated by si = p (t −τ)whereτ is the delay of the

pulse. An unmodulated pulse train and a pulse train modulated with BPM is shown

in figure 2.7.

15

Figure 2.7: Burst position modulation on a Gaussian monopulse [4]

2.5.3 Interference

The UWB spectrum overlaps with the spectrum allocated to 802.11a, more commonly

known as WiFi, shown in figure 2.8. Due to regulatory power restrictions for UWB sys-

tems, they are in the category of unintentional radiators and usually resides below the

noise floor of a conventional narrowband system [8]. UWB systems often use a corre-

lation receiver and have inherent immunity to interference from narrowband signals

because of the short time window used at the receiver [4]. These characteristics en-

able UWB systems to coexist with current radio services with low, if any, interference

[8].

Figure 2.8: Spectrum allocations

2.5.4 Ranging

Due to the high time resolution, individual multipath components can be resolved

at the receiver. This benefits time of flight (TOF) and angle of arrival (AOA) methods.

16

Figure 2.9: Single-sided two-way ranging [9]

Figure 2.10: Double-sided two-way ranging using three messages [9]

Received-signal-strength (RSS) and AOA have lower ranging accuracy and are more

complex methods compared to TOF methods.

One-way TOF methods require the transmitter and receiver clocks to be accurately

synchronized. For this reason, a two-way TOF method is often used which is not lim-

ited by this restriction.

Two-way TOF methods measure the round trip time (RTT) of a message exchange be-

tween two devices, shown in figure 2.9. Both devices involved in the ranging exchange

timestamp received and transmitted frames. Measuring one RTT is commonly known

as single-sided two-way ranging (SSTWR). The accuracy of SSTWR is dependent on

the reply time since device A measures Tr o und and device B measures Tr e p l y on their

local clocks which has some offset error from their nominal frequency. As the reply

time increases, the error due to clock drift increases [9].

Double-sided two-way ranging (DSTWR) methods combine measurements of two

17

RTT to minimize the error introduced by the clock offset. The responder to the first

RTT measurement initiates the second RTT measurement. DSTWR methods require

four messages and one additional message if the initiator requests the calculated

range. If the third message from device A includes the timestamp of the third mes-

sage, the number of messages can be reduced to three or a total of four messages if

both devices need the calculated range. DSTWR using three messages is shown in

figure 2.10. The estimated TOF is calculated according to equation 2.3.

Tp r o p =Tr o und 1 ∗Tr o und 2−Tr e p l y 1 ∗Tr e p l y 2

Tr o und 1+Tr o und 2+Tr e p l y 1+Tr e p l y 2(2.3)

2.6 IEEE 802.15.4-2011 communication standard

The IEEE 802.15.4 communication standard specifies the PHY and MAC layer for low-

rate wireless personal area networks (PANs). The IEEE 802.15.4 architecture is shown

in figure 2.11. The standard has the traditional PHY layers of 780, 868, 915, 950 and

2450 MHz and a UWB physical layer which was introduced in 2007.

Figure 2.11: IEEE 802.15.4 architecture

The standard was developed with limited power supply in mind [5] and aims to over-

come the problems associated with existing standards such as Bluetooth and WiFi [1].

It provides for low complexity, low cost, low power consumption low data rate, ease of

installation, reasonable battery life and reliable data transfer. A PAN is a simple and

inexpensive communication network for wireless connectivity in applications with

limited resources, such as power and computational ability, and relaxed through-

put requirements. The protocol stack is simple and does not require any infrastruc-

ture. It is suitable for short-range communications, typically within a range of 100m

[3].

The PHY layer in the IEEE 802.15.4-2011 communication standard is responsible for

the following tasks [5]:

• Activation and deactivation of the radio transceiver

18

• Energy detection within the current channel

• Link quality indicator for received packets

• Clear channel assessment (CCA) for the carrier sense multiple access with col-

lision avoidance (CSMA/CA) mechanism

• Channel frequency selection

• Data transmission and reception

• Precision ranging for UWB PHYs

The MAC layer in the IEEE 802.15.4-2011 communication standard responsible for

the following tasks [5]:

• Generating network beacons if the device is a coordinator

• Synchronizing to network beacons

• Supporting PAN association and disassociation

• Supporting device security

• Employing the CSMA/CA mechanism for channel access

• Handling and maintaining the GTS mechanism

• Providing a reliable link between two peer MAC entities

2.6.1 Device types and classes

Devices in a PAN are divided into two different types: a full-function device (FFD) and

a reduced-function device (RFD). An FFD provides all defined MAC services while

an RFD provides a reduced set of the defined MAC services. Therefore, an RFD re-

quires less processing and memory resources but provides limited services on the

PAN. RFDs are used to execute simple tasks, such as obtain sensor measurement and

transmit sensor data to a coordinator. Both types of devices are required to have a

unique 64-bit extended IEEE address. Devices which have associated to a PAN may

have been allocated with a 16-bit short address which is unique within the PAN. De-

vices use either the extended or the short address for communication on the PAN.

The short address allows shorter packets, thus optimizing the use of network band-

width. Devices are further divided into classes based on their capabilities on the net-

work.

19

2.6.1.1 PAN coordinator

There must be one and only one PAN coordinator on the network. The PAN coor-

dinators responsibility is to initiate and manage the network. The tasks of the PAN

coordinator include:

• Assigning a PAN ID to the network

• Selecting the working complex channel

• Handling requests from other devices, such as association and data requests

A PAN coordinator must provide all MAC services and therefore must be an FFD.

2.6.1.2 Local coordinator

One or more local coordinators can exist within the PAN. The responsibilities of a

local coordinator include:

• Handling requests from other devices, such as association and data requests

• Relaying messages

A local coordinator must provide all MAC services and therefore must be an FFD.

2.6.1.3 End device

An end device has a more simple input/output function without any coordinating

functionality. The end devices associate to the network through the PAN coordinator

or any local coordinator.

End devices does not have to provide all MAC services and can be an RFD.

2.6.2 Network topologies

A PAN compliant with the standard operates in either a star or a peer-to-peer topology

shown in figure 2.12.

In a star topology, the communication is established between devices and the PAN

coordinator. The PAN coordinator initiates and manages the network and devices

wishing to associate to the network must associate through the PAN coordinator. If a

message is meant for any other device than the PAN coordinator, the PAN coordinator

must be able to relay the message to its final destination. Multiple star topologies

20

Figure 2.12: IEEE 802.15.4 Star and peer-to-peer topologies [5]

operating in the same area are required to have different PAN identifiers and operate

independently of each other.

The peer-to-peer topology allows communication between any two devices as long as

they are within radio range of one another. A PAN coordinator initializes the network

but does not limit the communication within the network. The peer-to-peer topology

enables implementation of more complex network topologies, such as tree and mesh.

Devices with relaying capabilities on the network enable devices which are not within

radio range of each other to communicate.

The coverage area of a star topology is limited since all devices must be in range with

the PAN coordinator. The peer-to-peer topology has a larger coverage area due to

alternative routes between the devices. Furthermore, due to no alternative routes,

the PAN coordinator in a star topology can be a bottleneck in the network and cause

congestion. If the channel fails between the PAN coordinator and associated devices

in a star topology, the network is no longer functional.

2.6.3 Operational overview

The standard allows network synchronization through an optional superframe struc-

ture. The superframe structure requires the coordinator to periodically transmit a

network beacon. The beacon identifies the PAN and describes the structure of the

superframe. The time between two beacons is divided into 16 slots of equal duration,

the active period. Optionally, the coordinator can define an inactive period where the

21

coordinator and the associated devices can enter a low-power mode since all data

transfers occur during the active period. The active period can further be divided

into two periods, the contention access period (CAP) and the contention-free period

(CFP).

Devices transmitting during the CAP use slotted carrier-sense multiple access with

collision avoidance (CSMA/CA) or ALOHA as channel access mechanism. The de-

vices compete with each other for channel utilization during this period. The CFP,

which occurs after the CAP in the end of each superframe, consists of guaranteed

time slots (GTSs). The PAN coordinator allocates a maximum of seven GTSs to de-

vices on the network which ensures that one or more devices are able to transmit in

each superframe. GTSs is useful in low-latency applications or applications requiring

specific data bandwidth [5]. Multiple GTSs can be assigned to the same device.

Networks using the superframe structure are referred to as beacon-enabled networks.

Nonbeacon-enabled networks do not use periodic beacons to synchronize the net-

work and have no ability to guarantee time slots to devices. The coordinator uses

the beacon for network discovery only. Data transfers can occur at any time in a

nonbeacon-enabled network. Devices use unslotted CSMA/CA or ALOHA as chan-

nel access mechanism, competing with each other for channel utilization. The PAN

coordinator must have the receiver enabled at all times to manage the network.

2.6.3.1 CSMA/CA

The devices in a wireless network have to share a common medium for signal trans-

mission. CSMA/CA is a channel access mechanism utilized in the IEEE 802.15.4-2011

communication standard.

PANs compliant with the standard use either unslotted or slotted CSMA/CA as chan-

nel access mechanism.

Unslotted CSMA/CA performs clear channel assessment (CCA) after a random back-

off period each time a device wishes to transmit data or MAC commands. If the chan-

nel is found to be idle, the device transmits the requested physical service data unit

(PSDU). If the channel is found to be busy, the device waits another random backoff

period before accessing the channel again.

Slotted CSMA/CA aligns the backoff period with the start of the beacon. When a de-

vice wishes to transmit data during the CAP, it selects a random time slot and performs

CCA. If the channel is found to be idle, the device transmits on the next time slot. If

the channel is found to be busy, the device randomly selects another time slot and

attempts to access the channel again.

22

Node A Node B Node C

Figure 2.13: The hidden terminal problem

Node A Node B Node C Node D

Figure 2.14: The exposed terminal problem

The CSMA/CA channel access mechanism works well when all nodes can detect each

other’s transmissions and the propagation delay is small [2]. The hidden terminal

problem, illustrated in figure 2.13, occurs when a node is in radio range of the near-

est neighbor but no others nodes on the network. Node A and node C both want to

transmit data to node B. Both nodes will conclude that the channel is idle and start

to transmit, causing a collision. Node C is hidden from node A and vice versa. The

exposed terminal problem, illustrated in figure 2.14, occurs when node B wishes to

transmit to node A at the same time node C is transmitting to node D. Node B is in

radio range with node C and will conclude that the channel is busy even though the

transmission would not cause a collision.

2.6.3.2 ALOHA

Devices using the ALOHA protocol do not sense the medium or wait for a specific time

slot before transmission. When the device has data to transmit, it simply transmits

the data regardless of channel conditions. If the network is lightly loaded and the

probability of collisions is small the ALOHA protocol is appropriate [5].

2.6.3.3 Acknowledged transmission

Acknowledged transmission is a mechanism to improve the probability of success-

ful delivery. Frames can be sent with or without an acknowledgement request. A

received frame with the acknowledgement request flag set should be acknowledged

by the recipient by transmitting an acknowledgement frame. A device transmitting a

frame with the acknowledgement request flag set should wait a predefined period of

time for an acknowledgement frame. If an acknowledgement frame is received within

the period, the transmission is considered successful, otherwise the device should

conclude that the transmission attempt has failed and possibly retransmit the frame,

depending on network configurations. If the retransmission attempts exceeds the

maximum number of retransmissions, indicated by the network configurations, the

23

MAC layer will notify the higher layer that the transmission has failed. Devices trans-

mitting without an acknowledgement request automatically assume that the trans-

mission was successful.

2.6.3.4 Security

The MAC layer provides basic security based on symmetric-key cryptography passed

down from the higher layers. It is assumed that higher layers generate and stores the

keys securely. It is optional for devices to implement the security features. Security

services provided includes:

• Access control: Each device keeps an access control list (ACL) containing other

devices which are allowed to communicate with the device.

• Data encryption: Data is protected from eavesdropping by symmetric cryptog-

raphy.

• Data integrity: An integrity code protects data from being modified by devices

without the cryptographic key and ensures that the data is transmitted from the

device with the cryptographic key.

• Replay protection: A frame counter protects devices from replay attacks.

2.6.4 Ultra wideband physical layer

The IEEE 802.15.4-2011 communication standard includes a number of different PHYs

such as direct sequence spread spectrum (DSSS) PHYs employing offset quadrature

phase-shift keying (O-QPSK) or BPSK modulation, chirp spread spectrum (CSS) PHYs

employing differential quadrature phase-shift keying (DQPSK) modulation and UWB

PHY which combines BPM and BPSK modulation.

Since this thesis focuses on UWB communications, the details on other PHYs will be

omitted.

2.6.4.1 Radio frequency requirements

The UWB PHY supports three independent frequency bands, the sub-gigahertz band,

which consists of a single channel and occupies the spectrum from 249.6 MHz to

749.6 MHz, the low band, which consists of four channels and occupies the spec-

trum from 3.1 GHz to 4.8 GHz and the high band, which consists of 11 channels and

24

occupies the spectrum from 6.0 GHz to 10.6 GHz. Channel number, center frequency

and bandwidth are listed in table 2.1.

Table 2.1: IEEE 802.15.4 UWB PHY frequency bands

Channel number Center frequency [MHz] Bandwidth [MHz]

0 499.2 499.2

1 3494.4 499.2

2 3993.6 499.2

3 4492.8 499.2

4 3993.6 1331.2

5 6489.6 499.2

6 6988.8 499.2

7 6489.6 1081.6

8 7488.0 499.2

9 7987.2 499.2

10 8486.4 499.2

11 7987.2 1331.2

12 8985.6 499.2

13 9484.8 499.2

14 9984.0 499.2

15 9484.8 1354.97

Each channel support at least two preamble codes. A channel combined with a pream-

ble code is termed a complex channel. The standard defines 24 preamble codes with

perfect autocorrelation properties, which allows a coherent receiver to determine the

impulse response of the channel [9]. Knowledge of the impulse response of the RF

channel enables the receiver to resolve the channel in detail and determine the arrival

of the direct path accurately, turning multipath interference into a positive effect, ex-

tending the operating range [9]. The use of codes within each channel is restricted

and assigned such that interchannel communications is enabled. Devices operating

on different preamble codes can, under certain circumstances, operate simultane-

ously as if on different channels due to the preamble codes being semi-orthogonal

[9].

2.6.4.2 Modulation

A combination of BPSK, described in section 2.5.2.1, and BPM, described in section

2.5.2.2, is used to modulate the symbols. BPM-BPSK supports both coherent and

25

Burst here ’0’ Guard interval Burst here ’1’ Guard interval

Figure 2.15: IEEE 802.15.4-2011 UWB symbol structure

Figure 2.16: IEEE 802.15.4 UWB PPDU format [5]

noncoherent receivers using a common signaling scheme [5].

Each symbol is composed of one active burst of UWB pulses and is divided into four

quarters. The first and the third quarters are termed BPM intervals. A burst in the first

BPM interval indicates one bit, 0, and a burst in the second BPM interval indicates

one bit, 1. In addition to the bit modulated by the position of the burst, the polarity

of the burst indicates a second bit. The second and fourth quarter is guard intervals

which limit the amount of inter-symbol interference (ISI) caused by multipath [5].

Each BPM interval can be divided into time-hopping slots which provides for multi-

user access interference rejection. The symbol structure is shown in figure 2.15.

Since only one burst is allowed per symbol, 50% of the transmission time is unused

which is a disadvantage of BPM modulation.

2.6.4.3 Physical protocol data unit

The UWB physical protocol data unit (PPDU), shown in figure 2.16, consists of a syn-

chronization header (SHR) preamble, the physical header (PHR) and the data pay-

load. The SHR preamble aids receiver algorithms and consists of a preamble se-

quence and a start of frame delimiter (SFD). The preamble sequence is a repeated

sequence of pulses determined by a preamble code. The length of the preamble se-

quence is determined by the preamble symbol repetitions (PSR). The number of sym-

bols in the preamble sequence is 6, 64, 1024 or 4096. The SFD is 8 or 64 symbols.

The SHR is coded at 1.01 Msymbols/s, 0.25 Msymbols/s or 0.98 Msymbols/s depend-

ing on the length of the preamble code and the oscillators pulse repetition frequency

(PRF).

The SFD marks the end of the preamble and the start of the switch into BPM-BPSK

modulation.

The PHR, shown in figure 2.17, consists of 19 bits and lets the receiver know necessary

26

Figure 2.17: IEEE 802.15.4 UWB PHY header [5]

information for successful decoding of the packet. The PHR includes six single error

correct, double error detect (SECDED) check bits to protect the PHR against errors

caused by channel impairments and noise. The PHR is transmitted at 0.85 Mbps for

all data rates greater than or equal to 0.85 Mbps and at 0.11 Mbps for the 0.11 Mbps

data rate. Allowed data rates are 0.11 Mbps, 0.85 Mbps, 6.81 Mbps and 27.24 Mbps

specific for mean PRF of 15.60 or 62.40 MHz and 1.70 Mbps specific for mean PRF of

3.90 MHz.

The data field contains the octets intended for transmission as requested by the MAC

layer. The data field is encoded using a Reed-solomon block code, adding 48 parity

bits, followed by a symmetric convolutional encoder. The data field is then spreaded

and modulated using BPM-BPSK modulation.

2.6.5 MAC protocol data unit

A general MAC protocol data unit (MPDU), which occupies the data field in the PPDU

is shown in figure 2.18.

Figure 2.18: IEEE 802.15.4 MAC protocol data unit consisting of the MAC header, MAC

payload and MAC footer [5]

The MAC header (MHR) contains information about the frame such as frame type,

destination and source addresses. Four different frame types are defined in the stan-

dard, a beacon frame, a data frame, an acknowledgement frame and a MAC com-

mand frame. The frame payload contains information specific to individual frame

27

types. E.g, for a data frame, the payload consists of the data intended for the recipient.

The frame payload may be cryptographically protected, depending on if the frame is

secured or not. The MAC footer (MFR) contains a frame check sequence (FCS) field

which contains a 16-bit cyclic redundancy check (CRC) code for error detection.

The frame structure has been designed with low complexity in mind while at the

same time keeping the frames sufficiently robust for transmission on a noisy chan-

nel [5]. A maximum frame size of 127 bytes is supported, including the MHR and the

MFR.

2.6.5.1 Frame rejection

The MAC layer is able to filter incoming frames and only present frames that are of

interest to the higher layers. The IEEE 802.15.4-2011 frame filter passes all received

frames which fulfill the following criteria [5]:

• The FCS field contains a correct value

• The frame type is beacon, data, acknowledgement or MAC command

• The frame version control flag in the frame control is not a reserved value

• The destination PAN identifier matches the devices PAN ID or is the broadcast

PAN identifier

• The destination address matches the devices extended or short address, or is

equal to the broadcast address

• If the frame type is a beacon frame, the source PAN identifier shall match the

devices PAN ID or be equal to the broadcast PAN ID

• If only source addressing fields are included in a data or MAC frame, only a PAN

coordinator with matching PAN ID accepts the frame

28

3. Hardware implementationThis section presents the hardware related to the nodes which together forms the

wireless sensor network, the communication interface between hardware compo-

nents, the components responsibilities and the physical layer of the protocol stack.

3.1 Overview of the nodes

The UWB-based sensor nodes consist of one sensor, one DWM1000 UWB transceiver

and one Arduino Nano board. An overview of such a sensor node is shown in figure

3.1. The MCU manages reading sensor measurements (data) and sending the data to

other nodes. The sensors and the DWM1000 module is powered by the Arduino Nano

which is powered by a USB cable connected to a PC or an electric socket with a power

adapter.

Sensors

Arduino Nano

with MCU

ATmega328

UWB

transceiver

DWM1000

Power supply by USB

Figure 3.1: Overview of the sensor nodes

The sink node consists of one DWM1000 UWB transceiver and one Arduio Nano. The

MCU exchanges data and commands with the DWM1000 UWB transceiver to receive

and transmit on the physical channel. The node is powered by a USB connection to

a smartphone and sends sensor measurements to the smartphone through the USB

connection. An overview of the sink including the smartphone is shown in figure

3.2.

The hardware components are connected together by wires on a breadboard. A con-

structed sensor node is shown in figure 3.3 and the sink is shown in figure 3.4. The

communication interface between the MCU and the DWM1000 transceiver is SPI

while the communication interface between the MCU and the sensors is I2C or a

sensor-specific one-wire bus.

29

Smartphone

Arduino Nano

with MCU

ATmega328

UWB

transceiver

DWM1000

Figure 3.2: Overview of the sink node

Figure 3.3: A sensor node consisting of (i) DWM1000 UWB transceiver, (ii) Arduino

Nano board and (iii) a sensor which is the ECG AD8232 heart rate monitor

30

Figure 3.4: The sink consisting of the DWM1000 UWB transceiver and Arduino Nano

board connected to a Huawei Honor 5X smartphone

31

3.2 Arduino Nano

Arduino Nano is a board with an ATmega328 microcontroller. The microcontroller is

preburned with a bootloader and the board can be powered by a Mini-B USB con-

nection. Arduino Nano specifications is shown in table 3.1 and a figure of the board

is shown in figure 3.5.

Figure 3.5: Arduino Nano board [10]

The ATmega328 microcontroller is a low-power 8-bit CMOS microcontroller based on

the AVR enhanced RISC architecture. It has the following peripherals [11]:

• One 16-bit Timer/Counter with Separate Prescaler, Compare Mode, and Cap-

ture Mode

• Two 8-bit Timer/Counters with Separate Prescaler and Compare Mode

• Real Time Counter with Separate Oscillator

• Six PWM channels

• 8-channel 10-bit ADC in TQFP and QFN/MLF package

• 6-channel 10-bit ADC in PDIP Package

• One Programmable Serial USART

• Two Master/Slave SPI Serial Interface

• One Byte-oriented 2-wire Serial Interface (I2C compatible)

• Programmable Watchdog Timer with Separate On-chip Oscillator

• One On-chip Analog Comparator

32

• Interrupt and Wake-up on Pin Change

The MCU on the Arduino Nano board is the core of the nodes, controlling the UWB

transceiver and any connected sensors. The sink’s microcontroller is also responsible

for communication with the smartphone.

Table 3.1: Arduino Nano specifications [10]

Architecture AVR

Microcontroller asdfasdfasdfasdfasdfasdf ATmega328

Flash memory 32 kB

SRAM 2 kB

EEPROM 1 kB

Operating voltage 5 V

Clock frequency 16 MHz

ADC pins 8

Digital I/O pins 22

PCB size 18 x 45 mm

Weight 7 g

3.3 DWM1000

The DWM1000 communication module, shown in figure 3.6, is a UWB wireless transceiver

compliant with the IEEE 802.15.4-2011 communication standard and provides the

PHY layer. The module is optimized for applications in real time location systems

(RTLS) and WSNs.

Figure 3.6: DWM1000 module

DWM1000 is based on DecaWaves DW1000 IC [12] and integrates antenna, power

management and clock control. The DW1000 IC integrates an analog front-end trans-

33

Figure 3.7: DWM1000 high level block diagram [13]

mitter and receiver, and a digital back-end interface to a host processor. A block dia-

gram of the module is shown in figure 3.7.

The host communication is a slave-only SPI and requires an external master SPI bus

host controller to communicate with the DW1000 IC. The ATmega328 MCU on the Ar-

duino Nano board acts as the host microcontroller. Pin description and connections

between the DWM1000 and the Arduino Nano board is listed in table 3.2.

Table 3.2: DWM1000 pin description of used pins and the corresponding Arduino Nano

connection

Signal DWM1000 pin I/O Description Arduino Nano pin

RSTn 3 DIO Reset D9

VDD3V3 6 P 3.3 V power supply 3V3

VDD3V3 7 P 3.3 V power supply 3V3

SPICSn 17 DI SPI chip select D10

SPIMOSI 18 DI SPI data input D11

SPIMISO 19 DO SPI data output D12

SPICLK 20 DI SPI clock D13

IRQ 22 DO Interrupt request D2

GND 24 G Common ground GND

The DW1000 IC has support for three data rates defined in the IEEE 802.15.4-2011

communication standard, 0.11 Mbps, 0.85 Mbps and 6.8 Mbps. It is possible to trans-

mit with a PRF equal to 4 MHz, 16 MHz and 64 MHz as defined in the standard but

the receiver does not support the 4 MHz PRF. In addition to the defined preamble

lengths in the standard, the DW1000 IC supports 128, 256, 512, 1536 and 2048 pream-

34

ble lengths.

The DW1000 IC implements a subset of the defined channels in the IEEE 802.15.4-

2011 communication standard. Supported channels and preamble codes can be seen

in table 3.3.

Table 3.3: DWM1000 supported channels and preamble codes

Channel NumberPreamble codes

16 MHz PRF 64 MHz PRF

1 1, 2 9, 10, 11, 12

2 3, 4 9, 10, 11, 12

3 5, 6 9, 10, 11, 12

4 7, 8 17, 18, 19, 20

5 3, 4 9, 10, 11, 12

7 7, 8 17, 18, 19, 20

Additional preamble codes, 13-16 and 21-24, are available for dynamic preamble se-

lect at 64 MHz PRF.

The DW1000 IC notes the system clock when beginning the transmit of the PHR, adds

the transmit antenna delay and stores the resulting timestamp in a register. The host

controller is responsible for reading the register to get the transmit timestamp. Dur-

ing reception, the SFD is timestamped by the DW1000 IC. The receive antenna delay

and the correction factor determined by the first path detection algorithm is used to

adjust the reception timestamp. The reception timestamp is stored in a register and

the host controller is responsible for reading the register to get the reception times-

tamp. Timestamps enables the MCU to calculate ranges between two devices par-

ticipating in a ranging exchange. A function called delayed transmission allows the

host controller to select a transmission time and predict the transmission timestamp.

This function enables the three message DSTWR described in section 2.5.4.

The DW1000 IC is capable of automatically calculating and appending the 16-bit CRC

FCS and automatically calculating the 16-bit CRC FCS on reception, comparing the

received CRC to the calculated CRC. A mismatch between received and calculated

CRC indicates that the received frame contains errors.

Received frames, compliant with the IEEE 802.15.4-2011 communication standard,

can be parsed and filtered, according to the criteria described in section 2.6.5.1, by

the DW1000 IC. While parsing the frame, the DW1000 IC allows the functionality to

automatically transmit an acknowledgement frame if the parsed frame has the ac-

knowledgement request flag set.

35

3.4 Sensors

This section presents technical information about the sensors used in the wireless

sensor network prototype. A variety of sensors have been used with different func-

tionality and communication interfaces.

3.4.1 Inertial measurement unit

The inertial measurement unit (IMU) consists of four sensors, an accelerometer, a

gyroscope, a magentometer and a barometric pressure sensor. The sensor breakout

board is shown in figure 3.8. Pin descriptions and connections to the Arduino Nano

board is listed in table 3.4.

Figure 3.8: Geeetech 10 DOF Inertial Measurement Unit

Table 3.4: Geeetech 10 DOF IMU pin description and connections

Signal IMU pin I/O Description Arduino Nano pin

VCC 1 P 5 V power supply 5V

GND 2 G Common ground GND

SCL 3 AIO Serial clock line A4

SDA 4 AIO Serial data line A5

A gyroscope measures angular velocity. InvenSense ITG3205, mounted the IMU, is a

triple-axis gyroscope with three 16-bit ADCs to digitize the outputs [14]. The sensor is

36

accessible through I2C. Gyroscope measurements can be used to determine and/or

maintain orientation of the sensor.

An accelerometer measures the acceleration with respect to gravity. The accelerom-

eter on the IMU is the ADXL34 developed by Analog Devices which is a triple-axis

accelerometer with 13-bit resolution measurements up to ± 16g [15]. It is accessible

through SPI or I2C. Accelerometer measurements can be used to determine the po-

sition from a fixed point and/or the orientation of the sensor. The accelerometer is

used in the prototype to determine if a prospective patient is in vertical or horizontal

position. If the sensor is placed on the chest, vertical implies that the patient is sitting

or standing up while horizontal implies that the patient is lying down.

A magnetometer measures the magnitude and/or direction of the magnetic field sur-

rounding the sensor. The Honeywell HMC5883L on the sensor breakout is a triple-

axis magnetometer capable of measuring both direction and magnitude of the sur-

rounding magnetic field. It includes features such as ADC, offset cancellation and

amplification [16]. The heading accuracy is between 1◦ to 2◦. The sensor is accessible

through I2C. The sensor measurements can be used to determine the orientation of

the sensor.

A barometric pressure sensor detects the atmospheric pressure. Bosch’s BMP085 in-

cluded on the sensor breakout measures the pressure in the range 300 - 1100 hPa with

an accuracy of up to 0.03 hPa / 0.25m [17]. The sensor is accessible through I2C. At-

mospheric pressure can be used to estimate the altitude of the sensor.

3.4.2 Single lead heart rate monitor

Sparkfun AD8232 sensor breakout, shown in figure 3.9, is a single lead heart rate mon-

itor used to measure electric activity of the heart. Analog Devices AD8232 IC is a sig-

nal condition block for biological measurement applications. It includes features as

adjustable lowpass filter, adjustable highpass filter and DC blocking capabilities. It

is designed to extract, amplify and filter biopotential signals contaminated by noise

[18]. The sensor breakout breaks out nine connections from the AD8232 IC. Five of

these connections are used and listed in table 3.5. The output from the sensor is an

analog voltage which has to be digitized by an ADC on the MCU. The board has a

3.5mm jack connection which can be used to connect electrodes.

37

Figure 3.9: AD8232 sensor breakout

Table 3.5: Sparkfun AD8232 description and connection of used pins

Signal AD8232 pin I/O Description Arduino Nano pin

GND 1 G Common ground GND

3.3V 2 P 3.3 V power supply 3V3

OUTPUT 3 AO Output signal A0

LO- 4 DO Negative leads-off detection D6

LO+ 5 DO Positive leads-off detection D7

3.4.3 Temperature

DS18B20, shown in figure 3.10, is a digital thermometer which provides 9-bit to 12-

bit temperatures in Celsius. It includes an alarm feature with upper and lower trigger

points. It measures temperatures from -55◦C to 125◦C with an accuracy of 0.5◦C in the

interval -10◦C to 85◦C [19]. The communication interface is a unique one-wire bus

which allows multiple DS18B20 sensor to operate on the same bus by utilizing 64-bit

addresses. Pin description and connections to the Arduino Nano board is listed in

table 3.6.

38

Figure 3.10: DS18B20 sensor

Table 3.6: DS18B20 pin description and connections

Signal DS18B20 pin I/O Description Arduino Nano pin

GND 1 G Common ground GND

VCC 2 P 5 V power supply 5 V

DQ 3 DIO Serial data line D5

3.4.4 Temperature and humidity

DHT11 is a digital temperature and humidity sensor, shown in figure 3.11 . It is able

to measure temperature from 0◦C to 50◦C with 2◦C accuracy and humidity from 20%

to 80% with 5% accuracy [20]. The resolution of both measurements is 16-bit. The

communication interface is a unique one-wire bus. Pin description and connections

to the Arduino Nano board is listed in table 3.7.

39

Figure 3.11: DHT11 sensor

Table 3.7: DHT11 pin description and connections

Signal DHT11 pin I/O Description Arduino Nano pin

VDD 1 P 3.3 V - 5 V power supply 5V

GND 2 G Common ground GND

DATA 3 DIO Serial data line D5

3.4.5 Ultrasonic sensor

HY-SRF05, shown in figure 3.12, is an ultrasonic sensor which is capable of detecting

objects by emitting a sound burst of 40kHz and receiving the reflected echo signal

[21]. By measuring the duration between the trigger and echo signal, the distance

to the object can be calculated. Three HY-SRF05 ultrasonic sensors is soldered to a

PCB to measure distances to objects located in front, to the right and to the left of the

PCB. Pin description and connections to the Arduino Nano board is listed in table

3.8.

40

Figure 3.12: HY-SRF05 sensor

Table 3.8: HY-SRF05 description and connection of used pins

Signal HY-SRF05 pin I/O Description Arduino Nano pin

VCC 1 P 5 V power supply 5V

TRIG 2 DI Trigger D3, D5, D7

ECHO 3 DO Echo D4, D6, D8

GND 4 G Common ground GND

41

4. Software implementationThis section describes the implementation of the software. The process from sen-

sor nodes reading sensor data to the smartphone displaying the sensor data is de-

scribed.

4.1 Integrated development environment

The integrated development environment (IDE) used during this thesis is Eclipse [22].

Eclipse is a free open-source software used in computer programming. Eclipse has a

plug-in system which lets the user customize the environment and install plug-ins to

support programming languages such as C, C++, JavaScript and others. The software

has been written in C++ and plug-ins including the Arduino toolchain and AVRDUDE

have been used.

4.2 Overview of node operation

The nodes on the network operate differently depending on if it is a sensor node or a

sink.

The sink is responsible for collecting sensor data and further sending the data to the

smartphone. To this end, the sink starts a network, operating as the PAN coordinator,

and maintains the network through service primitives provided by the protocol stack.

A flow chart of how the sink node operates is shown in figure 4.1.

During initialize, the sink initializes the DWM1000 communication module, the hard-

ware timer and resets the PAN information base (PIB) attributes in the protocol stack

to default values. A PAN is then started with RF parameters according to the de-

fault values in the PHY PIB. The sink is now required to manage the PAN by con-

stantly listening on the working channel. Two types of frames are processed after

reception, MAC command frames and data frames. MAC command frames include

association requests, data requests and beacon requests. The sink responds to the

MAC commands appropriately and returns to receive on the working channel. If data

is received, the data is sent to the smartphone, described in more detail in section

4.5.

The sensor nodes are responsible for reading and transmitting sensor data, which

42

Initialize

Start PAN

Manage PAN

Command receivedData received

RespondData presentation

Figure 4.1: Flow chart of sink node operation

Initialize

Channel scan

Associate to PAN

Sensor

Transmit dataRelay data

Figure 4.2: Flow chart of sensor node operation

43

may include relaying sensor data from other nodes. A flow chart of sensor node op-

eration is shown in figure 4.2.

The sensor node initializes the DWM1000 communication module, the connected

sensor, the hardware timer and resets the protocol stack through service primitives.

The sensor node then attempts to discover and associate to a network, described in

section 4.4.1. Once a sensor node is associated to a network, data from the sensor

is collected as described in section 4.3 and transmitted as described in section 4.4.2.

Sensor nodes which act as routers is capable of relaying data between reading and

transmission of sensor data.

4.3 Reading sensor data

The MCU on each sensor node initializes and communicates with the connected sen-

sor through the appropriate communication interface. Software libraries to manage

initialization, sensor control and communication exists for the ADXL345 accelerom-

eter on the IMU [23], the DS18B20 temperature sensor [24] and the DHT11 temper-

ature and humidity sensor [25]. The analog output from the single lead heart rate

monitor is sampled by the ADC peripheral on the MCU by using predefined Arduino

functions [26]. The Arduino functions include one function to measure the length of

a pulse on a digital pin, enabling the MCU to calculate the distance from the duration

of the pulse on the echo pin from the HY-SRF05 ultrasonic sensor.

Temperature and humidity change slowly in time and the sink does not require mul-

tiple data packets containing the same information. The MCU on these sensor nodes

periodically poll the sensor for new measurements and decide if the physical param-

eters have changed since the last sensor measurement. The MCU on the ultrasonic

sensor node initiates new distance measurements periodically and transmits the data

regardless of previous measurements. The accelerometer on the IMU sensor kit is

polled for measurements periodically. The decision between horizontal or vertical

position is made depending on which axis the gravitation affects.

An ECG requires a continuous data flow and the analog output from the AD8232 sen-

sor breakout is sampled immediately when the transmission of the previous mea-

surements is successful.

44

4.4 Transmission of sensor data

Before the sensor nodes can transmit sensor data towards the sink, they must be as-

sociated to the PAN started by the sink.

4.4.1 Network discovery and association

Discovering and associating to a PAN is provided by service primitives in the protocol

stack. Sensor nodes expect to associate to an existing PAN already operating in the

area and perform a channel scan to find such PANs. The channel scan, if any coordi-

nator is in radio range, will result in the necessary information needed to associate to

any found PAN. If a PAN which allows association is found, the sensor node attempts

to associate to the PAN through the coordinator which responded during the chan-

nel scan. Once a sensor node is associated, it needs to know which node requires the

sensor data and the address of that node. Sensor nodes with time-critical data do

not need any other information to successfully provide the sink with the sensor data.

These sensor nodes operate in a star topology with the sink since they do not have

time to participate in peer-to-peer communication, e.g. ranging exchanges or relay-

ing data, between transmission of sensor data to the sink. Sensor nodes with non

time-critical data polls the sink for the neighbor look-up table upon association. The

neighbor look-up table contains information about associated nodes: the address,

the range to the node and the node’s range to the sink, and if the node has its receiver

enabled during idle periods. Nodes with the receiver enabled during idle periods are

obligated to relay data upon reception of any data frame and respond to ranging re-

quests. Nodes with the intention of utilizing multi-hop routing protocol is required

to initiate ranging exchanges with all nodes in the look-up table with the receiver en-

abled during idle periods. After the ranging exchanges, the routing protocol in the

network layer calculates the next destination towards the sink in accordance with the

forward within r protocol described in section 2.3.

A message chart between a sensor node and a sink while discovering a PAN and as-

sociating to the PAN is shown in figure 4.3 which illustrates the layer interactions and

data direction of the primitives.

45

Figure 4.3: Discover and join network message chart between a sensor nodes layer en-

tities and a sinks layer entities

4.4.2 Communication on the network

After association, sensor nodes are free to communicate on the network. Once the

sensor node has data for the sink, it is passed to the network layer through a ser-

vice primitive. A message chart between a sensor node and a sink is shown in figure

4.4.

Figure 4.4: Message chart between a sensor nodes layer entities transmitting data and

a sink layer entities receiving data

A data request at the network layer requires the destination address, the network ser-

vice data unit (NSDU), if it is an acknowledged transmission and if routers should to

be used. The network layer requests the MAC layer to transmit the supplied NSDU

46

to the destination address with the acknowledgement request flag set appropriately.

If routing should be used, the network layer is responsible for providing the next hop

destination to the MAC layer as calculated by the routing protocol. The MAC layer

constructs the corresponding MHR and MAC service data unit (MSDU) with frame

control and addresses set as requested. The CSMA/CA channel access mechanism,

including CCA, is used to assess if the channel is idle or busy by requesting the PHY

layer to enable the receiver and hunting for preambles. If the channel is idle, the

transceiver is transitioned into transmit mode, the MHR and the MSDU is written

to the DW1000 IC transmit data buffer register and the DW1000 IC is commanded

to start transmitting the data in the buffer. The DW1000 IC automatically generates

the MFR, including the CRC, and transmits the MFR after the MSDU. The SHR and

PHR is automatically generated by the hardware without commands from the soft-

ware.

Upon successful reception of a frame, the DW1000 IC parses the MHR and only presents

frames which are of interest to the higher layers. The frame filter decision is made

according to the IEEE 802.15.4-2011 communication standard, presented in section

2.6.5.1. The CRC included in the MFR is automatically verified by the DW1000 IC.

After parsing the MHR and verifying the CRC, the DW1000 IC automatically transi-

tion the transceiver into transmit mode and transmits an acknowledgement frame

according to the IEEE 802.15.4-2011 communication standard if the acknowledge-

ment request flag in the frame control is set. The frame is then presented to the MAC

layer by a hardware interrupt. The frame is passed to the higher layers through the in-

dication primitive, eventually presented to the application layer which decides what

actions needs to be taken.

Routers on the network which receives a data frame repeats the process described

above and discards the data after successful transmission. Other frames, such as

MAC commands, are transmitted and received in the same manner but by other ser-

vice primitives. The software library [27] has been used to read and write registers on

the DW1000 IC. During the thesis, the library has been extended with functionality

needed for the prototype.

4.5 Sensor data collection and presentation

Once the data has reached the sink, which is the destination, the MCU uses built in Ar-

duino functions [26] to print a string on the serial port which the smartphone is con-

nected to. The Android application parses the string and presents the measurement

in a graph or communication log depending on the identifier in the string. Strings

47

which start with a ’D’ is displayed in a graph and strings which start with a ’M’ is dis-

played in the communication log. ’|’ is used to notice the application that it is the

end of the string. The Android application is developed in another thesis and will

not be presented more in detail in this thesis, details on the application can be found

in [28]. The first octet of each MSDU identifies which type of sensor data the MSDU

contains, enabling the sink determine if the data should be presented in a graph or

the communication log.

4.6 Evaluation

The evaluation of the prototype was performed in a generally more challenging envi-

ronment for wireless communication, a long corridor inside a building. Parameters

related to transmission, reception and ranging accuracy were recorded at different

distances while varying PSR, PRF, data rate, length of the preamble sequence, pream-

ble code, center frequency and bandwidth. The transmitter and receiver were in line-

of-sight during the evaluation.

Interchannel communication was evaluated by placing a transmitter next to a re-

ceiver while operating on overlapping channels and recording any received frames.

The ability to operate independently by using different preamble codes on the same

channel was evaluated in the same manner.

MAC protocols were evaluated by implementing additional functionality in the MAC

layer which recorded the number of transmission attempts, CCA failures and lost

packets. During the test, the number and types of sensor nodes active on the net-

work varied.

48

5. Results and discussionThis section presents the performance of the implemented prototype and the results

from the evaluation along with a discussion of the results.

5.1 Prototype

A prototype of a UWB-based WSN has been developed. As shown in figure 5.1, it con-

sists of five sensor nodes, one sink node and one Huawei Honor 5X smartphone. The

sensor nodes measure physical quantities related to medical monitoring, ECG, room

temperature and humidity, acceleration and distance to nearby objects in front of, to

the right and to the left of a prospective patient. The sensor node which measures

acceleration is capable of determining if the patient is in horizontal or vertical po-

sition. Sensor data is successfully obtained by the MCU on each sensor node and

transmitted by the DWM1000 UWB communication module to the sink or towards

the sink using routers. The sink can successfully manage the network by responding

to MAC commands, receive sensor data and send the data to the Huawei Honor 5X

smartphone which displays the sensor measurements in an Android application. The

sensor data is shown in the communication log, shown in figure 5.2a, or in a graph,

shown in figure 5.2b. ECG measurements are displayed in a graph while the tem-

perature, humidity, body position and distance measurements are displayed in the

communication log. The Android application is not developed with this particular

application in mind. A graphical user interface allowing the user to see the ECG and

other measurements in the same view instead of switching between the communi-

cation log and the graph menu is preferred.

The implemented protocol stack supports both star and peer-to-peer topology and

has multi-hop capabilities. The implemented MAC primitives and MAC PIB attributes

supports a nonbeacon-enabled network operating closely to what is described in the

IEEE 802.15.4-2011 communication standard.

The DSTWR method provides the routing protocol with estimates of the distance be-

tween the nodes on the network. The routing protocol calculates the next hop to-

wards the sink based on the distance estimates, presenting multiple paths from sen-

sor nodes to the sink and extending the coverage area of the network.

Since the network is nonbeacon-enabled, the sink must have its receiver constantly

enabled and be ready to handle any received frames. The sensor nodes are pending

49

Figure 5.1: The prototype consisting of (i) ECG sensor node, (ii) sink, (iii) Huawei Honor

5X smartphone, (iv) ultrasonic sensor node, (v) IMU sensor node, (vi) temperature sen-

sor node and (vii) humidity and temperature sensor node

(a) The communication menu (b) The graph menu

Figure 5.2: Android application menus to view sensor measurements

50

between the transmit and receiver state. Since all sensor nodes, except the ECG sen-

sor node, also act as routers, they are not allowed to enter any sleep state but must

instead enable the receiver during idle periods. A typical receiving power profile re-

quires 113 mA current during the preamble hunt, 125 mA current during reception

of the SHR, 118 mA current during reception of the PHR and PSDU [12]. This can

be compared to the sleep state which requires 50 µA, the deepsleep state which re-

quires 50 nA and the idle state which requires 18 mA [12]. The ATmega328 micro-

controller can enter different sleep modes which minimizes power consumption by

disabling unused features. Thus, letting the transceiver and/or microcontroller enter

sleep states will have a significant impact on power consumption.

5.2 Evaluation

This section presents the results of the evaluation described in section 4.6 and a dis-

cussion of the results.

5.2.1 Communication

The best recorded performance metrics are listed in table 5.1.

Table 5.1: Performance metrics between two nodes in line-of-sight at different distances

operating at 1331.2 MHz bandwidth with center frequency 3993.6 GHz, 1024 preamble

length, 0.11 Mbps data rate and 16 MHz PRF

Distance [m] Receive

power [dBm]

First path

power [dBm]

Receive

quality

Packet loss

5 -74.1 -79.1 444 0.6%

10 -87.8 -93.0 244 1.2%

15 -83.5 -87.9 340 0.6%

20 -88.5 -90.3 290 4.6%

25 -93.1 -95.8 165 14%

30 -95.0 -105 64.4 30%

The best performance was recorded at a channel with center frequency 3993.6 GHz

and 1331.2 MHz bandwidth. Channels with higher center frequency and lower band-

width have reduced maximum range and worse performance over all distances. A

lower center frequency has better penetrating abilities due to increased wavelength

of the signal and a wider bandwidth allows more power to be sent at a given frequency

51

while still transmitting below the regulatory limit. This implies that the power con-

sumption of the transceiver is increased as well.

Increasing the data rate decreases the maximum range but other performance met-

rics were close to the best recorded. The air time is largely dependent on the data

rate and for frames of equal length, lower data rate increases the time the channel

is occupied. The length of the preamble sequence has a significant impact on both

radio range and the first path power. Decreasing the preamble sequence from 1024

to 64, the radio range decreased to approximately 15 m with packet loss around 60%

and decreased first path power. A longer preamble sequence allows the receiver to

synchronize and detect the first path of arrival but increases air time and power since

more symbols have to be transmitted.

No differences between 16 MHz and 64 MHz PRF could be observed. According to

DecaWave, a higher PRF increase the ranging accuracy and slightly increase the range

at the cost of marginally increased power consumption [12].

Operating independently, as if on different channels, by using different preamble

codes is possible. A receiver operating the same channel as the transmitter with a dif-

ferent preamble code did not receive any transmissions of a total 1000 transmissions.

Interchannel communication is possible as stated in the IEEE 802.15.4-2011 com-

munication standard. A receiver at channel 2 with center frequency 3993.6 MHz and

bandwidth 499.2 MHz and a transmitter at channel 3 with center frequency 4492.8

MHz and banwidth 499.2 MHz could establish reliable communications. The packet

loss at a distance of approximately 10 cm in line-of-sight was 11% over 1000 trans-

missions.

The CSMA/CA channel access mechanism introduces latency from request to trans-

mit data until the first symbols is transmitted. Latency depending on channel access

failures is listed in table 5.2.

Table 5.2: Latency due to the CSMA/CA channel access mechanism from requesting to

transmit before the first symbol is transmitted

Channel access failuresLatency [ms]

Best case Average Worst case

0 8 15 22

1 16 38 60

2 24 77 130

3 32 148 264

The minimum latency is 8 ms which is the duration of the CCA. In a sparse network

52

the channel is often idle and no additional latency occurs. In dense networks, the

channel is occupied more often and a total delay, between requesting to transmit and

the first symbol being transmitted, of 264 ms after the fourth channel access attempt

is possible. The latency is dependent on PHY parameters such as data rate, PRF and

preamble length. In acknowledged transmissions the transmitting node is required to

wait for the recipients acknowledgement frame. In poor channel conditions when the

recipient does not receive the frame, the transmitting node waits 100 ms before con-

cluding that the transmission attempt has failed. If the transmitted frame is a MAC

command expecting a response, the transmitting node is required to wait approx-

imately 300 ms after receiving the acknowledgement frame before concluding that

the transmit attempt of the response has failed. To establish reliable communication

with the used hardware, MAC PIB attributes related to latency have been altered from

what is defined in the standard. These delays have been set to make sure that the MAC

layer has enough time to process the received frame and make a decision on how to

respond. If microcontrollers with higher clock frequency is used, the delays can likely

be reduced.

In a lightly loaded network, with periodic sensor measurements, a sensor node ca-

pable of acting as a router in the middle of the sensor field in line-of-sight condi-

tions, failed to access the channel approximately 14% of the attempts. The sensor

node failed to receive acknowledgement frames approximately 3% of the transmis-

sions. 44% of the transmission attempts occurred due to its own sensor measure-

ments and the rest were measurements from other sensor nodes using this node as a

router.

Changing the environment conditions, making the sensor measurements change more

often, results in a higher load on the network. In a similar setting, the sensor node

failed to access the channel approximately 27% of the attempts and failed to receive

acknowledgment frames approximately 4% of the transmissions. During this test,

58% of the transmission attempts occurred due to its own sensor measurements.

Including the ECG sensor node, which attempts to transmit new ECG measurements

immediately after receiving an acknowledgement from the previous sent measure-

ments, the same test showed that the sensor node failed to access the channel ap-

proximately 83% of the attempts, failed to receive acknowledgement frames 5% of

the transmissions. 70% of the transmission attempts occurred due to its own sensor

measurements.

Failure to receive acknowledgement frames may be caused by collisions from the hid-

den terminal problem described in section 2.6.3.1. The ECG sensor node has strict

latency and throughput requirements since the sink needs a continuous data flow

53

to provide a real-time ECG. The latency may be unacceptable for such an applica-

tion. A multiple access scheme instead of random access could be employed to deal

with such issues. It is possible to use the ALOHA channel access mechanism, which

does not introduce latency, instead of CSMA/CA. However, instead of failing to access

the channel, the transmission will cause a collision and further reduce the through-

put.

The Android application can only deal with one new value for each graph and com-

municates slowly with the MCU. For this reason, the payload of the data frame is not

filled with ECG sensor measurements before transmission. Utilizing the payload to

a maximum, the number of transmissions decrease which decreases channel occu-

pation time by the ECG sensor node. Thus, improved network performance metrics

could be achieved if the Android application is able to receive a buffer of data.

5.2.2 Routing protocol

The routing protocol performance is dependent on the calculated ranges between

the nodes. Inaccurate timestamps can cause the routers to relay data away from the

the sink instead of towards it.

Table 5.3: Accuracy of the ranging protocol between two nodes in line-of-sight at differ-

ent distances operating at 1331.2 MHz bandwidth with center frequency 3993.6 GHz,

1024 preamble length, 0.11 Mbps data rate and 64 MHz PRF

Distance [m] Average range [m] Standard deviation [m]

5 5.00 0.0397

10 9.98 0.0398

15 15.1 0.0831

20 20.1 0.0360

25 24.9 0.0540

30 30.0 0.1055

Table 5.3 shows the average calculated range between two nodes. According to the

DW1000 user manual [9], the DW1000 has a ±10 cm ranging accuracy which is veri-

fied. No differences on ranging accuracy could be noticed by varying the PRF or cen-

ter frequency. The preamble length and bandwidth of the channel showed small dif-

ferences, lower preamble length and lower bandwidth showed slightly increased error

in the distance estimates.

The routing protocol does not introduce any limitations on number of hops. Each

node in the network only considers the next destination in the multi-hop chain. There-

54

fore, the maximum number of hops is limited by the number of available routers in

the network. In case of mobile sensor nodes, the ranging exchange will have to be

performed periodically at a high rate, occupying the channel and decreasing through-

put.

Since all deployed sensor nodes main responsibility is to transmit its own sensor mea-

surements to the sink, the sensor nodes configured to relay data only do so during idle

periods. If a sensor node is not in its idle period, ready to relay data, when another

sensor nodes transmits data addressed to the router, the sensor node will not receive

an acknowledgement frame and thus go through the process of retransmission which

decreases the throughput.

In case of mobile nodes, the neighbor look-up table should be updated often. The

ranging exchange requires 0.5N (N −1) distance measurements, where N is the num-

ber of nodes. Each distance measurement is 4 messages. Thus, updating the neighbor

look-up table requires 40 messages. Even in a sparse network, performing ranging ex-

changes often might lead to as low throughput as a very dense network. The dynamic

preamble select feature of the IEEE 802.15.4-2011 communication standard can re-

duce the channel time occupied by ranging exchanges. Predetermined ranging with

synchronized clocks may utilize a different preamble code for all 40 messages, thus

not occupying the working channel at all. Without synchronized clocks, the number

of messages can reduced to half by using dynamic preamble select.

Since the data path is only dependent on the distance between nodes, specific routers

can become bottlenecks of the network depending on the placement of sensor nodes

and routers. Extending the routing protocol by additional parameters such as link

quality, latency and hopcount would improve the routing protocol and make it more

robust.

5.3 Sensor measurements

The AD8232 sensor breakout provides measurements of a prospective patients heart

activity. Figure 5.3a shows the analog output from the AD8232 IC. The signal is con-

taminated by high-frequency noise and details of the heart activity cannot be seen.

The signal filtered with a 10th order lowpass finite impulse response filter with cutoff

frequency equal to 35 Hz is shown in figure 5.3b. After the signal is passed through

the filter, details resembling the PR and QT interval can be seen in the ECG. If the

measurements are intended to treat or diagnose conditions, although neither the

sensor breakout nor the electrodes are licensed medical devices, signal processing

55

0 50 100 150 200 250 300 350 400

Sample

100

200

300

400

500

600

700V

olta

ge

[m

V]

(a) Unfiltered measurements

0 50 100 150 200 250 300 350 400

Sample

200

250

300

350

400

450

500

550

600

Vo

lta

ge

[m

V]

(b) 35 Hz lowpass filtered measurements

Figure 5.3: Electrocardiogram

is needed.

Measurements from the ADXL345 accelerometer is shown in figure 5.4. The sensor

node is placed on a prospective patient’s chest and shows a transition from the sen-

sor node being in vertical position to horizontal position. The signals are accurate

enough to reliably provide information on the patient’s position, e.g. sitting, standing

up or lying down. The accelerometer measurements are contaminated with noise, es-

pecially during movement. For other applications, signal processing is likely required

to provide reliable measurements.

The DHT11 sensor measurements is shown in figure 5.5. The sensor provides reliable

measurements in a typical indoor environment. The DS18B20 temperature sensor

has a higher resolution than the DHT11 temperature sensor. Temperature measure-

ments provided by the DS18B20 sensor is shown in figure 5.6. Ultrasonic distance

measurements is shown in figure 5.2a.

56

0 200 400 600 800 1000 1200 1400 1600 1800 2000

Sample

-2

0

2

4

6

8

10

12

Accele

ration [m

/s2]

x-axis

y-axis

z-axis

Figure 5.4: Accelerometer measurements during a transition between vertical and hor-

izontal position

0 100 200 300 400 500 600 700 800 900 1000

Sample

25

25.5

26

26.5

27

27.5

28

28.5

29

29.5

30

Tem

pera

ture

[°C

]

(a) Temperature measurements

0 100 200 300 400 500 600 700 800 900 1000

Sample

25

30

35

40

45

50

55

60

65

Hum

idity [%

]

(b) Humidity measurements

Figure 5.5: DHT11 sensor measurements

57

0 100 200 300 400 500 600 700 800 900 1000

Sample

23

24

25

26

27

28

29

30

31

Tem

pera

ture

[°C

]

Figure 5.6: DS18B20 temperature measurements

58

6. Conclusions and future workThis section presents conclusions drawn from the presented results and suggestions

for further work.

A prototype of a wireless sensor network with ultra wideband radio and communi-

cations has been developed. It consists of five sensor nodes, equipped with one Ar-

duino Nano board, one DWM1000 UWB transceiver and one sensor, and one sink

node, equipped with one Arduino Nano board and one DWM1000 UWB transceiver,

connected to a Huawei Honor 5X smartphone. The sensors used are one accelerom-

eter ADXL345 which is a part of an IMU, one single lead heart rate monitor based

on the AD8232 IC, three HY-SRF05 ultra-sonic sonars, one DHT11 temperature and

humidity sensor and one DS18B20 temperature sensor. The Arduino Nano board is

equipped with a microcontroller, ATmega328, which is the core of the nodes, respon-

sible for controlling the DWM1000 communication module by acting as master of the

SPI bus and controlling the sensors through the corresponding communication in-

terface or the ADC peripheral. A protocol stack consisting of four layers, PHY, MAC,

network and application layer, enables communication on the network. The PHY

layer, strictly implemented in hardware and provided by the DWM1000 module, and

large parts of the MAC layer is compliant with the IEEE 802.15.4-2011 communica-

tion standard. The routing protocol is location-based and estimates distances be-

tween nodes on the network through double-sided two-way ranging. The network

operates in star or peer-to-peer topology where the last mentioned topology allows

multi-hop communication. Sensor measurements can be successfully obtained and

transmitted using wireless UWB communication from sensor nodes to the sink. The

sink sends the received measurements to the smartphone which displays the sensor

measurements in an Android application.

UWB communication is suitable for WSNs where distances between neighbor sensor

nodes are short. In an indoor environment, reasonable communication has been

verified up to a distance of 30 m between transmitter and receiver. Reliable range

estimates have been measured and DecaWaves claim that the DW1000 IC provides

accurate timestamps to allow for 10 cm error has been verified. UWB RF settings such

as data rate, PRF and preamble code length have been investigated. Different settings

have impact on radio range, first path timestamp accuracy and power consumption.

These settings have to be decided based on the WSN application.

The IEEE 802.15.4-2011 communication standard employs different mechanisms which

provide reliable communication through low probability of packet collisions and er-

59

ror detection. High throughput requirements are not suitable for PANs compliant

with the IEEE 802.15.4-2011 communication standard.

The developed prototype can further be improved. Improvements should be made

with a specific application in mind. Towards this end, a more extensive evaluation

of the protocols is needed to find possible disadvantages and improvements with re-

spect to the intended application. The performance of UWB communications can be

investigated further in different environments and in non-line-of-sight propagation.

A list with suggestions for further work follows:

• Select a more suitable microcontroller in terms of power consumption, com-

putational capabilities and memory, whichever is needed for the intended ap-

plication

• Design a PCB including the microcontroller, communication module and the

sensors to increase robustness and reduce node size

• Use the magnetometer, barometric pressure sensor and the gyroscope available

on the IMU to track an object

• Implement support for a beacon-enabled network as specified by the IEEE 802.15.4-

2011 communication standard

• Implement the security features defined in the IEEE 802.15.4-2011 communi-

cation standard for applications with security demands

• Extend the routing protocol with additional parameters to make it more robust

• Implement storage of data and signal processing, if needed for the intended

application

• Develop an Android application which is more suitable for the intended appli-

cation

• Investigate the need for a transport layer in the protocol stack

• Investigate the benefits of a cross-layer protocol stack

• Power the nodes by batteries and evaluate energy efficiency

• Compare UWB and narrowband communication with respect to important as-

pects of a WSN

60

References[1] S. Yang, Wireless sensor networks: Principles, Design and Applications, Springer,

London, 2014.

[2] A. Goldsmith, Wireless communications, Cambridge University Press, New York,

2005.

[3] J. Zheng, A. Jamalipour, Wireless sensor networks: A networking perspective, John

Wiley & Sons Ltd, New Jersey, 2009.

[4] M. Ghavami, Ultra wideband signals and systems in communication engineering,

John Wiley & Sons Ltd, England, 2nd edition, 2007.

[5] IEEE Computer Society, IEEE Standard for Local and metropolitan area networks

- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs), Sponsored by

the LAN/MAN Standards Committee, New York, 2011.

[6] E. Williams, Make: AVR programming, Maker Media, USA, 2014, 1st edition

[7] NXP Semiconductors, UM10204 I2C-bus specification and user manual. [Online].

Available: https://www.nxp.com/docs/en/user-guide/UM10204.pdf. [Ac-

cessed June 10, 2018].

[8] F. Nekoogar, Ultra-wideband Communications: Fundamentals and Applications,

Prentice Hall, 2005.

[9] Decawave Ltd., How to use, configure and program the DW1000 UWB transceiver,

DW1000 user manual version 2.13, 2017. [Online]. Available: https://www.decawave.com/sites/default/files/dw1000_user_manual_2.13.pdf.

[Accessed June 10, 2018].

[10] Arduino, Arduino Nano Documentation, 2018. [Online]. Available: https://store.arduino.cc/usa/arduino-nano. [Accessed June 10, 2018].

[11] Atmel, ATmega328/P datasheet complete, 2016

[12] Decawave Ltd., DW1000 datasheet version 2.09, 2015. [Online]. Availi-

able: https://www.decawave.com/sites/default/files/resources/dw1000-datasheet-v2.09.pdf. [Accessed June 10, 2018].

[13] Decawave Ltd., DWM1000 datasheet version 1.6, 2016. [Online].

Availiable: https://www.decawave.com/sites/default/files/dwm1000-datasheet-v1.6.pdf. [Accessed June 10, 2018].

61

[14] InvenSense, ITG3205 Product Specification, ITG3205 datasheet Rev. 1.0, 2010.

[15] Analog Devices, 3-Axis, ±2 g/±4 g/±8 g/±16 g Digital Accelerometer, ADXL345

datasheet Rev. E, 2015.

[16] Honeywell, Three-Axis Digital Compass IC HMC5883L, HMC5883L datasheet

Rev. C, 2012.

[17] Bosch, BMP085 Digital pressure sensor, BMP085 datasheet Rev. 1.2, 2009.

[18] Analog Devices, Single-lead, Heart Rate Monitor Front End, AD8232 datasheet

Rev. C, 2018.

[19] Maxim Integrated, DS18B20 Programmable Resolution 1-Wire Digital Ther-

mometer, DS18B20 datasheet Rev. 4, 2015.

[20] Adafruit, DHT11, DHT22 and AM2302 Sensors. [Online]. Available: https://cdn-learn.adafruit.com/downloads/pdf/dht.pdf. [Accessed June 10,

2018].

[21] Energia Zero, Arduino ultrasonic sensor (HY-SR04 or HY-SRF05). [Online].

Available: http://www.energiazero.org/arduino_sensori/Arduino%20ultrasonic%20sensor%20(HC-SR04%20or%20HY-SRF05).pdf. [Accessed

June 10, 2018].

[22] Eclipse Foundation, Eclipse Platform. [Online]. Available: https://www.eclipse.org/. [Accessed June 18, 2018].

[23] GitHub, Arduino Library for the ADXL345. [Online]. Availabile: https://github.com/sparkfun/SparkFun_ADXL345_Arduino_Library. [Ac-

cessed March 12, 2018].

[24] GitHub, Arduino plug and go library for the Maxim (previously Dallas) DS18B20

(and similar) temperature ICs. [Online]. Availabile: https://github.com/milesburton/Arduino-Temperature-Control-Library. [Accessed March

12, 2018].

[25] GitHub, Arduino library for DHT11DHT22, etc Temp & Humidity Sensors. [On-

line]. Availabile: https://github.com/adafruit/DHT-sensor-library.

[Accessed March 12, 2018].

[26] Arduino, Language reference. [Online]. Available: https://www.arduino.cc/reference/en/. [Accessed Feb. 12, 2018].

[27] GitHub, A library that offers functionality to use Decawave’s DW1000

62

chips/modules with Arduino. [Online]. Available: https://github.com/thotro/arduino-dw1000. [Accessed Feb. 12, 2018].

[28] O. Flink, Wireless electrocardiogram transmission based on ultra wideband radio,

Uppsala University, 2018.

63