Aircraft wireless sensors networks (WSN) testbed

Master thesis

Authored by: Xavier Perez´ Simo´ Enginyeria Electronica` UPC Supervisor: Jose Antonio Lazaro Villa TriaGnoSys GmbH supervisor: Eriza Fazli invisible text Contents

1 Introduction 1 1.1 Background and motivation...... 1 1.2 Objectives and scope...... 2 1.3 Outline of the thesis...... 3

2 System architecture5 2.1 Aircraft Architecture...... 5 2.2 Testbed Architecture...... 7

3 State of the art 8 3.1 WSN Testbed Platforms...... 8 3.1.1 Jennic...... 9 3.1.2 Radiocraft...... 9 3.1.3 Arduino...... 10 3.1.4 Zolerita...... 11 3.1.5 Libelium...... 12 3.1.6 Murata...... 13 3.1.7 VESNA...... 13 3.2 Operating Systems...... 16 3.2.1 FreeRTOS...... 16 3.2.2 Tiny OS...... 16 3.2.3 µC/OS II:...... 17 3.2.4 Contiki...... 17 3.2.5 RIOT...... 18 3.3 Medium Access Control (MAC) Protocols...... 19 3.3.1 Random Access...... 19 3.3.1.1 ALOHA...... 19 3.3.1.2 CSMA/CA and IEEE 802.15.4...... 19 3.3.2 Deterministic Access...... 21 3.3.2.1 FDMA...... 21

ii 3.3.2.2 CDMA...... 21 3.3.2.3 TDMA...... 21 3.4 Testbed Development...... 22 3.4.1 Selected the testbed options...... 22 3.4.2 Supporting VESNA in RIOT...... 23

4 Developing applications with RIOT-OS 24 4.1 Defining an Application...... 24 4.2 Multithreading Capability...... 25

5 RIOT-OS Latency Measurement 28 5.1 RIOT timer module...... 28 5.2 Latency Measurement...... 30 5.3 Measurement results and analyses...... 31

6 Wireless module development 36 6.1 Application using CC1101...... 36 6.2 Application using AT86RF231...... 37 6.2.1 Driver Initialization...... 37 6.2.1.1 Driver pin configuration...... 37 6.2.1.2 Debugging SPI...... 38 6.2.1.3 Radio transceiver modes...... 39 6.2.2 Pingpong Application...... 40

7 Conclusions and future work 42 7.1 Conclusions...... 42 7.2 Future Work...... 43

8 Appendix 44 8.1 Testbed Environment...... 44 8.2 Code Implementation...... 44 8.2.1 Supporting RIOT-OS in VESNA...... 44 8.2.2 Latency Measurements...... 45 8.2.3 Radio Application...... 45 8.3 Time Phases...... 47

9 References 49

10 Acronyms 52 List of Figures

2.1 Main network architecture of an aircraft...... 5 2.2 Wireless sensor node...... 7

3.1 JN5148 module from Jennic [42]...... 9 3.2 The radiocraft module [41]...... 10 3.3 The most common Arduino platform: Arduino Mega [39]...... 11 3.4 Z1 platform from Zolerita [40]...... 11 3.5 Waspmote platform from Libelium [19]...... 12 3.6 LPR2430 platform from Murata [38]...... 13 3.7 VESNA platform...... 14 3.8 radio transceiver CC1101...... 15 3.9 radio transceiver AT86RF231...... 15 3.10 Example of a superframe...... 20 3.11 MAC header...... 21 3.12 TDMA diagram...... 22

4.1 RIOT state machine...... 27

5.1 RIOT timing functions diagram...... 29 5.2 Cyclictest diagram...... 30 5.3 The histogram example which runs only one thread (time-slot controlling thread). 32 5.4 CDF...... 32 5.5 ”usleep” results with the same priority...... 33 5.6 ”Set msg” results with the same priority...... 33 5.7 ”usleep” results...... 33 5.8 ”Set msg” results...... 33 5.9 ”usleep” results with different priority form time-slot controlling thread...... 34 5.10 ”Set msg” results with different priority form time-slot controlling thread...... 34 5.11 ”usleep” results...... 34 5.12 ”Set msg” results...... 35

iv 5.13 VESNA histogram...... 35 5.14 RIOT histogram...... 35

6.1 Microcontroller to AT86RF231 interface [20]...... 38 6.2 Read acces by SPI in AT86RF231 [20]...... 39 6.3 Radio module state machine [20]...... 40 6.4 The application scheme...... 41 Chapter 1

Introduction

1.1 Background and motivation

Nowadays, aircraft contain a large number of sensors distributed throughout the plane and kilo- meters of cables are needed in order to establish a communication between all the sensors and the centralized data acquisition system.

A commercial aircraft has a total wire length of 470Km of cables which all of them weight 5700Kg. The harness fixation structure for holding all the cables puts an additional weight of about 30% [37]. The redundancy in wiring routes for improving the security needs amount of cables to sep- arated them the farthest possible way allowed by the aircraft geometry. That kind of installation represents an elevate cost and an inefficient maintenance for the company. About 30% of the electrical wires are potential candidates for a wireless substitute.

In order to improve that fact some aircraft manufacturers are interested in applying the wireless sensors so reducing the amount of cables and aircraft weight and optimizing the airline opera- tional cost and the environmental impact. Moreover, the wireless structures gain in reconfigura- bility through improving the installation flexibility and they also gain a reliable monitoring of the parameters belonging to moving or rotating parts, for instance the landing gear monitoring. All the applications above must deliver the safety status information in real-time and this involve the wireless communications must also be in real time.

April 13, 2015 Master thesis page 1/54 Authored by: Xavier Perez´ Simo´ One of the examples that aircraft manufactures are interested is the wireless supply unit (WSU) for passengers. This WSU for passenger involves: The release of oxygen masks, the trigger of oxygen flow, audio announcement and display providing safety information for the passenger. These need a flexible installation locations for allowing fast reconfiguration of seat layout.

Further advantage in using wireless structures is improving the reliability. The common failures can be mitigated by the wireless communications system using a different redundancy. The redundant wiring routes within the aircraft has a risk of single points of failure, caused by de- fectuous wiring such as loose contact or cut wires. The separated wired routes combined with the redundant radio links provides a different redundancy and a mitigation risk of single points of failure.

The motivations during this thesis are involves in creating a testbed for a WSN using different hardware and software components. The impulse for working in this environment is learning and getting experience in wireless sensors.

1.2 Objectives and scope

The work of this master thesis was focused on developing a wireless sensor network (WSN) testbed for an aircraft and the preliminary work for implementing a medium access control (MAC) protocol adapted in that WSN. The approach of this thesis is developing and testing the software components for implementing this custom made MAC protocol. The objectives to develop this challenge consist on:

• Embedded an operating system (OS) in real time in a specific platform. • Performed some response timing measurement with an OS in real time. • Chose the radio modules for the WSN and implement simple applications for checking the correct operation from the radio modules. • Develop a preliminary work for implementing a custom MAC protocol.

The scope of this final thesis focused on the creation of an aircraft WSN testbed. The main purposes of my thesis are: Creating a WSN testbed, chosen an OS and platform, make some demonstration applications using the radio transceivers and evaluate the real time requirements for this OS.

April 13, 2015 Master thesis page 2/54 Authored by: Xavier Perez´ Simo´ During the design process, the motivations involved in selecting the elements to develop this WSN which are: MAC communication protocol, platform testbed and an OS to embedded in the platform.

The main goal of this work was to provide a preliminary work in order to implement a custom MAC protocol using an OS in real time. This preliminary work involved defining the wireless nodes, the latency measurements and the radio module implementation. The focus of the performance analysis were on OS timing functions, radio modules features and the platform µC capabilities.

The thesis consists of planning a WSN for an aircraft with one wireless coordinator and several wireless nodes. An open-source real-time OS has been embedded in these wireless nodes. Additionally, I performed a set of measurements to determine the timing performance of the OS. The thesis was performed in the framework of TriaGnosSys internal research and development project.

1.3 Outline of the thesis

This master thesis has been developed in a period of six months and it is divided in different sections. At the beginning, the hardware platform is set up with the OS. The next stage consist in developing a radio application test in order to communicate the data test between the different sensor nodes. Finally, the last stage consists in performing latency measurements from the OS using an algorithm implemented in this thesis.

All the parts commented above are divided in this document into ten chapters, which are:

Chapter 1 gives a complete introduction for performing this master thesis. It is separated in background and motivation, the objectives and scope and lastly the outline.

Chapter 2 determines the features required for aircraft applications. The airlines are interested to perform a research in the WSNs specific for an aircraft.

Chapter 3 describes the state of the art which involved all possible platforms and OSs to define the testbed and the MAC protocols options for communicating the WSN. Finally, this chapter also contains the reasons to chosen the OS, the platform and the MAC protocol.

April 13, 2015 Master thesis page 3/54 Authored by: Xavier Perez´ Simo´ Chapter 4 explains how the users can develop applications using the OS called RIOT, take into account this OS is in real time and it has multithreading capability and its priorities. Finally, the chapter describes an important part from RIOT architecture which consists on the threads state machine.

Chapter 5 analyzes the latency from RIOT-OS. It is necessary to know how good are the timing functions from this OS in order to develop real time applications and implement custom commu- nication protocols. There are some statistical results and analyses from these measurements at the end of this chapter.

Chapter 6 investigates which are the best radio module to create a WSN. I developed a simple applications using each module in order to analyze which one is better.

Chapter 7 discusses the main conclusions of this master thesis by summarizing the work com- pleted and the future work for implementing a custom MAC protocol for the WSN.

Chapter 8, 9 and 10 contains additional information from this investigation such as references, acronyms and appendix respectively.

April 13, 2015 Master thesis page 4/54 Authored by: Xavier Perez´ Simo´ Chapter 2

System architecture

2.1 Aircraft Architecture

The main network architecture of an aircraft involves a client application, a human machine inter- face (HMI), a server, a wireless data concentrator (WDC) and lastly the wireless sensor network (WSN) which is the only wireless part. The WSN offers sensed data to one or more data col- lection elements in the same node which have a specific ID for the identification purposes. The Figure 2.1 illustrates the overall architecture of the network.

Figure 2.1: Main network architecture of an aircraft.

The connectivity from the sensors to rest of the network have been achieved by the wireless co- ordinator. This central node is a network gateway attached to the WDC via serial port.

April 13, 2015 Master thesis page 5/54 Authored by: Xavier Perez´ Simo´ WDC collects data from the sensors and connects the WSN to the wired network of the aircraft. The server, that is connected to the WDC, is controlling and managing all the components in the WSN. Software module of the server operates as the access port to the wired data network of the aircraft. The server also provides an interface to the client applications and the HMI. HMI enables the interaction between the staff in the aircraft to the rest of architecture. HMI is responsible of displaying and managing data in accessible and logical way. The client application can contribute in the network in different environments such as a WSU for the passengers.

The WSN topologies are: Tree, mesh and star which is used in the aircraft architecture described above.

The reasons why the WSN for an aircraft is a star topology are: It is easy to install, modify and the network density is low and security of the network can be implemented in the WDC. However, there are also some drawbacks in the star topology. For example, the whole network will be down if the coordinator node fails. Further drawback is developing the central node with different features as the others sensor nodes. This central node can not be constrained as the others because it controls the transmission from the rest of the nodes. The central node should have more processing power, more memory storage and more power supply.

The issue to use the other topologies (tree and mesh) is based on the difficulty to access directly to all the sensor nodes because they don’t have a central node which access immediately to the rest of the nodes.

In a tree topology, each node has a communications link with a parent node, which is the next hop in the path towards a special node called root. The root node does not have parents, however the nodes that have a certain parent are called the children of that parent. In a mesh topology, the nodes can be communicated by other nodes if a path exists. If a WDC needs to access directly to the all wireless sensors, it cannot access using a tree or a mesh topology.

April 13, 2015 Master thesis page 6/54 Authored by: Xavier Perez´ Simo´ 2.2 Testbed Architecture

The topology of the WSN in this aircraft architecture is a start topology which have one wireless coordinator and the rest of the nodes, but the challenge in this thesis is developing a testbed only with two wireless nodes. The components of these wireless nodes are small platforms which features are: Low-cost, autonomous sensing and low-power consumption devices.

A wireless node testbed is composed of a micro-controller (µC), several radio modules that act as a transceiver and different sensor models to capture data information. The hardware testbed also has additional peripherals such as a st-link debugger and it has several hardware limitations such as the microprocessor capacity. The block diagram from a wireless node testbed is in the Figure 2.2.

Figure 2.2: Wireless sensor node.

The software architecture is focused on chosing an operating system in real time, because all applications must deliver in real-time the safety status information. The communication between nodes will be achieved implementing a custom MAC protocol, but in this thesis only the prelimi- nary work to implement a custom MAC will be developed.

April 13, 2015 Master thesis page 7/54 Authored by: Xavier Perez´ Simo´ Chapter 3

State of the art

The state of the art has been examined in tree main parts that are operating systems (OS), platforms and radio communication protocols.

The hardware options in the market for developing a WSN are: Jennic, Radiocraft, Arduino, Zolerita, Libelium, Murata and VESNA.

The operating systems options for embedded platforms are: FreRTOS, Tiny OS, µC/OS II, Contiki and RIOT.

There are several options for implementing communication protocols in a WSN. They are in two main groups depend if the medium access control (MAC) is deterministic or random access.

3.1 WSN Testbed Platforms

There are several platforms in the market may be used to implement a WSN testbed. The require- ments from this platforms has a simple communications serial interface, low cost and low power consumption devices. In order to facilitate size and price reduction, wireless nodes include the minimum elements to capture and transmit data information, reducing the additional components needed. Many manufacturers in the market offer a fully operational wireless node including bat- teries, antenna and some sensor devices. Also this platforms has a set of connectors to facilitate the integration to a main PCB and requires no additional components to work.

April 13, 2015 Master thesis page 8/54 Authored by: Xavier Perez´ Simo´ 3.1.1 Jennic

Jennic produced a wireless microcontroller module, called JN5148 where is in the Figure 3.1. This modules incorporated a 32 bits RISC microntroller, 128kB of RAM and 128kB of ROM. The transceiver is working at 2.4GHz using the standard protocol IEEE 802.15.4.

Jenic provided different modules variants which are with an integrated antenna: JN5148-001-M00 and with an antenna connector are: JN5148-001-M03 and JN5148-001-M04 . All modules can run with networking stacks such as JenNet and ZigBee PRO as well as customer applications.

All that variants are required to connect a power supply and peripherals such as switches, actu- ators and sensors, considerably simplifying product development. The typical applications using this module are: Industrial systems, telemetry, remote control, home and commercial building automation and robust and secure low-power wireless applications.[8]

Figure 3.1: JN5148 module from Jennic [42].

3.1.2 Radiocraft

It has embedded wireless solutions with a family of miniature RF-modules. These modules are designed for operating under the European and US radio regulations for a license-free use. The network topologies that Radiocraft supports are: The point-to-point, the point-to-multipoint and the peer-to-peer.

Radiocrafts was the first in the market who embedded the wireless Meter-Bus (M-Bus) protocol. The M-Bus is an European standard for remote reading gas, water, heat-meters and heat cost allocators. Radiocraft wireless M-Bus technology has all the features needed to comply with these national standards, including the 128 bits advanced encryption standard (AES).

April 13, 2015 Master thesis page 9/54 Authored by: Xavier Perez´ Simo´ The modules have an UART interface for the serial communication to the sensors, the actuators and the central system who controls all the network. The network involves multi transceiver modules with an embedded protocol, but it needs external devices to control the signal responses from these transceivers.

The typical applications using these Radiocraft modules is for building control such as lighting, blinds and shutters, metering gas or water, fire or smoke detection, security systems and white goods [9].

Figure 3.2: The radiocraft module [41].

3.1.3 Arduino

Arduino is a family of electronic boards that are based on specific software programing easy to use with the Arduino development environment. The Arduino platforms are based with a family of microntrollers called ATmega from Atmel. These 8-bits microcontollers are low power with a reduced instruction set computing (RISC) architecture.

The most typical versions of Arduino in the market are the Arduino UNO and the Arduino Mega (See Figure 3.3), but the Arduino also involves another platforms which are called: Leonardo, Nano, Robot, Due, Pro and Mini among others. The main differences between them are: CPU speed range from 8MHz to 16MHz, the digital input/output number of pins from 4 pins in Ar- duino Robot to 54 pins in Arduino Mega and flash memory range from 32kB in the most Arduino platforms to 128kB in Arduino Mega.

Arduino’s applications are based in senses the atmosphere by receiving inputs from many sen- sors, and affects its environment by controlling lights, motors, and other actuators. [10]

April 13, 2015 Master thesis page 10/54 Authored by: Xavier Perez´ Simo´ Figure 3.3: The most common Arduino platform: Arduino Mega [39].

3.1.4 Zolerita

Zolerita has a special platform in the market for WSN called Z1 where is in the Figure 3.4. This module has been designed for researchers, developers, enthusiasts and hobbyists.

It is equipped with two on board digital sensors (accelerometer and temperature), but it is also supported with external sensor modules. The core architecture is based with a 16 bits microcon- troller MSP430 which is running at 16MHz. The radio transceiver is CC2420 which is running with the standard protocol IEEE 802.15.4 at 2,4GHz. Z1 has a maximum flexibility and an ex- pandability while improving the low power consumption with the most versatile and low power sensors and µC.

The Z1 platform applications are: Emergency detectors, safe and rescue devices, energy me- tering and agricultural monitoring. The applications can be connected directly to the Internet of Things (IoT) with a IPv6. Z1 is compatible in the most currently open source OS such as the TinyOS or the Conitiki. [11]

Figure 3.4: Z1 platform from Zolerita [40].

April 13, 2015 Master thesis page 11/54 Authored by: Xavier Perez´ Simo´ 3.1.5 Libelium

Libelium has developed a platform for the WSNs, called Waspmote where is in Figure 3.5. It has a specific open-source environment in its website to develop applications using a Waspmote.

It incorporated a microcontroller ATMEGA1281, which was running at 14 MHz. Waspmote had 8KB Of RAM and 128KB of flash memory. It had 8 digital input/ouput pins, but it only had 7 analogs inputs.

Waspmote hardware architecture has been specially designed to be extremely low consumption. Digital switches allow to turn on and off any of the sensor interfaces as well as the radio modules. The normal Waspmote consumption is 15mA, but two different sleep modes get Waspmote the low consumption until 22µA.

The build sensors on board are accelerometer and temperature, but Waspmote has available extended boards for multiple environments such as: Gases, smart waters, smart cities, smart parking, agriculture, video camera and radiation. Libelium has been developed until 70 sensors for implementing all extended sensor boards described above.

Waspmote can be communicated using 15 different technologies. Waspmote has available wire- less interfaces for long range (3G or GPRS), medium range (Zigbee, IEEE 802.15.4 or WiFi) and short range (Bluetooth). Waspmote radio modules can be used in combination of two radio transceivers by using the expansion radio board. [12]

Figure 3.5: Waspmote platform from Libelium [19].

April 13, 2015 Master thesis page 12/54 Authored by: Xavier Perez´ Simo´ 3.1.6 Murata

Murata makes a wireless transceivers for industrial applications, called LPR2430 where is in Figure 3.6. It is a robust module with low latency network operation.

The radio transceiver used in this platform is CC2430. It is based with the IEEE 802.15.4 standard protocol for 2.4GHz operation. It transmits up to 63mW of RF power.

The core architecture is composed with the microcontroller 8051 from Intel. It used two crystals which are provided from radio transceiver CC2430. One crystal is running at 32 MHz for normal operation and the another crystal is running at 32.768kHz for precision sleep mode operation.

In the consume part, it used low power with the sleep mode for long battery life operation. The LPR2430 got less than 3µA during the sleep mode.

The module includes three ADC inputs and two PWM outputs. Finally, this modules has a system to report automatically reports from sensors in response to set of programmable trigger condi- tions. [13][14]

Figure 3.6: LPR2430 platform from Murata [38].

3.1.7 VESNA

Versatile platform for sensor network applications (VESNA) is a modular architecture from Sen- sorLab which is an interdepartmental laboratory within the Jozef Stefan Institute (JSI). JSI is leading the Slovenian research organisation. [1]

In terms of modularity the platform consists of a main part which is the sensor node core (SNC) and the special modules that are used for specific applications. This modules are the sensor node radio(SNR) and the sensor node expansion(SNE). The Figure 3.7 is a SNC and a SNR.

April 13, 2015 Master thesis page 13/54 Authored by: Xavier Perez´ Simo´ The SNC is based on the high-performance microcontroller STM32f103re from the ST Microelec- tronics running with its internal clock since the platform does not include a crystal oscillator. The internal RC oscillator for the clock source works at 8MHz [27]. The external clock signal can be derived from the radio module via the radio connector.

SNC has a low memory storage capacity, 512kB of flash memory and 192KB of RAM (SRAM + NVRAM). It has five different connectors to get all extension modules. It is supported several communication protocols like USB, RS232/UART, SPI and I2C. This modules also incorporates the instrumentation amplifier and the 12bit ADC/DAC.

They have multiple power supply sources such as the multi chemistry battery support and the USB. In addition, it has a stand alone solar charger for the application that requiring solar cell power sources. The flexible power supply can be powered by a DC power source from 5 to 24V. VESNA provided low power modes that allowed to put in a hibernation state with power consumption below to 10µA.

Figure 3.7: VESNA platform.

The SNE allows different sets of sensors for temperature, humidity, luminance, color, reflectance, pressure, presence, location, sound, acceleration, gasses and motion. Moreover, SNE allows different sets of actuators for motor, relay, servo and alarm.

The SNR are low power radio modules that can be attached to the SNC (Sensor Node Core) pro- viding short range communication capabilities. The radio module is equipped with a light-emitting diode (LED) that is connected to the chip select line. The LED gives a visual representation of the communication between the transceiver and the microcontroller unit (MCU).

April 13, 2015 Master thesis page 14/54 Authored by: Xavier Perez´ Simo´ There are two main groups of SNR. On the one hand, there is the SNR-TRX which is using the transceiver CC1101 (fig:3.8) or AT86RF231 (fig:3.9). CC1101 runs at 868MHz whereas AT86RF231 runs at 2.4GHz in industrial, scientific and medical band (ISM). AT86RF231 is using the standard communication protocol IEEE 802.15.4.

On the other hand, there is the SNR-MOD which involves the ZigBee or the Telit in the wireless M-bus protocol software(WMBUS). These modules can been used for different applications such as the 6LoWPAN, a low cost spectrum sensing and a point to multi-point wireless communication.

Figure 3.8: radio transceiver CC1101. Figure 3.9: radio transceiver AT86RF231.

The radio module AT86RF231 has ultra low power consumption with a minimum of 0.02µA in sleep mode and a maximum of 14.3 mA during transmission at 3dBm. It is easy to use, with registers accessible through the SPI and the interrupt pin from the radio transceiver. It includes a 128 bytes first in-first out (FIFO) of static random access memory (SRAM) for data buffering, programmable clock output to clock the host microcontroller or as timer reference and includes integrated RX/TX switch.

The CC1101 is a low-cost transceiver designed for very low-power wireless applications. It pro- vides extensive hardware support for packet handling, data buffering, burst transmissions, clear channel assessment, link quality indication and wake-on-radio. The main operating parameters and the 64-byte transmit/receive FIFOs of the CC1101 can be controlled via an SPI interface.

In a typical systems, these radio modules will be used together with a microcontroller and a few additional passive components.

April 13, 2015 Master thesis page 15/54 Authored by: Xavier Perez´ Simo´ 3.2 Operating Systems

A sensor node includes a processor that executes tasks which require access to hardware el- ement such as memory, input/output, and communications. The operating system (OS) allows coordinating the use of resources and offers an interface to the hardware to make it independent from the applications that sensor node executes. There exists a great amount of OSs for instance FreeRTOS, Tiny OS, µC/OS II, Contiki, and RIOT.

3.2.1 FreeRTOS

It is a free source real-time multiplatform OS. It supports tasks which can be assigned with the different priority level. Semaphores are performing the communication and synchronization be- tween tasks and interruptions. FreRTOS doesn’t have limitacions on the maximum number of tasks which can be created and neither it has limits in the number of priority levels which can be used.

FreeRTOS are available for several processors platforms, including Cortex-M3, ARM7, MSP430, H8/S, AMD, AVR, x86 and 8051 [16].

3.2.2 Tiny OS

Tiny OS was created by researchers from the University of Berkley in the frame of the SmartDust project. It is a free source code multi-platform OS used in several hardware platforms such as: MICA, TelosB, Cricket and Shimmer.

It has no kernel to interface with the hardware. It is based in three functional abstractions which are: Events, commands and tasks. TinyOS supports only priority levels which is a reduced value in comparison with those supported by other OSs. It restricts the maximum number of tasks to 255. Only one simultaneously active task is allowed and it can only be preempted by events or commands. Tiny OS is written in nesC that is a dialect of the C language.

April 13, 2015 Master thesis page 16/54 Authored by: Xavier Perez´ Simo´ Development tools are available for implement applications using the Tiny OS. These tools are: The TOOSSIM and the PowerTOSSIM. It has an embedded communication facilities such as the concept of an active message. The message has a handler address that is used on the arrival of the message to call the handler.

In addition, the TinyOS has functionalities to support multi-hop communication, instead of single- hop communication, which is the default one in the most OSs. The last TinyOS version that has being written was 2.1.0. [18]

3.2.3 µC/OS II:

It is a multiplatform OS developed by Micrium. This is a preemptive real time multithreading OS intended for the embedded systems. This OS can manage up to 255 tasks and specifies up to 64 priority levels. Only 56 priorities can be used by applications and the same priority can be specified to different tasks. Synchronization and communication among tasks or between tasks and interruptions is based on semaphores. It is not freely available and requires listening from Micrium Inc, but it is free for an educational purpose. It is compatible with most of the popular processors and boards available in the market.[17]

3.2.4 Contiki

It is an open source, highly portable, multi-tasking OS for constrained embedded systems. It uses C as a programing language.

Contiki offers most of the standard features of an OS such as threads, timers, random number generations (RNG), file system and command line shell.

Contiki consist of an event-driven kernel. Programs are dynamically loaded and unloaded on the top of this kernel. Contiki supports inter-process communication using message passing through events. Contiki is designed for microcontrollers with small amounts of memory. A typical Contiki configuration is 2kB of RAM and 30kB ROM.

Contiki runs on a variety of platforms that for instance are: sky, avr-rcb, econotag and exp5438 among others.

April 13, 2015 Master thesis page 17/54 Authored by: Xavier Perez´ Simo´ The typical applications using Contiki is for numerous commercial and non-commercial systems that for example are: Sound monitoring, street lights, networked electrical power meters, indus- trial monitoring and radiation monitoring [15].

3.2.5 RIOT

RIOT is an open source real time operating system (RTOS). Concretely, RIOT is a soft RTOS since it has been built to reduce resource consumption, tolerate overloads and adapt to system changes.

RIOT supports several boards, central processing units (CPUs), peripherals and drivers. The advantages of use RIOT functions makes the application cleaner and easier for the developers. Another advantage is that RIOT scheduling is C and C++.

RIOT has a modular directory architecture. He current tree has the following folders: boards, CPU, core, drivers, dist, system, documentation, examples and test.

RIOT defines the board, the CPU and the application peripherals in the ”board.c” which is always compiled. The board folder and the CPU provide the configurations and the initialization code for the supported platforms and the CPU. There are a CPU and a board called native in the repository which allows to execute the code natively on a x86 module runing linux. The CPU folder contains the microcontroller specific implementations like startup and exception code handling.

The RIOT micro-kernel, which is in the core folder, comprises a thread management, a priority- based scheduler, a system timer, and a mutex. The system folder contains the libraries, the tools and the utilities such as the implementation of the network stacks. The standard communication protocol IEEE 802.15.4 is supporting by RIOT in the system folder. The ”dist” folder contains a template for creating an application and a Makefile. It contains as well external utilities like the terminal program pyterm or a script to build the toolchain for ARM microcontrollers. It includes also the Makefiles to integrate the external libraries into RIOT. The drivers folder contains the libraries for external module devices for radio or sensors.

The doxygen documentation is in the doc folder. It contains descriptions for modules, functions, header files list and brief drivers descriptions. The examples folder provides simple applications such as ”hello world” or pingpong threads.

April 13, 2015 Master thesis page 18/54 Authored by: Xavier Perez´ Simo´ RIOT also includes in the test folder different codes in order to test drivers, peripherals and functions threads. As driver test includes several sensors code test for HDC1000, MAG3110, ISL29020, I3G4200d, IPS331AP and TMP006. As a peripheral test includes code test for: A general purpose input/output (GPIO), an inter-integrated circuit (I2C), a serial peripheral interface (SPI), a pulse width modulation (PWM), an universal asynchronous receiver/transmitter (UART) and a analog to digital converter (ADC). Also provides different thread test codes for send mes- sages to another thread and also using the timing functions (vtimer functions) to send messages to another thread.

3.3 Medium Access Control (MAC) Protocols

The Medium access control (MAC) manages access to a channel shared by several nodes. This section presents the MAC protocols options to implement in this WSN. The MAC layer design can be in random access or deterministic access.

3.3.1 Random Access

3.3.1.1 ALOHA

ALOHA is one of the earliest MAC protocol. When a device has data to transmit, in ALOHA it simply transmits the data. If there is a collision between two or more transmissions, the device retry the transmission later. The ALOHA capacity channel has a 18.4% of theoretical maximum throughput. The inefficiency of the protocol is the collisions.

3.3.1.2 CSMA/CA and IEEE 802.15.4

Carrier sense multiple access (CSMA) is a channel-access mechanism in which nodes listen to the medium to verify that there are not transmissions before the transmitting data.

A node that has a frame to transmit in the CSMA/CA listen first the medium. If the medium is idle then the node transmits the frame. Otherwise, the node delay transmission for a random amount of time and tries the transmission again. The collision avoidance (CA) is based on transmits an

April 13, 2015 Master thesis page 19/54 Authored by: Xavier Perez´ Simo´ acknowledgment to the sender, when a device receives a data frame. If the sender receives the acknowledgment, it can deduce that a collision has not occurred for the transmission of the data frame. Otherwise, the sender retransmits the data frame. The CSMA/CA is used in several wireless standards such as IEEE 802.11, Wi-Fi or IEEE 802.15.4.

The standard protocol IEEE 802.15.4 defines three roles, called PAN coordinator, coordinator, and device. If a coordinator is the main controller of the network, it is called a PAN coordinator. A coordinator is capable of relaying messages. A node that is not a controller is called a device.

The superframe is divided into 16 slots of the same size and requires the presence of a coor- dinator in the network. The superframe started by network beacons which describe the specific format of the superframe and identify the PAN which are used for the synchronization. The co- ordinator transmits beacons at predetermined interval between 15ms and 251s. The superframe can have an inactive period during when the nodes has low-power mode and cannot transmit data, therefore the communication take place only during an active period. The active period is composed of the contention access period (CAP) and optionally, the contention free period (CFP). During the CAP, any device uses slotted CSMA/CA for channel access. The CFP may be composed of up to seven guaranteed time slots (GTSs), which are portions of the superframe devoted to a specific application. GTSs are useful for applications have to be completed before the next superframe period. The Figure 3.10 shows an example of a superframe.

Figure 3.10: Example of a superframe.

IEEE 802.15.4 specifies four types of MAC frames, called: beacon frame, data frame, acknowl- edgment frame and MAC command frame. The MAC header contains the frame control, se- quence number and addressing information fields (Figure 3.11). The frame control field has a size of two bytes and contains information about the frame type, addressing fields and other con- trol flags. The sequence number field has a size of one byte and specifies a unique number for a frame. The addressing fields may include a two byte destination PAN identifier, 16 or 64 bits for the destination address, a two byte source PAN identifier and 16 or 64 bits for the source address.

April 13, 2015 Master thesis page 20/54 Authored by: Xavier Perez´ Simo´ Figure 3.11: MAC header.

3.3.2 Deterministic Access

3.3.2.1 FDMA

Frequency division multiple access (FDMA) is a technology for the total amount of spectrum is divided in a number of channels. Each channel can be assigned to a different user. FDMA is com- monly used in analog mobile radio, including analogue cellular mobile telephone systems like the advanced mobile phone service (AMPS) and the total access communications system (TACS). Between the different used frequency channels is a small amount of bandwidth not used. This space is called a guard band. This bandwidth is necessary take into account no-ideal filtering.

3.3.2.2 CDMA

Code division multiple access (CDMA) assigns unique codes to each communication to differenti- ate it from others in the same spectrum. CDMA is a ”spread spectrum” technology, allowing many users to occupy the same time and frequency allocations in a given band/space. CDMA enables many more people to share the airwaves at the same time than do alternative technologies. The CDMA air interface is used in both 2G and 3G networks.

3.3.2.3 TDMA

Time division multiple access (TDMA) is a MAC mechanism in which time is divided into struc- tures called frames, which are composed of time intervals called slots, such as shows in the Figure 3.12. In general, the slots have a fixed size. Each slot is reserved for the data transmis- sion of a specific node, therefore it is essential to know the time oscillation from this slots in order to avoid conflicts between the nodes transmissions. This protocol select specific time interval for the transmission of each node and the nodes must have the clock synchronized in order to start all slots in time.

April 13, 2015 Master thesis page 21/54 Authored by: Xavier Perez´ Simo´ Figure 3.12: TDMA diagram.

A drawback of the TDMA is that when the nodes have no data to transmit, their slots remain unused. A wireless node can turn off the radio for energy conservation during the slots of the remaining nodes. In addition, the TDMA is a simple and easy to implement approach but requires a RTOS. Some applications require a deterministic access in the WSN for send packets at a regular interval for instance a smoke detector.

3.4 Testbed Development

3.4.1 Selected the testbed options

The platform hardware chosen to implement a WSN testbed was VESNA platform and the OS was RIOT.

I have chosen RIOT because it was the open source real-time operating system which provid- ing real time functions and it had clear folders structure according to boards, CPU, system and drivers.

The reasons why I chose VESNA was because it is equipped with a STM32F103re which is supported by RIOT, therefore it makes easier adapting the VESNA platform in RIOT. Addition- ally, the VESNA platforms were owned by TriaGnoSys GmbH. Another reason is that VESNA’s developers offers private software in github repository to implement some simple applications.

In order to establish a communication between the wireless nodes has been chosen a medium access control (MAC). The MAC must be deterministic since some applications require a deter- ministic radio access. For example, the smoke detector sends a packet at a regular interval, also the Airworthiness certification needs to prove to the regulators that the radio link is deterministic.

There were different deterministic MAC options which were the CDMA, the FDMA and the TDMA. The preliminary work in this thesis consist on chosen a deterministic MAC protocol for the WSN.

April 13, 2015 Master thesis page 22/54 Authored by: Xavier Perez´ Simo´ This was the TDMA because, the FDMA had limited number of channels (16 channels on 2.4GHz band) and the CDMA implementation was a challenging for now. The TDMA is the most appro- priate protocol for the aeronautical WSNs since there isn’t need to completely restructure the protocol.

3.4.2 Supporting VESNA in RIOT

I imported RIOT-OS from the github repository directly in Eclipse [3]. RIOT was supporting for default different boards and CPU, but it didn’t support the VESNA platform. The preliminary worked to created the testbed was adapting RIOT in the VESNA platform.

At the beginning, the RIOT kernel initialized the default board functions when the firmware started. It was necessary to define this board initialization procedure and defined its configurations since RIOT didn’t supports the VESNA platform by default.

VESNA and iot-lab M3 [28] platforms were running with the same µC (STM32f103re [29]). Iot- lab M3 was supporting by RIOT for default, so I used the default configuration from the Iot-lab M3 for adapting the VESNA platform.

Every RIOT board have two header files for default which were the ”board.h” and the ”pe- riph config.h”. All initialization board functions were called and implemented in ”board.c”. My adaptation in VESNA platform consisted in adapting these board files. See the appendix 8.2.1 for more details.

I also adapted the script ”flash.sh” in order to flash the programs to VENSA platform. I adapted the script in order to using the ST-Link/V2 debugger with the OpenOCD. See the github repository for the complete file[36].

April 13, 2015 Master thesis page 23/54 Authored by: Xavier Perez´ Simo´ Chapter 4

Developing applications with RIOT-OS

RIOT provides some examples source code in the examples folder. There are example ap- plications and sample Makefiles. These template Makefiles show how to compile and link the application against RIOT. This OS is supporting several applications examples for default that can been used for implement custom applications.

4.1 Defining an Application

The two minimum elements to define an application are the ”main.c” and the Makefile. The Make- file must include the project sources, the project headers and define at minimum two parameters called in the Makefile as ”BOARD” and ”RIOTBASE”.

An application only compiles by default its main.c, the kernel, and the platform specific code. It is necessary to add the modules in the Makefile with ”USEMODULE” variable in order to use additional peripheral modules such as a particular device driver or a system library. If the module depends on another modules, this information needs to be also added to RIOT’s Makefile. For instance, to build an application using the transceiver AT86RF231 it is necessary add these lines in the Makefile:

USEMODULE += at86rf231 USEMODULE += transceiver

April 13, 2015 Master thesis page 24/54 Authored by: Xavier Perez´ Simo´ Most modules require an initialization before they can be used. In some cases the initialization function does not have special configurations. For these modules you might use the auto-init feature by adding a line ”USEMODULE += auto-init” in the Makefile. Auto-init calls all module initialization functions just before the main thread gets executed.

4.2 Multithreading Capability

RIOT has a priority-based scheduler build in which consist in a threading model. The advantages of this model are totally portable and have few system dependencies.

However, the disadvantage is memory management. When the threads have been defined for the application, it is necessary to define a stack allocation for each thread. This can cause problems of memory allocation. Default stack size parameters for the threads are: Idle 256 Bytes and main 1024 Bytes. RIOT has a special function to measure the free stack size from a thread, this is the ”thread measure stack free”.

Moreover, RIOT has limitations to define number of threads, it only can handle maximum of 32 threads. RIOT has two kernel threads (idle and main) and several applications threads. The ap- plications using RIOT may has been implemented using different threads with different priorities.

It is necessary to define all threads in the main application. The parameters required for defining a thread are: Name, priority, stack size, flags and function. There are three flags to define threads that are: ”Create sleeping” that sets the new thread to sleep, ”Create without yield” that doesn’t call automatically ”thread yield” after creation the thread and ”Create stacktest” that writes markers into the thread’s stack to measure the stack usage for a debugging mode.

The follow part code is an example to define the thread parameters and the memory stack to allocated the thread:

char second_thread_stack[KERNEL_CONF_STACKSIZE_MAIN];

kernel_pid_t pid = thread_create( second_thread_stack, sizeof(second_thread_stack), PRIORITY_MAIN - 1, CREATE_STACKTEST, second_thread, NULL, "pong");

April 13, 2015 Master thesis page 25/54 Authored by: Xavier Perez´ Simo´ RIOT called ”idle” and ”main” threads when it starts. After that, the rest of the threads for a specific application will be created in the main. Finally, when RIOT has already created all the threads, RIOT core stars to execute these threads with the major priority.

RIOT provides a function called ”thread print all” to print a process identifier (PID) table in the debug output. The follow table is an example of ”thread print all” which has four threads, two for default and two defined in that application example.

pid | name | state Q | pri | stack ( used) | location 1 | idle | pending Q | 15 | 256 ( 136) | 0x2000059c 2 | main | pending Q | 7 | 2048 ( 1808) | 0x2000069c 3 | blinker_on | running Q | 6 | 2048 ( 1724) | 0x20001114 4 | blinker_off | bl mutex _ | 5 | 2048 ( 1652) | 0x20001914 | SUM | | | 6400 ( 5320)

In the PID table application above there have four different threads with different priorities, higher number of priority on the table means lower priority execution. For instance, the thread ”blinker off”(5) has a major priority than the thread ”blinker on”(6). All of them has the same thread allocation which is 2048 Bytes except idle which is 256 Bytes.

The application can stop the current thread if one of these functions that are ”thread sleep”, ”thread yield” and ”thread yield higher” have been called by the current thread. After that, RIOT kernel will be able to execute another thread. ”Thread yield higher” forces the kernel to exe- cute another thread with a higher priority than the current thread who has called this function ”Thread yield higher”. However the function ”thread yield” only forces to exit the current thread and execute a new one with any priority. The function ”thread sleep” sends the current thread to sleep state and will not be executed again until another thread wakes it up.

The mutex system controls the threads using the functions ”mutex lock” or ”mutex unlock”. When one thread calls the ”mutex lock”, the kernel does not have any possibilities to switch thread until the current thread calls the function ”mutex unlock”. In that moment RIOT kernel will be able again to execute another thread.

”msg receive” blocks the thread until receive a message from the interrupt function ”vtimer callback msg”. This function takes part from the functions who send messages. These are ”msg send” or ”vtimer set msg” and they can been called from another threads or from the same thread. The function ”vtimer set msg” defines a delay to send the message instead of ”msg send” that sends the message when the function has just been executed.

April 13, 2015 Master thesis page 26/54 Authored by: Xavier Perez´ Simo´ The RIOT kernel manages those threads with a state machine. When a thread is using the CPU, this thread is in ”running” state. When threads are sending or receiving messages, these are in ”blocked” state. If the thread doesn’t have an infinite loop, it will became in ”stopped” state after one execution. When the kernel wants to execute any thread again, it will set it to ”pending” state before running again in order to wait that the CPU will be available.

In order to optimize the execution time, it is possible to send a thread to ”sleeping” state in the meantime the application does not need to execute it. The thread can be in ”sleeping” state after creation if it was defined with the flag ”create sleeping”. The thread can also go into ”sleeping” state if the function ”thread sleep” is called during its execution. External threads will call specific functions like ”thread wakeup” or ”vtimer set wakeup” to wake up a sleeping thread. The next diagram in Figure 4.1 shows all possible states for threads that RIOT has.

Figure 4.1: RIOT state machine.

April 13, 2015 Master thesis page 27/54 Authored by: Xavier Perez´ Simo´ Chapter 5

RIOT-OS Latency Measurement

The latency measurements are based using different timing functions from RIOT and VESNA software. It consists in investigating how good are these timing functions that offers RIOT and VESNA software.

Concretely, these measurements have been performed to know the latency from the RIOT timing functions in order to plan a custom TDMA implementation using this OS. The intention is setting a fixed time slot periods in these timing functions for implementing a custom TDMA. Moreover, with this test has been seen if the RIOT can be used for real-time applications.

Several factors have been defined during the latency measurements for the purpose of studding the RIOT timing functions in different conditions.

5.1 RIOT timer module

RIOT provides two timing functions which are the ”vtimer usleep” and the ”vtimer set msg”.

The ”vtimer usleep” hinders the program until a predefined interval has been expired. It means that during a specific time interval the application will not be available until this predefined delay has been terminated. This function fixed first the interval input as an offset time. Then, the func- tion checks always the actual time if it has exceeded the offset interval. The function terminates when the actual time has passed the offset. The actual time has been captured by a hardware timer using the function ”htimer now”.

April 13, 2015 Master thesis page 28/54 Authored by: Xavier Perez´ Simo´ However, the advantge of the other RIOT timer module is that the application can execute other functions availables within RIOT-OS until the predefined interval time (by ”vtimer set msg”), has been expired. This consist in two functions, first, the function ”vtimer set msg” which is fixed to send a message after an interval time and second, the function ”receive msg” is waiting for receiving the message that has been sent by the first function.

The function ”vtimer set msg” decreases this offset time to send a message using internal vari- ables until expired it. In that moment the function call the interrupt ”vtimer callback msg” to send a message which will been received by the function ”receive msg”.

Both functions from the RIOT timer module achieved the same, but when the application is us- ing ”vtimer set msg”, it is able to perform another task before the time has been expired. The ”vtimer usleep” only defines a specific time to block the program, whereas the ”vtimer set msg” defines a specific interval where the program may perform another task until expired the time.

The Figure 5.1 shows an application example using these timing functions. The purpose was establish a fixed time for performing specific tasks (reading temperature and transmit values) and to wait until finish the predefined time. If we are using the function ”vtimer usleep”, it is difficult to fix the time slot since the timing function needs a fixed interval, but we don’t know how much time takes the rest of the tasks. However, the function ”vtimer set msg” fixed to send a message after an interval time and it isn’t necessary to wait a specific time interval for receiving the message in that application. The function has a limitation when the task ”reading temperature” takes more time than the fixed time slot. If this happens the program call the function ”receive msg” after the message has been sent by function ”vtimer set msg”, then the application will never receive the message to finish the time slot since the message has already been sent before.

Figure 5.1: RIOT timing functions diagram.

April 13, 2015 Master thesis page 29/54 Authored by: Xavier Perez´ Simo´ 5.2 Latency Measurement

Latency is a time interval between a theoretical and a practical value. The latency time indicates how good is the RIOT timing functions (”vtimer usleep” and ”vtimer set msg”). I am going to analyze the latency time from these timing functions using different measurements. The algorithm that measures latencies calculates the time difference between a practical interval time and a theoretical interval time using the RIOT timing functions.

The code defines 1ms, 5ms or 10ms as a theoretical interval using the functions ”vtimer usleep” or ”vtimer set msg”. Then the application calculates a practical time interval using the function ”vtimer now”. The program captures two points of time using ”vtimer now” and the practical time interval is the difference between those values. After that, the latency will be the subtraction result between the theoretical time interval and the practical time interval. The Figure 5.2 shows this main algorithm concept where the ”actual wakeup time” is the practical value. The latency values have been kept in a histogram range vector form 0 to 999. If a latency value is out of this range, the code kept this value as an overflow. When the latency test has finished the application prints to debug output port the histogram values and some statistic results. They are maximum and minimum latency time and the maximum repetition cases with the same latency value.

Figure 5.2: Cyclictest diagram.

There are several factors that may affect the measurement results. I used two timing functions which are ”vtimer usleep” and ”vtimer set msg”. Moreover, I selected representatives values to define slots widths that are 1ms, 5ms and 10ms. Another factor is adding background threads that are running as a simple counter. These background threads may be in a lower priority or in a same priority than the latency measurement thread. I added up to four threads running as a background. The measurements have been performed 10000 repetitions for each combination of factors. April 13, 2015 Master thesis page 30/54 Authored by: Xavier Perez´ Simo´ The code that has been implemented for this test is in the appendix 8.2.2. At the beginning, the code defines all the factors described above in order to create different test cases. The clock properties (frequency, resolution and accuracy) are not considered for now in these test cases.

5.3 Measurement results and analyses

The measurement results consists in creating statistical graphs which are histograms and cu- mulative distribution function (CDF). I used specific python scripts [22] to perform these graph for a statistical analysing, but first I had filtered the values from the debug output port using the comand line ”grep”.

There are in total 16 histograms which each one is a combination of factors described in the before section. This factors are: The number of threads, the timing functions and the time-slot controlling thread with a different priority. The histograms have in common the repeating times and the slot width (1ms, 5ms or 10ms).

All the histograms content 10000 values from the latency repetitions measurements in each com- bination of factors. This number has been considered optimum for this test, although the statistical variations may also have an impact on the measurement result. The another common parameter in each histogram is the time slot width. The three possible time slot width (1ms, 5ms or 10ms) have been integrated in each histogram which have in common the same combination of fac- tors. These histograms have been created with three different graphs lines which are the three different time slot width (1ms, 5ms and 10ms).

There is an histogram example in the Figure 5.3. For instance, the time value 135µs from 1ms slot width (green line) is repeating 200 times. Concretely, when the timing function input was 1ms, the latency was 135µs during 200 times. The values from the histograms are really concentrated in specific time values therefore, this may confirm that RIOT can be used for real-time applications.

Derived from each histogram there is a CDF graph, therefore there are also 16 CDF graph. The CDF shows the accumulated latency that the timing functions provided from the test cases. The purpose of using a CDF is to provide a graphical tool for reading the probabilities.

The CDF results in these latency cases are really vertical because the values are really concen-

April 13, 2015 Master thesis page 31/54 Authored by: Xavier Perez´ Simo´ Figure 5.3: The histogram example which runs only one thread (time-slot controlling thread)

trated in a short time range.

There is a CDF example in the Figure 5.4. I considered in these tests a probability of 90% as the most representative value to analyze the latency test cases. In this example, the 90% of probability of a 1ms slot width is 134µs or 122µs of a 10ms slot width.

Figure 5.4: CDF.

The 90% of the probability in the CDF, that came from all the test cases, have been collected in four different tables. The difference between the tables are: The timing function used (”vtimer usleep” or ”vtimer set msg”) and the priority form the time-slot controlling thread.

The Figures 5.5 and 5.6 show the tables where threads have the same priority. The differences between these tables are only the timing functions used (”vtimer usleep” or ”vtimer set msg”).

April 13, 2015 Master thesis page 32/54 Authored by: Xavier Perez´ Simo´ Figure 5.5: ”usleep” results with the same priority.

Figure 5.6: ”Set msg” results with the same priority

The results showed that the ”vtimer set msg” is slightly better than the ”vtimer usleep” but the differences between both timing functions can be considered insignificant.

The graphical representation in the Figures 5.7 and 5.8 came from the values tables above. The graphs showed minimum differences between using both timing functions. When the time slot decreases, the latency will be a little bit higher as show the blue line (1ms) in Figure 5.7.

Figure 5.7: ”usleep” results.

Figure 5.8: ”Set msg” results.

April 13, 2015 Master thesis page 33/54 Authored by: Xavier Perez´ Simo´ The follow tables in the Figures 5.9 and 5.10 are the test cases with a different priority form time- slot controlling thread. Concretely, the time-slot controlling thread has a higher priority than other threads which are running in background.

The difference between the follow tables is the timing function used (”vtimer set msg” or ”vtimer usleep”). The values in these tables came from the 90% of probabilities along the CDFs of the test cases. The best results are achieved when the thread that is controlling time slot has a higher priority than the others threads.

Figure 5.9: ”usleep” results with different priority form time-slot controlling thread.

Figure 5.10: ”Set msg” results with different priority form time-slot controlling thread.

The Figures 5.11 and 5.12 showed the graph results came from the table values. In these cases the latency has increased more gradually than the before test cases. So the latency increased slightly according to add more threads in background.

Figure 5.11: ”usleep” results.

April 13, 2015 Master thesis page 34/54 Authored by: Xavier Perez´ Simo´ Figure 5.12: ”Set msg” results.

When the time slot thread has a higher priority than the others, the latency will be reduced increasingly the number of threads. Choosing timing functions in order to implement a custom TDMA protocol is not really important in according with the latency measurement results.

The next test cases consist in comparing timing functions from RIOT and VESNA. The differences are really clear in Figures 5.13 and 5.14. The conclusion was that the RIOT’s timing functions (Figure 5.14) performs better than the default VESNA-driver functions (Figure 5.13).

Figure 5.13: VESNA histogram

Figure 5.14: RIOT histogram.

April 13, 2015 Master thesis page 35/54 Authored by: Xavier Perez´ Simo´ Chapter 6

Wireless module development

The main blocks for wireless module development consist in choosing the radio modules for the wireless sensor nodes and implementing the custom MAC protocol that is TDMA. This last part wasn’t performed completely in this thesis, only the preliminary work has been developed. The preliminary work involved the RIOT-OS latency measurement which was in previous chapter and implementing a simple code in order to check the radio modules were working well.

The radio module options that has provided by VESNA platform are CC1101 and AT86RF231. I had worked firstly using the CC1101, but lastly I used the AT86RF231 for several technical reasons. The reasons why I chose AT86RF231 were because the module AT86RF231 has the standard communication protocol that is IEEE 802.15.4, the module is supporting by RIOT and it is running with a higher frequency and speed (250kbit/s at 2.4GHz ) than the CC1101 ( 1.2kbit/s at 800MHz).

6.1 Application using CC1101

Firstly, I had chosen the radio module CC1101. RIOT provided the generic driver for supporting CC1101, but it doesn’t enough in order to achieve the application using this radio module with RIOT. The complete CC1101 driver from RIOT needed to implement specific functions such as initialization for SPI, interrupts and GPIO for VESNA’s µC (ST32F103re). As a consequence of that, the simple radio application using this module has been developed with VESNA’s software.

April 13, 2015 Master thesis page 36/54 Authored by: Xavier Perez´ Simo´ I have been implemented a ping pong application for checking the right mode operation from these modules. All the code application has been included in the appendix 8.2.3. The radio module was working correctly using this application. It sends and receive packets to and from other VESNA platform with the same application using the CC1101. The next debug output proved that the module is working correctly while running the application described above.

Sending packet with length: 41 before write: tx underflow: 0, bytes in fifo: 0 tx underflow: 0, bytes in fifo: 42 II: sent done CC: got packetGot a packet Got packet, length 22, rssi 0x67, link quality 0xab

These module is not useful for developing the WSN because they didn’t use any specific standard MAC, and it is not completely supporting by RIOT.

The next stage consist in using the radio module AT86RF231 which has more advantages than the CC1101.

6.2 Application using AT86RF231

RIOT has a driver to support completely the radio module AT86RF231 and also RIOT has a special module, called ”transceiver” which is a multiplexer between the network stack and the radio driver AT86RF231. The module ”transceiver” provides an inter process communication (IPC) interface that allows to configure and use the radio driver AT86RF231 in order to set the radio channel to send a packet. A thread may also register at the ”transceiver” module, in order to get notified whenever a packet for the radio transceiver is been received.

6.2.1 Driver Initialization

6.2.1.1 Driver pin configuration

RIOT has a function called ”at86rf231 initialize” which configured the radio transceiver. This function initialized GPIO, SPI and interrupts for getting the communication between the micro- controller and the radio module. The Figure 6.1 showed all the communication pins required to get communication between the microcontroller and the radio module. April 13, 2015 Master thesis page 37/54 Authored by: Xavier Perez´ Simo´ Figure 6.1: Microcontroller to AT86RF231 interface [20]

The radio transceiver needed to configure the SPI signals which were: SCLK (Clock), master output - slave input (MOSI), master input - slave output(MISO) and chip select(CS). It worked in full duplex mode using a master-slave architecture. The Figure 6.1 showed the SPI signals configured in the initialization part.

After the SPI configuration, the function ”at86rf231 initialize” set the pins CS, reset and sleep in the default mode, take into account that the CS and the reset were working in invested mode. This means that default mode from the CS and the reset was a high level whereas the sleep pin was a low level.

6.2.1.2 Debugging SPI

The hardware communication between the µC to the radio module has been debugged in or- der to check the correctly radio driver initialization. The communication interface between both hardware modules was through the SPI protocol. The read/write operations using the SPI were maximum of two bytes.

I have implemented a simple code for reading the version number and the part number from the radio module using the SPI interface. The first transferred byte on the MOSI is in the command byte including an identifier bit (bit7 = 1), a bit to set read/write and 6 bits register address. The Figure 6.2 showed the composition of the command byte used in this radio module which had tree parts.

April 13, 2015 Master thesis page 38/54 Authored by: Xavier Perez´ Simo´ The first bit was always ”1” in order to get access, the second bit was ”0” for reading from the radio transceiver to the µC or ”1” for write from the µC to the radio transceiver and the rest of bits were address.

Figure 6.2: Read acces by SPI in AT86RF231 [20]

The address to read version number and part number were ”0x1D” and ”0x1D” respectively. So, the microcontroller wrote on MOSI port the command byte that were ”0x9D” (80+00+1D = 9D) from the version number and ”0x9C” (80+00+1C = 9C) from the part number. Then the µC obtained from the radio transceiver on MISO port ”2” as the version number and ”3” as the part number. The following debug output showed the commands to write/read from the MOSI and the MISO ports. kernel_init(): This is RIOT! (Version: 2014.12-280-g8ef0d-test12-LIFEBOOK-S782-vesna-board) #kernel_init(): jumping into first task... out: 9c in: was nullPointer transferred: 1 out: 0 in: 3 transferred: 2 part number is: 3 out: 9d in: was nullPointer transferred: 1 out: 0 in: 2 transferred: 2 version number is: 2

6.2.1.3 Radio transceiver modes

The radio transceiver was working in two modes which were: the basic mode and the extended mode. The state machine in Figure 6.3 showed the difference between both modes where yellow states was basic mode and blue states was extended mode. The basic mode consisted on simple radio transmitter and receiver. The extended mode has automatic acknowledgment on receive if it is requested and automatic retransmission on transmit if the ACK is requested but none is received or if the channel was busy.

When the external supply voltage (VDD) was firstly applied to the AT86RF231, the radio transceiver went into the ”P ON” state performing an on-chip reset. After the pin configuration, the function

April 13, 2015 Master thesis page 39/54 Authored by: Xavier Perez´ Simo´ ”at86rf231 initialize” from RIOT put the radio module in the reception mode on extended area which were the blue states in Figure 6.3 since RIOT worked in the extended mode.

The function ”at86rf231 initialize” also initialized the carrier sense multiple access (CSMA) since the radio module was working using the standard protocol IEEE 802.15.4. The driver performed the CSMA initialization using a RNG and specific functions that determines the length of the back-off period in the CSMA-CA algorithm.

Figure 6.3: Radio module state machine [20]

6.2.2 Pingpong Application

I have developed a ping-pong application to test no error configuration and the good transmission and reception of packets using the radio module AT86RF231. The code implementation have been developed using the RIOT functions from the IEEE 802.15.4 standard protocol and the AT86RF231 radio driver.

The challenge of this application consists in incrementing the payload values while it was sending and receiving packets, encapsulated with the IEEE 802.15.4 protocol. The Figure 6.4 showed the application scheme where involved two nodes defined with a specific address in each one. The address in this application have been defined as a short address (2 Bytes) but the driver also supported long address (8 Bytes). April 13, 2015 Master thesis page 40/54 Authored by: Xavier Perez´ Simo´ Figure 6.4: The application scheme.

The IEEE 802.15.4 required basic headers configuration such as channels, PAN, addresses, frame type and payload. The frames types used in this application was data frame, but RIOT supports others kind of frames such as beacon frame, ACK frame and MAC CMD frame. The nodes were running using the same channel (11) and the same PAN (1).

After configuring the MAC header, RIOT provides a function called ”at86rf231 send” that send a packet to the other radio transceiver. The RIOT driver is working on extended mode (blue area on Figure 6.3), it means there is an automatically ACK after send packets.

There was a network stack where save the packets when they have been received. In order to read the packets values in ”main” from this network stack, it is necessary to register the radio transceiver in ”main” using the function ”transceiver register” from the transceiver module.

When the packet was ready to read in ”main”, the payload have been incremented and send it again to the other wireless node.

The full code implementation was in appendix 8.2.3. The follow debug output reflected the appli- cation was working well.

# ********************************************* # ************ pingpong AT86RF231 ************* # ***************** STARTNODE ***************** # ********************************************* Payload received: 2 Payload received: 4 Payload received: 6 Payload received: 8 test finish

April 13, 2015 Master thesis page 41/54 Authored by: Xavier Perez´ Simo´ Chapter 7

Conclusions and future work

7.1 Conclusions

The design work presented a RIOT implementation on VESNA, latency measurements of RIOT timer functions and wireless module implementation and test. These features and their effect on performance aspects were evaluated debugging test programs on RIOT.

The most important outcome of this thesis is the testbed design that provides a wireless sensor nodes with an OS in real time, the radio modules working well without errors on configuration and the good transmission and reception of packets.

The results produced by the testbed using an OS reflected that would improve its features in real time, the code optimization, the radio drivers and the radio protocols.

In order to implement an applications on RIOT needs less flash memory than VESNA software because RIOT optimized the code when has been compiled. The RIOT system optimized the code and used less flash memory than VESNA software. VESNA platform has 1MB of flash memory. This is not a limitation to implement sophisticate applications that require a lot of allo- cation memory since VESNA platform is ready to add extended ROM memory.

The radio module chosen was the AT86RF231. The reasons to have selected this module were: it supported from RIOT, it worked in a higher frequency (2.4GHz) than the CC1101 (836MHz), it used a IEEE 802.15.4 protocol which was also supported by RIOT and it had sleep mode that got less consumption. We had to take into account that we could have interference problems if

April 13, 2015 Master thesis page 42/54 Authored by: Xavier Perez´ Simo´ there was Wi-Fi environment working at IEEE 802.11.n at 2.4GHz.

The results produced by the latency measurements were: ”vtimer set msg” was slightly better than ”vtimer usleep”, RIOT could be used for real-time applications and its timing functions per- formed better than the default VESNA-driver functions. The most significant results have been indicated by latency analyses when the time-slot controlling thread had a higher priority than other threads.

The RIOT requirements contain a low memory footprint, a high energy efficiency, real-time ca- pabilities, a modular and configurable communication stack and supports for a wide range of low-power devices and sensor modules.

7.2 Future Work

The work which has been carried out in this master thesis corresponds to the preliminary work for implementing a custom MAC protocol in the WSN. The future work will consist in implementing a custom MAC protocol for the WSN using the radio module AT86RF231.

As I was described in the section 5.3, the measurement results and analyses, the TDMA should be implemented using threads with a different priority.

Therefore, the following natural step would be to implementing the code on RIOT for developing a custom TDMA protocol for the WSN in aircrafts.

The RIOT driver for the AT86RF231 was working only in an extended mode, but the radio module had two working modes. The future work will consist also in investigating which mode will be better to use for implementing the TDMA. The extended mode has an automatic acknowledgment and perhaps wouldn’t be the best solution to implement the TDMA protocol with RIOT.

As a conclusion, in the future, the investigation should be geared to search for a way of imple- menting basic mode into the RIOT driver for the radio transceiver AT86RF231.

April 13, 2015 Master thesis page 43/54 Authored by: Xavier Perez´ Simo´ Chapter 8

Appendix

8.1 Testbed Environment

I installed cross-compiler and associated development tools that required to compile and de- bug software for VESNA on a GNU/Linux operating system. The toolchanin involved Eclipse, croscompiler and openocd onchip debugger [6][7]. It was necessary to change the configura- tions to adapt drivers with st-link [25].

8.2 Code Implementation

8.2.1 Supporting RIOT-OS in VESNA

The ”board.c” contains as well pin led configuration, UART initialization and ”cpu init”. The ”cpu init” configures internal interrupts, vector table location to internal flash and clock initial- ization. The VESNA platform runs with internal µC clock at 8MHz and it does not use any PLL configuration. It neither uses any prescaler configuration for the buses APBx. The reference [30] has the full code implementation.

The board.h contains the configuration ports (GPIOs) for radio module AT86RF231, and also the LED pin configuration. This header also defines the UART 1 configuration with a baudrate of 115200 and the timer 0 as a hardware timer. The reference [31] has full the code implementation.

April 13, 2015 Master thesis page 44/54 Authored by: Xavier Perez´ Simo´ The periph config.h contains all the peripheral configurations such as clock frequency, pins and clocks configurations, as well as configurations for UARTs, GPIOs, SPIs and even for the inter- rupts. The reference [32] has the full code implementation.

8.2.2 Latency Measurements

The code from the latency measurements has been implemented in this thesis. Firstly I imple- mented the code without multithreading options, it means that all the code was in the main [33]. Then I implemented the code adding multithreading options take into account calling the specific functions to switching threads when it is necessary [34].

8.2.3 Radio Application

I developed two pingpong applications for the radio modules CC1101 and AT86RF231 in order to evaluate if they were working correctly. I achieved no error configuration and the good transmis- sion and reception of packets in both radio module applications. The ping pong radio application using the radio module AT86RF231 is in the github repository [35].

The application using the radio module CC1101 has been implemented using VESNA’s software. The github repository from VENSA’s software was private therefore I included the code here since I can’t push my code implementation in that repository.

/** @file * @author Xavier PA~ c rez * */

#include

#include "vsn.h" #include "vsnusart.h" #include "vsnsetup.h" #include "vsntime.h" #include "vsnpm.h" #include "vsnledind.h" #include "vsncc1101.h" #include "vsnccradio.h" #include "vsncrypto.h"

/* ------* Simple example of CC1101 */

/* Global variables */ #define RX_BUF_SIZE 300

April 13, 2015 Master thesis page 45/54 Authored by: Xavier Perez´ Simo´ char rx_buf[RX_BUF_SIZE+1]; int rx_len; int received_flag; int second_current = 0; const char* testData = "M2345678901234567890123456789012345678901234567890";

/* Interrupt function */ void received();

/* Start of main */ int main(void) { USART_InitTypeDef USART_InitStructure; /* Reset Clock configuration */ SystemInit(); /* Turn on power manager */ vsnPM_init(); /* Set SysClock frequency */ vsnSetup_intClk(SNC_CLOCK_8MHZ); /* Initialize SNC */ vsnSetup_initSnc(); /* Configure debug port at USART1, 115200 kbaud, 8 data bit, no parity, one stop bit, no flow control */ USART_InitStructure.USART_BaudRate = 115200; USART_InitStructure.USART_WordLength = USART_WordLength_8b; USART_InitStructure.USART_StopBits = USART_StopBits_1; USART_InitStructure.USART_Parity = USART_Parity_No; USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; vsnUSART_init(USART1, &USART_InitStructure);

/* Make stdout unbuffered, just in case */ setbuf(stdout, NULL);

printf("SNC Initialized\r\n"); printf("Debug port Open\r\n");

/* Get ADC one bit value in volts, call as last init function */ vsnPM_mesureAdcBitVolt();

/* Init functions for sensors, actuators,... */ vsnCC1101_init(); vsnCC1101_setReceiveInterrupt(received); vsnCC1101_setMode(RX); //rx mode

received_flag = 0;

int length = 30; int last_sent = -1; /* End of init functions */

/* Start of main while */ while(1) { vsnTime_delayMS(100); /* Send a packet once per second */ second_current = vsnTime_uptime(); if ((second_current - last_sent >= 1) && (!received_flag)) { last_sent = second_current;

length = (vsnCrypto_rand() % 245) + 10;

printf("Sending packet with length: %d\n", length); vsnCC1101_send(testData, length);

} /* Check if packed received */ if( received_flag ){ printf("Got a packet\n");

April 13, 2015 Master thesis page 46/54 Authored by: Xavier Perez´ Simo´ rx_len = vsnCC1101_receive(rx_buf, RX_BUF_SIZE);

printf("Got packet, length %d, rssi 0x%x, link quality 0x%x\n", rx_len, rx_buf[rx_len-2], rx_buf[rx_len-1]); // make string null-terminated rx_buf[rx_len-2] = 0; printf("\n\n");

received_flag = 0; vsnCC1101_setMode(RX); } } /* End of main while */ } /* End of main */ void received(){ received_flag = 1; }

8.3 Time Phases

This thesis has been structured by five blocks.

I started to get used in the first block with toolchain package and the hardware environment. It is necessary first to install the cross-compiler and the associated development tools required to compile and debug software for VESNA on a GNU/Linux operating system. The toolchanin involves Eclipse, croscompiler and openocd onchip debugger [6][7].

The second block consist in understanding RIOT and embedding RIOT in VESNA platform. I defined the peripheral configurations from VESNA platform in RIOT.

In the third block I chose the radio modules between the CC1101 and the AT86RF231 and I developed applications using them.

The fourth block consists in analyzing latency in RIOT, that specific code has been implemented in this thesis. I applied prosprocessing, in order to examine experimental results. It is necessary to know the maximum latencies values in order to implement TDMA in the WSN.

The fourth block consists in developing the documentation for this project and preparing the project presentations. At the beginning, I needed to get used with the latex tool and the specific code.

The gannt below shows the thesis development from a graphic point of view. The thesis has been performed in five blocks during 24 weeks (6 months).

April 13, 2015 Master thesis page 47/54 Authored by: Xavier Perez´ Simo´ WEEKS: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

1. VESNA Init

1.1 Install tools

1.2 Vesna soft

2. Embedded RIOT

2.1 Get familiar in riot

2.2 Riot in vesna

3. Radio application

2.4 Selecting radio module

2.4 Developed applications

2.5 Understanding IEEE 802.15.4

4. Latency

3.1 Algorithm design

3.2 Experimental results

5. Thesis Documentation

4.1 Presentation

4.2 Report

April 13, 2015 Master thesis page 48/54 Authored by: Xavier Perez´ Simo´ Chapter 9

References

[1] SensorLab group website, available at: http://sensorlab.ijs.si/, 2014

[2] RIOT website, available at: http://www.riot-os.org/, 2014

[3] RIOT repository in github, available at: https://github.com/RIOT-OS/RIOT, 2014

[4] C.Gomez,´ J.Paradells, J.Caballero , ”Sensors everywhere, Wireless network technologies and solutions”, Vodafone Spain in collaboration of i2CAT, 2010,Barcelona, Spain

[5] Jozef Stefan Institute, Department of Communication Systems, available at: http://comms.ijs.si/, 2014

[6] VESNA Documentation, available at: https://github.com/sensorlab/vesna-manual, 2014

[7] CodeSourcery Lite toolchain: https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription?@template=lite, 2014

[8] Modules from Jennic, available at: http://www.jennic.com/products/modules/, 2014

[9] Modules from Radiocraf, available at: http://www.radiocrafts.com/, 2014

[10] Arduino project website, available at: http://www.arduino.cc/, 2014

[11] Zolerita website, , available at: http://www.zolertia.com/products, 2014

[12] WaspMote from Libelium, available at: http://www.libelium.com/products/waspmote, 2014

[13] Murata Website, available at: http://wireless.murata.com/eng/products/rf-modules-1.html?ref=rfm.com, 2014

April 13, 2015 Master thesis page 49/54 Authored by: Xavier Perez´ Simo´ [14] Murata platform called LPR2430, avilable at: http://wireless.murata.com/RFM/data/lpr2430.pdf, 2014

[15] Contiki repository in github, available at: https://github.com/contiki-os/contiki, 2014

[16] FreeRTOS repository in github: https://github.com/xaviersimo/FreeRTOS/tree/master/FreeRTOS, 2014

[17] µC/OS II specifications, available at: http://micrium.com/rtos/ucosii/specifications/, 2014

[18] TinyOS website, available at: http://www.tinyos.net/, 2014

[19] Waspmote platform from Libelium, available at: http://www.libelium.com/uploads/2013/02/waspmote pro-400px.jpg, 2015

[20] AT86RF231 transceiver datasheet, available at: http://www.atmel.com/Images/doc8111.pdf, 2015

[22] Latency data processing, available at: https://github.com/herrfz/rt benchmark, 2014

[23] Triagnosys GmbH, available at: http://www.triagnosys.com/, 2015

[24] Zodiac aerospace, available at: http://www.zodiacaerospace.com/en, 2015

[25] Circuit debugger/programmer St-link/V2 documentation available at, http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user manual/DM00026748.pdf, 2014

[26] St-link/V2 repository, available at: Stlink repostit https://github.com/texane/stlink, 2014

[27] Datasheet stm32f103re, available at: http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF164485, 2014

[28] The iot-lab M3 board supporting by RIOT, available at: https://github.com/xaviersimo/RIOT/tree/master/boards/iot-lab M3, 2014

[29] The CPU stm32f103re supporting by RIOT, available at: https://github.com/xaviersimo/RIOT/tree/master/cpu/stm32f1, 2014

[30] ”board.c” implementation for VESNA in RIOT, available at: https://github.com/xaviersimo/RIOT/blob/vesna-board/boards/vesna/board.c, 2014

April 13, 2015 Master thesis page 50/54 Authored by: Xavier Perez´ Simo´ [31] ”board.h” implementation for VESNA in RIOT, available at: https://github.com/xaviersimo/RIOT/blob/vesna-board/boards/vesna/include/board.h, 2014

[32] ”periph config.h” implementation for VESNA in RIOT, available at: https://github.com/xaviersimo/RIOT/blob/vesna-board/boards/vesna/include/periph conf.h, 2014

[33] The code implementation for latency measurments single thread, available at: https://github.com/xaviersimo/RIOT/blob/vesna-board/examples/latency/main.c, 2014

[34] The code implementation for latency measurments multiple thread, available at: https://github.com/xaviersimo/RIOT/blob/vesna-board/examples/multi thread latency/main.c, 2014

[35] The code implementation for pingpong radio application, available at: https://github.com/xaviersimo/RIOT/blob/vesna-board/examples/pingpong at86rf231/main.c, 2014

[36] The script to flash programs to VESNA using st-link, available at: https://github.com/xaviersimo/RIOT/blob/vesna-board/boards/vesna/dist/flash.sh, 2014

[37] Wireless avionics intra-communications (WAIC) overview, available at: http://waic.avsi.aero/downloads/WAIC Overview and Application Examples.pdf, 2015

[38] LPR2430 platform from Murata, available at: http://www.mouser.com/images/microsites/RFMLPR2430.jpg, 2015

[39] Arduino Mega platform, available at: http://arduino.cc/en/Main/ArduinoBoardMega, 2015

[40] Z1 platform from Zolerita, available at: http://www.zolertia.com/products/z1, 2015

[41] Radiocraft module, available at: http://m.eet.com/media/1091563/051410.jpg, 2015

[42] JN5148 module from Jennic, available at: http://www.jennic.com/files/media/Module.jpg, 2015

April 13, 2015 Master thesis page 51/54 Authored by: Xavier Perez´ Simo´ Chapter 10

Acronyms

• ACK - Acknowledge Character • ADC - Analog to Digital Converter • AES - Advanced Encryption Standard • AMPS - Advanced Mobile Phone Service • CA - Collision Avoidance • CAP - Contention Access Period • CDF - Cumulative Distribution Function • CDMA - Code Division Multiple Access • CFP - Contention Free Period • CSMA - Carrier sense multiple access • CD - Collision Detection • CPU - Central Processing Unit • CS - Chip Select • FDMA - Frequency Division Multiple Access • FIFO - First in - First out • GCC - GNU C Compiler • GDB - GNU debugger • GPIO - General Purpose Input/Output • GTS - Guaranteed Time Slot • HMI - Human Machine Interface • IEEE - Institute of Electrical and Electronic Engineers

April 13, 2015 Master thesis page 52/54 Authored by: Xavier Perez´ Simo´ • I2C - Inter-Integrated Circuit • IOT - Internet Of Things • IPC - Inter Process Communication • ISM band - Industrial, Scientific and Medical Band • IC - Integrated circuit • JSI - Jozef Stefan Institute • LED - Light-Emitting Diode • LR-WPAN - Low Rate Wireless Personal Area Network • MAC - Media Access control Address • M-Bus - Meter Bus • MCU - Microcontroller Unit • MISO - Master Input - Slave Output • MOSI - Master Output - Slave Input • OS - Operating System • OpenOCD - Open on chip-debugging • PAN - Personal Area Network • PID - Proccess Identifier • PWM - Pulse Width Modulation • RAM - Random Access Memory • RISC - Reduced Instruction Set Computing • RNG - Random Number Generator • RTOS - Real Time Operating System • SNC - Sensor Node Core • SNE - Sensor Node Expansion • SNR - Sensor Node Radio • SPI - Serial Peripherial Interface • SRAM - Static Random Access Memory • TACS - Total Access Communications System • TDMA - Time Division Multiple Access • UART - Universal Asynchronous Receiver/Transmiter • VESNA - Versatile platform for Sensor Network applications

April 13, 2015 Master thesis page 53/54 Authored by: Xavier Perez´ Simo´ • WAIC - Wireless Avionics Intra-Communications • WDC - Wireless Data Concentrator • WMBUS- Wireless M-Bus Protocol Software • WSN - Wirless Sensor Networks • WSU - Wireless Supply Unit

April 13, 2015 Master thesis page 54/54 Authored by: Xavier Perez´ Simo´