UPTEC E 18 020

Examensarbete 30 hp
Juni 2018

UWB-based wireless sensor network

with medical application

Joakim Lindström
 Abstract
UWB-based wireless sensor network with medical
application
Joakim Lindström

Teknisk- naturvetenskaplig fakultet

UTH-enheten 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 five
Besöksadress: sensor nodes and one sink which is connected to an Android smartphone. The
Ångströmlaboratoriet
Lägerhyddsvägen 1 smartphone acts as a sensor data management unit and has the ability to display
Hus 4, Plan 0 sensor measurements. The sensor nodes include the sensors of an inertial
measurement unit, an electrocardiogram (ECG) electrode set, a temperature sensor,
Postadress: a humidity sensor, and three ultrasonic sensors, and they are responsible for making
Box 536
751 21 Uppsala measurements, sending the measurements to, and forwarding the measurements from
other sensor nodes to the destination. The sink node receives the measurements
Telefon: from the sensor nodes, and the measurements are displayed on the smartphone.
018 – 471 30 03

Telefax: The sensor nodes and the sink are equipped with DecaWave's DWM1000 UWB
018 – 471 30 00 transceiver which is compliant with the IEEE 802.15.4-2011 communication standard
and enables the UWB communications, and a microcontroller, ATmega328, that
Hemsida: handles sensor data reading and transmission. Due to UWB pulses having high time
http://www.teknat.uu.se/student
resolution, a location-based routing protocol based on time of flight distance
estimates 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 topology
with multi-hop capabilities. The results of the evaluation show that lower data rate,
lower center frequency and wider bandwidth increases radio range and a longer
preamble sequence increases ranging accuracy. This comes at the cost of increased
time of channel occupation and power consumption.
From this thesis project it is indicated that UWB radio is a good choice for
short-distance radio communication applications such as WSNs. The measurement
errors in range estimates can be within 10 cm in line-of-sight. Networks compliant
with the IEEE 802.15.4-2011 communication standard should have low throughput
requirements as channel access mechanisms and functions related to reliable data
transfers introduce latency.

Handledare: Håkan Sjörling

Ämnesgranskare: Ping Wu
Examinator: Tomas Nyberg
ISSN: 1654-7616, UPTEC E 18 020
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
Contents
1 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 Figures
1.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 Tables
2.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
Abbreviations
ACL 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

I2 C 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. Introduction
This 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 (I2 C), 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 networks
This 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
 Application layer

Presentation layer

Session layer
Transport layer

Network layer

MAC layer

Physical 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 (I2 C) 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. I2 C is a protocol widely used as interface
between a MCU and sensors. I2 C 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

I2 C 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 I2 C 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).

fh − fl
FB =2 (2.1)
fh + fl

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 S N 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 = B l o g 2 (1 + S N 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
 Gaussian pulse
1

0.5
Amplitude

-0.5

-1
0 5 10 15 20 25 30 35 40 45 50
Time (fs)
Frequency spectrum
0.3
Magnitude

0.2

0.1

0
0 200 400 600 800 1000 1200 1400 1600 1800
Frequency (THz)

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.

Tr o und 1 ∗ Tr o und 2 − Tr e p l y 1 ∗ Tr e p l y 2
Tp r o p = (2.3)
Tr o und 1 + Tr o und 2 + Tr e p l y 1 + Tr e p l y 2

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 implementation
This 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.

Arduino Nano UWB

Sensors with MCU transceiver
ATmega328 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 I2 C or a
sensor-specific one-wire bus.

29
 Arduino Nano UWB
Smartphone with MCU transceiver
ATmega328 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 (I2 C 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 5V
Clock frequency 16 MHz
ADC pins 8
Digital I/O pins 22
PCB size 18 x 45 mm
Weight 7g

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

Preamble codes
Channel Number
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 I2 C. 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 I2 C. 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 I2 C. 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 I2 C. 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 5V
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 implementation
This 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

Data received Command received

Data presentation Respond

Figure 4.1: Flow chart of sink node operation

Initialize

Channel scan

Associate to PAN

Sensor

Relay data Transmit 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 discussion
This 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 First path Receive Packet loss

power [dBm] power [dBm] quality
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

Latency [ms]
Channel access failures
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
 700 600

550
600

500

500
450
Voltage [mV]

Voltage [mV]
400 400

350
300

300

200
250

100 200
0 50 100 150 200 250 300 350 400 0 50 100 150 200 250 300 350 400
Sample Sample

(a) Unfiltered measurements (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
 12

10

8
Acceleration [m/s 2 ]

6 x-axis
y-axis
z-axis
4

-2
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Sample

Figure 5.4: Accelerometer measurements during a transition between vertical and hor-
izontal position

30 65

29.5
60
29
55
28.5
Temperature [°C]

50
Humidity [%]

28

27.5 45

27
40
26.5
35
26
30
25.5

25 25
0 100 200 300 400 500 600 700 800 900 1000 0 100 200 300 400 500 600 700 800 900 1000
Sample Sample

(a) Temperature measurements (b) Humidity measurements

Figure 5.5: DHT11 sensor measurements

57
 31

30

29
Temperature [°C]

28

27

26

25

24

23
0 100 200 300 400 500 600 700 800 900 1000
Sample

Figure 5.6: DS18B20 temperature measurements

58
6. Conclusions and future work
This 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 I2 C-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