Usage of Bluetooth Low Energy for Weather Measurements

(1)

Bachelor of Science Thesis in Electrical Engineering

Department of Electrical Engineering, Linköping University,

2018

Usage of Bluetooth Low

Energy for weather

measurements

(2)

Bachelor of Science Thesis in Electrical Engineering

Usage of Bluetooth Low Energy for weather measurements

Viktor Gustafsson and Calle Waller LiTH-ISY-EX-ET–18/0472–SE Supervisor: Peter Johansson

isy, Linköpings universitet

Jacob Pålsson

SparvEmbedded

Examiner: Michael Josefsson

isy, Linköpings universitet

Division of Computer Engineering Department of Electrical Engineering

Linköping University SE-581 83 Linköping, Sweden

(3)

iii

Abstract

For every year the importance of lowering energy con-sumption of our devices gets more important. Wireless de-vices get smaller which leads to the fact that they need smaller batteries than earlier versions. At the same time the customers still have high requirements on the battery time. So what fol-lows is that new technologies are needed to meet the customer requirements by lowering the energy consumption for the de-vices to maintain the same battery time as earlier.

Today it is very common that these wireless devices makes use of the wireless Bluetooth protocol in order to communi-cate with other devices, for example with a mobile applica-tion. Bluetooth is in many cases more energy consuming than necessary. In this report the wireless Bluetooth Low Energy protocol will be tested and evaluated to see if the energy con-sumption of a battery driven ground station for weather mea-surements can be reduced.

Sammanfattning

Att reducera energiförbrukningen blir viktigare för varje år. Många trådlösa enheter blir mindre vilket också innebär att dessa enheters batterier blir mindre. Samtidigt har konsu-menterna fortfarande höga krav på enheternas batteritid. Då behövs det nya tekniker för att möta konsumenternas krav genom att sänka energiförbrukningen för enheterna för att er-hålla samma batteritid som innan.

Det är väldigt vanligt att dessa trådlösa enheter idag an-vänder sig av det trådlösa protokollet Bluetooth för att kom-municera med omvärlden, exempelvis till en mobilapplika-tion. Bluetooth är i många fall mer energikrävande än nöd-vändigt. I den här rapporten kommer det trådlösa protokollet Bluetooth Low Energy att testas och utvärderas för att se om det går att reducera energiförbrukningen på en batteridriven markstation för vädermätningar.

(4)

(5)

Acknowledgments

We want to thank our supervisor Jacob Pålsson at SparvEmbed-ded for giving us a helping hand when we neeSparvEmbed-ded it.

We also want to thank our supervisor Peter Johansson at LiU.

Linköping, April 2018 Viktor Gustafsson och Calle Waller

(6)

(7)

5 Results 33 5.1 Introduction . . . 33 5.2 Bluetooth classic . . . 33 5.3 Power mode 1 . . . 34 5.4 Power mode 2 . . . 37 5.5 Power consumption . . . 38 6 Discussion 41 6.1 Results . . . 41 6.2 Method . . . 42 6.2.1 Test board . . . 42 6.2.2 Current measurements . . . 42 6.2.3 Replicability . . . 43

6.3 The work in a wider perspective . . . 43

6.4 Source criticism . . . 43

7 Conclusions 45 7.1 Conclusions . . . 45

(9)

Contents ix

7.1.1 Comparing BLE and Bluetooth classic . . . . 45

7.1.2 Configuring BT121 . . . 46

7.1.3 Configuring GATT profile and packing of data 46 7.2 Future work . . . 46 A Appendix 49 A.1 project.xml . . . 49 A.2 did.xml . . . 50 A.3 hardware.xml . . . 51 A.4 spp.xml . . . 51 A.5 GATT.xml . . . 52 Bibliography 55

(10)

(11)

List of Figures

3.1 Comparison between the data rate of Modems, Ether-net, Wi-Fi and Bluetooth over time per version

num-ber. . . 10

3.2 Bluetooth Low Energy Protocol Stack. Host is the higher layers which handles high level data. Con-troller is lower layer which contain the radio interface. 11 3.3 The four parts that builds up an attribute where the three first explain what the value presents. . . 13

3.4 Relation between profiles, services and characteris-tics for a device. . . 15

3.5 Central and peripheral connect request. . . 16

3.6 Observer and broadcaster. . . 17

3.7 Bonding procedure. . . 19

4.1 The circuit board. . . 22

4.2 FTDI chip used to communicate with processor. . . . 23

4.3 STM32 the processor used on the ciruit board. . . 23

4.4 Serial port master a windows program to read from serial port. . . 29

4.5 Services and characteristics in the Windsond profile. 30 4.6 Notifications in a characteristic fired by a hardware timer. . . 30

4.7 Shunt resistor for current measurement. . . 31

5.1 Classic BT is advertising. The scaling is 500 ms per unit on the x-axis and 50 mV per unit on the y-axis. . 34

5.2 Classic BT is connected and sending on oscilloscope. The scaling is 1 s per unit on the x-axis and 100 mV per unit on the y-axis. . . 35

(12)

5.3 BLE is advertising. The scaling is 2 s per unit on the x-axis and 50 mV per unit on the y-axis. . . 35 5.4 Connected with BLE on oscilloscope. The scaling is

500 ms per unit on the x-axis and 100 mV per unit on the y-axis. . . 36 5.5 Connection interval message when connected to BLE

on oscilloscope. The scaling is 20 us per unit on the x-axis and 100 mV per unit on the y-axis. . . 36 5.6 Message with content on oscilloscope. The scaling is

20 us per unit on the x-axis and 100 mV per unit on the y-axis. . . 37 5.7 Wake up sequence from power mode 2 on

oscillo-scope. The scaling is 1 ms per unit on the x-axis and 100 mV per unit on the y-axis. . . 38

List of Tables

4.1 The different power modes for BT121 . . . 27 5.1 Power consumption for advertisement and connected

state . . . 39 5.2 Power consumption when sending five times per

sec-ond . . . 39 5.3 Power consumption when sendning one time per

sec-ond . . . 39 5.4 Power consumption when sending every fifth second 40

(13)

Notation

Abbre-viation/ Acronym

Meaning Explanation Context

BLE Bluetooth Low Energy

A later version Bluetooth that specifies its own communication protocol

Used in Bluetooth low energy

GATT Generic Attribute Profile Defines a framework of attributes for Bluetooth Low Energy Used in Bluetooth low energy

GAP Generic Access Profile Defines how Bluetooth Low Energy devices can connect and bond to each other Used in Bluetooth low energy

ATT Attribute Protocol

Defines a profiles attribute can be accessed Used in Bluetooth low energy 3

(14)

4 Notation

Abbre-viation/ Acronym

Meaning Explanation Context

PM1 Power Mode 1

Power mode that allows sleep mode for BT121 Used in Bluetooth low energy PM2 Power Mode 2 Power mode that allows deep sleep mode for BT121

Used in Bluetooth low energy STM32 STM32F105 The processor

used in the thesis

Mentioned in Chapter 4

(15)

1

Introduction

This thesis goal is to study if it is possible to reduce the power consumption of the product Windsond, developed by the company SparvEmbedded. Windsond is a weather balloon which measure weather in the lower atmosphere, that mainly is used to forecast tor-nadoes. This thesis will focus on the ground station for Windsond and how weather measurements can be sent to an Android device with Bluetooth Low Energy (BLE).

1.1 Purpose

The purpose with this thesis is to find out how and if it is possi-ble to reduce the power consumption on a weather station by using Bluetooth Low Energy instead of classic Bluetooth. The Bluetooth module that will be used to test the different protocols in this thesis is the Bluegiga module BT121 [1].

1.2 Problem statements

To drive the work to the important goals some problem state-ments had been chosen for this thesis.

• How much is it possible to reduce the power consumption when using BLE instead of classic Bluetooth?

(16)

6 1 Introduction

• How can the power consumption be reduced by configuring the device BT121?

• How can a good performance be obtained by configuring the GATT and the packing of data?

1.3 Limitations

The given Bluetooth device BT121 will be used for this thesis. Other Bluetooth devices will not be tested in this thesis.

(17)

2

Background

In order to get a better understanding of what the project is origi-nating from the background of the product and the method will be described in this background chapter

2.1 Introduction

The ground station for Windsond is battery driven and portable. Its main functionality is to receive weather measurements from the Windsond via radio. Up to eight Windsonds can be connected to the ground station at any time.

The ground station is used in the field, and that is why it is portable and battery driven. The possibility to connect the ground station to an Android device makes it easier for users to utilize it in the field.

When a device is battery driven, the energy efficiency of the de-vice is of big importance. Regular Bluetooth is easy to implement, but not so energy efficient. Bluetooth Low Energy (BLE) is not so easy and straight forward to implement as regular Bluetooth. But BLE can be more energy efficient since the energy consumed per transmitted bit is lower than for regular Bluetooth [2].

(18)

(19)

3

Theory

In order to complete the project some theoretical knowledge will be needed. This information will be discussed in the theory chapter.

3.1 Introduction

In 2010 a new Bluetooth standard was accepted Bluetooth 4.0 [3]. The standard presented new improvements for the regular Blue-tooth. But there was also a new version of Bluetooth, the Bluetooth Low Energy (BLE). BLE was somewhat revolutionary. High perfor-mance was not the goal for BLE. The goal for BLE was to reduce the energy consumption as much as possible. The solution for BLE was to decrease the performance radically. BLE is not suitable to use for faster systems, because of its lowered data rate. But in some areas BLE is really suitable to use. For example, BLE is commonly used in health care, consumer electronics and security [4].

3.2 Why BLE

When Bluetooth was created, the purpose was to link cell phones and laptops together [5]. Then someone realized that Blue-tooth was good for audio streaming so people could listen to music in their headphones without cables. The new purpose for Bluetooth was a big reason why Bluetooth is so big and commonly used today.

(20)

10 3 Theory

Bluetooth is also used for file transferring, connecting the phone with a car, wireless printing and many more usages [5]. The data rate has been better and better for every new Bluetooth version un-til Bluetooth 4.0 with the BLE. Actually, there is no other technol-ogy who has lowered their data transfer speed as the Bluetooth [5], as you can see in Figure 3.1.

1 2 3 4 10−4 10−2 100 102 104

Version number in time

Speed [MBps] Ethernet Wi-Fi Bluetooth Modems

Figure 3.1: Comparison between the data rate of Modems, Eth-ernet, Wi-Fi and Bluetooth over time per version number.

The traditional Bluetooth is good for many purposes. But for low energy devices, typically with a button-cell battery, the Bluetooth consumes way too much energy [5]. The main reason why BLE was developed is that regular Bluetooth was not energy efficient enough for low energy devices. In many cases the devices also will be cheap and produced in very high volumes. Some devices will run for months, maybe years without changing the battery [5]. Other low energy wireless technologies like Zigbee, 6LoWPAN and Z-wave is already established on the market for their purpose [4]. But these technologies are not used in the market for tablets and smartphones. The fact that BLE became big so fast is because it could be used for tablet and smartphones. BLE is used in smartwatches and other low energy devices, for example internet of things devices. Another main reason why BLE is so popular is that the energy consumption is extremely low and the energy per bit transmitted is low compared

(21)

3.3 The BLE protocol stack 11 to Zigbee [2].

3.3 The BLE protocol stack

The protocol stack for BLE is divided into two main parts that are called the controller and the host as shown in Figure 3.2. The controller, or as it also can be called the lower layers, responsibility is to perform low level operations like discovering other devices, making connections, send/receive packets, enter low power modes and so on. The host, the higher layers, on the other hand are making use of the lower layers functionality to make new more complex functionality. The more complex functionalities could be serial port emulation or transferring big packets of data by splitting them up and then reassembling them [6].

Figure 3.2: Bluetooth Low Energy Protocol Stack. Host is the higher layers which handles high level data. Controller is lower layer which contain the radio interface.

Most members of the lower and the higher layers have to be spec-ified by the implementer for BLE so these parameters are important to understand for this thesis.

(22)

12 3 Theory

3.4 Attribute

An attribute can be seen as something that represents data. Each attribute is built up by four properties where three of them describe the attribute and the last is the Attribute Value. The first property is the Attribute Type that describes what kind of data the attribute holds. The Attribute type is identified by a Universally Unique Iden-tifier (UUID) which is a 128-bit value which is supposedly unique over all devices. When an UUID is applied to an attribute either one of the predefined UUIDs from the Bluetooth SIG can be used or a new UUID can be defined [6].

The second property of an attribute is the Attribute Handle. The Attribute Handle is a nonzero unique value that is used to identify the attribute by the client whenever it’s needed for an operation [6]. Once an attribute has been handed a handle it should not change over time since it makes it so that the client can access the attribute with the same handle without having search for it again.

The third property that defines an attribute is Attribute Permis-sions. Every attribute has a set of permissions that defines the level of accessibility for that attribute. What they describe is if a client has access to read or write an attribute and if some identification is needed by either authentication or authorization. If a device tries access an attribute which it doesn’t have permission to then an er-ror code will be returned. For example if a device tries to read an attribute that have read disabled then it will receive the error code “Read Not Permitted” [6].

Then there is the actual Attribute Value that holds the data value for the attribute. The size of the value can be specified or be vari-able.

To sum it up attributes are used to represent data for BLE and a picture of an attributes parts is shown in Figure 3.3. Examples for a couple of attributes can be the temperature from a sensor or a device name.

(23)

3.5 Attribute protocol 13

Figure 3.3:The four parts that builds up an attribute where the three first explain what the value presents.

3.5 Attribute protocol

The attribute protocol (ATT) is an application protocol that de-termines how a device can read, write and discover the attributes of other devices. ATT provides services to the Generic Attribute Profile.

ATT is built to use a client server model where a device can fulfil the roll of being a client, a server or both client and server at the same time. What has to be remembered is that a device only can have one server active on it at a time [6]. The server holds and exposes attributes to other connected devices. While the client can discover, read and write the attributes from a server.

The function of notification or indication can also be imple-mented for ATT. What notification and indication means is that the server can inform the client about changes for attributes. The main difference between notification and indication is that indication re-quires an acknowledgment from the client that it noticed the mes-sage while notification does not. The fact that notification does not need an acknowledgment means that it is a little more energy effi-cient while indication is more reliable since it can be confirmed that the message reach the client. The functionalities of notification and indication can be very energy efficient for a system where the client reads from the server so that it does not need to read an attribute more often than necessary [6].

3.6 Generic Attribute Profile (GATT)

Generic Attribute Profiles (GATT) defines how a set of ATT attributes are grouped together into services and characteristics. What GATT also does is defining how devices can discover, read, write, notify and indicate those characteristics. Another thing that

(24)

14 3 Theory

GATT does is defining how the broadcast of attributes will work. The fact that the broadcast has to be specified is different for BLE compared to Bluetooth classic which always broadcast itself as a serial port by default [6].

Currently all Low Energy applications base their profiles on GATT. A profile is a definition for how a device works in a spe-cific application. Note that a device can have more than one profile which is essential for many cases [6]. An example is a weather bal-loon that uses different kinds of sensors where each sensor can have a different profile.

A characteristic is a value that’s used for services alongside some description what that value presents. A characteristic is described by the characteristics definition that includes a characteristic de-scription, characteristic properties and a characteristic value. Exam-ples for a characteristic can be a thermometer sensor characteristic that measures temperatures for a weather balloon or a device name characteristic that presents a device name to other devices.

A service is a collection of related characteristics. An example for this can be the characteristic of sensors readings and its settings. Each service has a service definition that is built up by three at-tributes where the first one is mandatory and called service dec-laration that says if it is a primary or a secondary service. Then it can also have one or more attribute called include definitions that’s used to reference other devices but this attribute is not mandatory. Lastly it can have one or more characteristic definitions depending on how many characteristics it supports which also is not manda-tory to implement in the service definition [6]. A device can sup-port one or more GATT profiles. Each profile can include one or more services which in turn are include one or more characteristics [6]. An example of this is shown in Figure 3.4.

(25)

3.7 Generic Access Profile (GAP) 15

Figure 3.4: Relation between profiles, services and character-istics for a device.

To sum up it can be said that GATT defines a framework of at-tributes that makes use of ATT to discover services and characteris-tics.

3.7 Generic Access Profile (GAP)

The Generic Access Profile (GAP) specifies how devices connect and bond with each other. The GAP also defines how devices can discover other devices [5]. The GAP further defines how broad-casters and observers transfer data without being in connection [5]. GAP is the highest layer at the core BLE stack [4]. Understanding GAP is to understand how devices can find, connect and how the devices can communicate once connected with each other.

3.7.1 The four different roles

The GAP defines four different roles [4]:

1. A Broadcaster device needs only a transmitter, it may have a receiver, but that is not necessary. The broadcaster is used to send advertising events to an observer. One example of an advertising event may be data from a service [5].

(26)

16 3 Theory

2. The observer must have a receiver, but not necessary a trans-mitter. The observer scans for broadcasters and report the in-formation from the broadcasters to an application [5]. Figure 3.6 shows how the broadcaster sends advertising events to the observer.

3. The peripheral device is a device who advertises so the central can initiate a connection. The peripheral is the device who will be the slave once connected. It needs a transmitter and a receiver [5].

4. The central will initiate the connection to the peripheral by a connect request like in 3.5. The central must have a transmit-ter and a receiver. The central will become the mastransmit-ter once connected to the peripheral [5].

One device can have multiple GAP-roles at the same time. For example, a peripheral-device can also be a broadcaster at the same time.

(27)

Figure 3.6:Observer and broadcaster.

3.7.2 Discover device

To discover a device, one must first scan for advertising devices. The scanning device is a central and an advertising device is a pe-ripheral device [6]. The central device transmits a packet to the peripheral device. But every peripheral is not discoverable or able to connect. To solve this problem there are some flags in the pack-ets that tell the central if the device is discoverable and/or able to connect [5].

3.7.3 Establish connection

The user selects a device to connect with. The first step is to cre-ate an initial connection [5], where the central (users device) send a connect request to the peripheral. The connect request-packet con-tains the address and the connection will be done by the address in the transmitted packet in the peripheral [5]. Once connected, the central will get information about the services and characteristics at the peripheral.

3.7.4 Pair and bond

Bluetooth Low Energy has a security manager as part of the GAP. In the security manager there is a series of protocols and algorithms [7] for the security, how security keys are generated and how de-vices exchange their security keys. The security manager is an

(28)

im-18 3 Theory

portant part of the BLE-technology, so peers can communicate se-curely over an encrypted link to trusted devices [7].

There is an initiator device in the security manager. This device is the master. The slave is a responder. The master trigger the begin-ning procedure for pairing or bonding, a so called security request [7]. The security request can be ignored by the slave. It can also be logically issued at the end of the connection by the slave [7].

3.7.4.1 Pairing

For a temporary connection pairing is a good choice. A security encryption key is generated and a secure and encrypted link is ini-tiated. The security key is temporary and will not be stored.

3.7.4.2 Bonding

In long time relationships between two devices there is a better choice to use bonding. The pairing sequence will be followed by generating and exchange of permanent security keys [7]. The secu-rity keys will be stored in a non-volatile memory and create a per-manent bond. This bond will quickly set up a secure link between the two devices. When re-connecting after the bonding procedure is made once, and the keys have been stored on the master and the slave there is a procedure that defines how these keys will be used. This procedure does not require a pairing or bonding procedure again [7].

3.7 describes the bonding procedure [7]:

• Phase 1: All information the devices need to generate tempo-rary keys will be exchanged

• Phase 2: Short Term Key (STK) will be generated at both de-vices, that’s the temporary encryption key.

• Phase 3: When there is a secure encrypted link between the two devices it´s possible to perform bonding. The permanent keys will be generated and can be used for easier pairing in the future.

(29)

(30)

(31)

4

Method

4.1 Introduction

This chapter will describe how the GATT Profiles and custom services is configured, how the code is implemented, how the pro-cessor communicates with the Bluetooth module and how the cur-rent measurements are done.

4.2 Hardware

A circuit board was given from the company, shown in Figure 4.1. In this thesis, only two of the components from the given board are used. The two components that will be used are the processor STM32 and the Bluetooth-module BT121, also marked in Figure 4.1.

(32)

22 4 Method

Figure 4.1:The circuit board.

4.2.1 The Bluetooth-module

The Bluetooth-module given is a BT121 from Bluegiga [1]. The BT121 is a Bluetooth Smart Ready device, which means it is possible to connect Bluetooth-devices and BLE- devices at the same time. It is possible to have 6 Bluetooth-devices connected at the same time. If BLE is used it is possible to connect up to 7 BLE-devices and one Bluetooth-device at the same time.

The BT121 does not need an external processor that controls it in order for it to function. It is possible to embed an application directly on the BT121 because there is an ARM-based processor em-bedded in the BT121 that runs the programming script language BGScript.

The BT121 features several of hardware-interfaces: GPIO, UART, SPI, I2C, ADC and a DAC. In the given hardware platform, the UART is used. Also the firmware at the BT121 will be updated by UART.

4.2.1.1 Programming of BT121

In order to program the BT121 a USB to UART converter was used to be able to upload hex-files from a computer to the BT121. The converter that was used in this project was a FTDI module shown in Figure 4.2.

(33)

4.2 Hardware 23

Figure 4.2: FTDI chip used to communicate with processor.

4.2.2 The processor

The processor that is used on the given hardware is a STM32F105. The STM32F105 is a high performance ARM 32-bit Cortex-M3 RISC core. The maximum CPU speed of the processor is 72 MHz. The STM32F105 has also a 256 Kbyte big flash memory and a 64 Kbyte big SRAM. It has also features as two 12-bit ADCs, two I2Cs, three SPIs, two I2Ss, five USARTs, two CANs, an USB OTG FS, four general-purpose timers and one PWM timer. Figure 4.3 shows a picture of the processor.

(34)

24 4 Method

4.2.3 Packing of sensor data

The STM processor will receive all weather data from connected Windsonds from the radio component on the board. Each packet STM32 receives from the radio is up to 32 bytes long and they in-clude measurements from several sensors. The first bytes in the radio packet describe what measurements the others bytes contain. The radio packet will then in the processor get assigned an identity that tells from which Windsond the data came.

4.3 Implementation

This part of the report will describe how the BLE profile is set up and how the programming of the STM32 processor have been done.

4.3.1 GAP mode

For the implementation of the GAP mode a command is used when starting up BT121. The command that sets up the GAP is namedle_gap_set_mode_{which activates the advertisement of the}

BLE-profile and allows other devices to connect to it.

4.3.2 GATT-profile with characteristics and services

Since BLE was used for the Bluetooth-module in this project a GATT-profile had to be made in order to save and convey data. To decide how this profile should look the first step is to decide how the packing of data that will be transferred with BLE should be done. The next step is to decide how the data transfer will be initi-ated, for example if the application will try to read the sensor data that is on BT121 with a certain time interval.

When these things have been considered then the construction of the profile can be started. In the construction of the GATT profile the usage of standard characteristics and services should be consid-ered if it is possible to use or if custom characteristics and services have to be made. If possible it is preferable to use standard ones since these are published by the Bluetooth SIG which makes them reliable to use and simple to implement.

(35)

4.3 Implementation 25

4.3.2.1 Services

In order to make the GATT-profile as flexible and as energy effi-cient as possible the data that is to be sent over the BLE were sepa-rated into different services. With the reasoning that in case of that a new type of data is to be sent over the BT121 it should be easy to implement a profile for it or if some of the data that is sent at the time is judged to not be necessary it should be easy to remove.

For this project the data that is to be sent over BT121 are dif-ferent kinds of weather measurements and also the battery level of connected windsonds. So what has to be considered is how often these measurements have to be sent to achieve the wanted function-ality. Here it is important that the weather data is sent as often it is updated because the android application makes use of the timing of every received weather data to calculate further things like for example where the windsond will land if its released at a certain moment. For the battery level the timing is not as important since its value most of the time will not change from one reading to the next.

So for this GATT-profile two services were made where the first one is named Battery service which represents the battery level of the respective Windsond. The second service is a Windsond service which hold the sensors measurement values of the respective Wind-sond. The Windsond service is custom made since no standard ser-vice existed that fit the wanted functionality. For the battery level there existed a standard service that was taken directly from the Bluetooth developer’s website.

4.3.2.2 Characteristics

The characteristic that is implemented for the battery service has a value size of one byte and it has the properties of notification and read. One byte is enough for this since the value that it rep-resents is between zero and a hundred percent. Notification and read was necessary since the android application should be notified when the value changes and should then commence to read it.

The characteristics for the Windsond service are two. They both have the same variable value size of maximum 20 bytes and the properties of notification and read. The sensor data packet that is sent from STM32 to BT121 is up to 32 bytes long depending of

(36)

26 4 Method

which sensor data it holds as mentioned in Section 4.2.3 . Since BLE only can operate a read on up 20 bytes at a time in a charac-teristic the packet was divided up into c_windsond_packet_1and c_windsond_packet_2_{. Which represent the first and the second}

half of the 32 byte packet. The windsond packets can be found in Appendix A.

4.3.3 Bondable mode

By default, the BT121 is in nonbondable mode. That means no keys will be exchanged or stored by the device.

There is only one line of code needed to be in bondable mode. That means the device will accept bonding request. If it is possible, the devices will send security keys to each other and store them if it is necessary. As motivated in Section 3.7.4 there is are good reasons to be in bondable mode.

4.3.4 Flow control

It is clear why flow control needs to be implemented. If the trans-mitter is fast and the receiver is slow there will be a problem. If the transmitter sends to many packets in quick succession data will be lost when the buffer is full.

The usage of flow control for BT121 is very straightforward to implement. See [8].

4.3.5 Bluegiga Application Programming Interface

(BGAPI)

BGAPI is a protocol specification. It specifies how to control the BT121-module. One way is to control the BT121 externally with BGLib. Another way is the on chip-solution, BGScript who runs on the integrated ARM-based processor on the BT121.

4.3.5.1 BGAPI imlementation

The decision for how BGAPI should be implemented was de-cided together with SparvEmbedded. The way it got implemented was by BGLib with the reasoning that it would be easier for the company to make changes in the future if they need it. It would be easier for them because they would have most of the BLE code on

(37)

4.3 Implementation 27 the same processor as the rest of the code for the ground station.

4.3.6 Power modes

A big part of why the BT121 is so attractive in a power efficiency point of view is because of its capability to spend a lot of time in low-power or sleep mode. For the BT121 the stack automatically changes the power mode accordingly to the lowest power consum-ing possible that can handle what the device is doconsum-ing at a given moment. The different modes the device can enter are described in Table 4.1. BT121 Operating Mode Description Theoretical power comsumption Active/Idle

Everything on the device is turned on and the CPU is either idle or active.

10 − 20 mA

Power Mode 1 (PM1)

Shallow sleep mode where all clocks and peripherals are running while the processor core is stopped.

4 − 10 mA

Power Mode 2 (PM2)

Deep sleep mode where most clocks and

peripherals are turned off. 50 − 100 µA Table 4.1: The different power modes for BT121

Power mode 1 (PM1) is handled automatically by the device and the performance is not downgraded since all clocks and peripherals are functional during this mode. For power mode 2 (PM2) UART cannot use normal communication since it needs clocks to work so the device can not receive messages over BGAPI from the STM32 processor in this mode. This leads to that BT121 have to be woken up in some way either from an interrupt pin on the device, an in-terrupt from the radio or by a separate wake up command over the UART. When it then gets woken up there is a short amount of time when the internal clocks are stabilizing where the device are unable to receive any data over the UART. The wake up time for PM2 is es-timated in the datasheet to be up to 70 microseconds.

(38)

28 4 Method

The way BT121 is woken up for PM2 is by usage of an inter-rupt triggered by setting a pin on the device in the hardware file to a wakeup pin. The pin will trigger a interrupt when it goes high which set the device to be active until the pin goes low again which allow it to enter PM2 again. Setting the wakeup pin high is done by STM32 every time before it sends something to BT121 and it also have to set it low when it receives a confirmation that its message has successfully arrived.

4.4 Testing and validation

In order to confirm that the communication over BLE worked as intended testing and validation of the system is required. There are several software tools that can be used for testing and validation.

4.4.1 Serial Port Master

Serial Port Master is an application for windows computers. The application has simple purpose and is simple to use. The purpose is to read the computers serial port and display it. To use the program: Choose right device, enter the baud rate and connect. Figure 4.4 shows what Serial Port Master looks like.

The link between the STM32-processor and the computer is UART connected to a FTDI-chip that is connected to the computer via USB. This tool is really good for trouble shooting.

(39)

4.4 Testing and validation 29

Figure 4.4: Serial port master a windows program to read from serial port.

4.4.2 BLE Reader

BLE Reader is an easy to use Android application. Connect to the BLE device and look at the device characteristics, services, read the values and subscribe on notifications. This tool is perfect for verify that the right data has been sent. Figure 4.5 shows available services and characteristics for the Windsond Profile in BLE Reader. Figure 4.6 shows a characteristic who subscribes and get notifica-tions. The notifications are fired by a hardware timer in this test case. It is also possible to read the characteristic manually.

(40)

30 4 Method

Figure 4.5: Services and characteristics in the Windsond pro-file.

Figure 4.6: Notifications in a characteristic fired by a hardware timer.

(41)

4.5 Current measurements 31

4.5 Current measurements

Two alternatives for current measurement were looked at for this thesis. One is a USB Current Meter and the other solution is to use a shunt resistor and measure with an oscilloscope.

4.5.1 USB Current Meter

The easiest but not the most informative alternative is to use a USB Current Meter like for example [9]. It is not possible to see how the current change over time for this method like you would with for example an oscilloscope. Because this method just measure the average current over a set time interval.

4.5.2 Shunt resistor with oscilloscope

A bit more complex than USB Current Meter, but still an easy solution is to use a shunt resistor. The resistor will be as small as possible. The resistor will be connected as in Figure 4.7.

The probes will be connected over the Shunt resistor and mea-sure the voltage. Then it is easy to use Ohm’s law to get the power consumption.

It is possible to see spikes and how the power consumption differ dependent on power mode and if the device is connected or not.

(42)

(43)

5

Results

5.1 Introduction

This chapter contains results from measurements on the circuit for Bluetooth classic and BLE in different power modes. The mea-surements were done as described in Section 4.5.2. This chapter will also present a table which shows power consumption for the different measurements so they can be compared to each other.

Measurements are displayed in voltage and can be converted to current with Ohm’s law where the resistance is 1.5 ohm as a shown in Equation 5.1.

I = U R =

U

1.5 (5.1)

What has to be considered when looking at the values are that the measurements are done over the whole circuit and not only over BT121. So a significant part of the power consumption comes from other components and their consumption is estimated to be about 41 mW.

5.2 Bluetooth classic

The first measurement for Bluetooth classic shows the voltage measured when BT121 is advertising which can be seen in Figure

(44)

34 5 Results

5.1. The advertisement packets can be seen as the high peaks in the figure and the interval is one second in between them.

Figure 5.1:Classic BT is advertising. The scaling is 500 ms per unit on the x-axis and 50 mV per unit on the y-axis.

The second measurement for Bluetooth classic shows the voltage measured when BT121 is connected to another Bluetooth classic de-vice which can be seen in Figure 5.2. The peaks seen in the figure are the radio checking if any data is incoming from other devices or if something is to be from the processor.

When a packet is getting sent over the Bluetooth classic it can be seen that a peak will extend for a longer time so that the radio ensures that the whole packets get send over in one piece.

5.3 Power mode 1

The first measurement for BLE in PM1 shows the voltage mea-sured when BT121 is advertising which can be seen in Figure 5.3. Just like for the Bluetooth classic first measurement the peaks are the radio sending out its advertisement packets.

The second measurement shows the voltage measured when BT121 is connected with BLE to another device and seen in Figure 5.4. What can be seen in the figure is that BT121 is in a shallow sleep mode and the voltage peaks are when the radio are checking if any data is incoming or if something is in queue to be sent. The

(45)

5.3 Power mode 1 35

Figure 5.2: Classic BT is connected and sending on oscillo-scope. The scaling is 1 s per unit on the x-axis and 100 mV per unit on the y-axis.

Figure 5.3: BLE is advertising. The scaling is 2 s per unit on the x-axis and 50 mV per unit on the y-axis.

(46)

36 5 Results

voltage peak from the radio can be seen in Figure 5.5.

Figure 5.4: Connected with BLE on oscilloscope. The scaling is 500 ms per unit on the x-axis and 100 mV per unit on the y-axis.

Figure 5.5: Connection interval message when connected to BLE on oscilloscope. The scaling is 20 us per unit on the x-axis and 100 mV per unit on the y-axis.

The third measurement for PM1 shows the voltage measured when a notification is sent over the BLE. What can be seen in Figure 5.6 is an extended peak from when the radio wakes up to check if any data is to be sent or received. In this case the notification will wait in the radio send queue until it gets handled. When sending the message BT121 have be awake which leads to the extended volt-age peak.

(47)

5.4 Power mode 2 37

Figure 5.6: Message with content on oscilloscope. The scaling is 20 us per unit on the x-axis and 100 mV per unit on the y-axis.

5.4 Power mode 2

The first measurement for the implementation of PM2 showed the voltage measured when the BT121 wakeup pin is high as de-scribed in Section 4.4.6, and the device is advertising. The voltage measured for this case resulted in a voltage of 87 mV = 58 mA.

The second measurement made for PM2 showed the voltage measured for when the BT121 wakeup pin from Section 4.4.6 is low which allows sleep mode for the device. The voltage measured for this case resulted in a voltage of 78 mV = 52 mA.

The third and last measurements that was done for PM2 is seen in Figure 5.7. This figure shows the voltage over the resistor for when BT121 gets woken up for sending a notification with BLE and how it goes back to deep sleep mode after sending the notification. The time BT121 has to be awake to guarantee that the notification is sent as it should depend on when the next time the radio wakes up to check its queue. So in worst case BT121 might have to be awake for up to 50 ms when a notification is being sent.

(48)

38 5 Results

Figure 5.7: Wake up sequence from power mode 2 on oscillo-scope. The scaling is 1 ms per unit on the x-axis and 100 mV per unit on the y-axis.

5.5 Power consumption

The results presented in this section shows the average power consumption of Bluetooth classic, PM1 and PM2 for three different time intervals between notifications sent. The power consumption when BT121 is advertising and for when it is connected is also dis-played in Table 5.1. The three time intervals can be seen in Table 5.2, Table 5.3 and Table 5.4. For PM2 the worst case wake up time of 50 ms as described in Section 5.4 were assumed to not achieve a lower result than the actual power consumption of the circuit.

(49)

5.5 Power consumption 39

BLE Advertisement BLE Connected AdvertisementBT Classic Sends per second [Hz] 5 5 -Connection interval per second [Hz] 1 20 1.2500

Average voltage [V] 0.0810 0.0810 0.0900 Advertisement peak time [s] 0.0600 0.1000 0.0114 Maximum peak voltage [V] 0.2310 0.2310 0.1570 Average peak voltage [V] 0.1560 0.1400 0.1250 Resistor [Ω] 1.5000 1.5000 1.5000

Results

Peak voltage per second [V/s] 0.0045 0.0059 0.0004 Power consumption [W] 0.0487 0.0503 0.0542

Table 5.1: Power consumption for advertisement and con-nected state

Connect and send

BT Classic Power Mode 1 Power Mode 2 Sends per second [Hz] 5 5 5 Connection interval per second [Hz] - 20 20

Results

Table 5.2:Power consumption when sending five times per sec-ond

Connect and send

BT Classic Power Mode 1 Power Mode 2 Sends per second [Hz] 1 1 1 Connection interval per second [Hz] - 20 20

Results

Table 5.3: Power consumption when sendning one time per second

(50)

40 5 Results

Connect and send

BT Classic Power Mode 1 Power Mode 2 Sends per second [Hz] 0.2000 0.2000 0.2000 Connection interval per second [Hz] - 20 20

Results

(51)

6

Discussion

This chapter will discuss the results presented, the method and some societal aspects of the project.

6.1 Results

When looking at the results the most interesting parameters to do an evaluation of is the power consumption of the circuit when the Bluetooth is connected and sending. The reason why it is the most interesting to look at the power consumption when the Blue-tooth is connected and sending is that this is the state where BT121 will be in the majority of the time.

The results presented in Chapter 5 were all achieved by the same measurement method as described in Section 4.5.2. As shown in tables in Section 5.5 the expected result were achieved where the measurements for BLE resulted in a lower power consumption than the measurements of Bluetooth classic. Higher power mode also resulted in a lower power consumption which was expected.

PM2 is as shown in the results the least power consuming op-tion and the reason for this is as described in Secop-tion 4.3.6 because of the deep sleep mode. For the calculations for PM2 the worst case scenario were assumed where BT121 always had to be awake for 50 ms to send a notification. The wake up time of 50 ms when the time interval between notifications were low resulted as expected

(52)

42 6 Discussion

in quite high power consumption since the device spend a relative low time in sleep mode in comparison to its time in wake up mode. What further can be seen is that the gap in power consumption be-tween PM2 and the other alternatives increase with longer intervals between notification as shown in Table 5.2, Table 5.3 and Table 5.4. The achieved results from the measurements was done over the whole circuit and not only over the Bluetooth device. So what has to be considered is that a significant part of the power consumption comes from other components and not from BT121. The power con-sumption of the rest of the circuit is estimated to be about 41 mW. The decrease in power consumption when using BLE PM2 in com-parison to Bluetooth classic can then be seen to be much greater in terms of percent when only taking BT121’s power consumption in consideration, especially when the time interval between notifica-tions gets larger.

6.2 Method

This section will discuss the method and how our experiences can help further studies in the subject.

6.2.1 Test board

An important thing in this thesis was to reduce the power con-sumption when sending data with BLE. Unfortunately, the Blue-tooth module BT121 is not the most optimized for low power con-sumption. For low power consumption, there are better alterna-tives. An idea could have been to do some test cards, maybe with two or three really low power BLE modules and evaluate which is the best choice according to power consumption, price and func-tionality. Examples of BLE modules to test are Bluegiga BLE113 [10] and ST BlueNRG-MS [11].

6.2.2 Current measurements

The use of a shunt resistor is easy. But there could be some error sources with the measurement. One of these error sources could be the resistance accuracy.

For higher precision measurements there are better solutions. An example of a solution with higher precision for current

(53)

mea-6.3 The work in a wider perspective 43 surement is EEVblog Microcurrent. EEVblog Microcurrent is a tool for high precision current measurement. Further description of the EEVblog Microcurrent can be read about on their webpage [12].

6.2.3 Replicability

It should be possible to replicate this project. Every important part is described in the method: How the GATT is configured, how the BGAPI runs, how to measure the current and how to validate that the BLE sends correctly. The source code and XML-files are posted in Appendix A for even higher replicability. The problem is that the hardware is given from the company SparvEmbedded. The circuit diagram of the hardware is not showed in this thesis which can make the replication of the hardware different. But the same conclusions will probably be made how BLE change the power consumption with different power modes and relative to classic BT.

6.3 The work in a wider perspective

The Windsond is used and will be used for weather measure-ments, in the most cases for research on tornadoes.

This thesis will hopefully be a one part in the improvement of the Windsond. The Windsond will help researchers to do better weather measurements. With better weather measurements they can get more, better data about the nature in this world.

6.4 Source criticism

The sources that is used for the technical part are books or well-renowned conferences and publications. The publications and con-ference papers are well-cited sources.

For example, Heydon´s book [5] is a book that is written from one of the developers of Bluetooth Low Energy. It has quite many citations also. It should be trustable.

Gupta’s book [6] is not so well-cited. But it is checked against Heydon’s book in some cases and publications. Gupta’s book is well written and is from our point of view, after some checking against other sources, trustable.

It is reasonable to mainly use well-cited sources because they usually contain the established solution for the problem. Sources

(54)

44 6 Discussion

that are not well-cited and reviewed at conferences, or reviewed in publications, requires more time to verify the correctness of.

Sources like data sheets and reference manuals are directly from the manufacture and only used for the implementation. To use data sheets and reference manuals directly from the manufacture is prob-ably the best source for their technology.

(55)

7

Conclusions

This chapter will present the conclusions from the thesis and also some recommendations for future studies on this subject.

7.1 Conclusions

The purpose of this thesis was to investigate how much the cur-rent consumption could be lowered by using BLE instead of Blue-tooth classic for sending sensor data from a weather station to an an-droid application. The Bluetooth device used in were a BT121 from Bluegiga which supports both Bluetooth classic and BLE. The appli-cation was proven to work by the use of several test programs and measurements was done in order to compare the current consump-tion between Bluetooth classic and BLEs different power modes.

7.1.1 Comparing BLE and Bluetooth classic

The current measurements presented in Section 5.5 show that the BLE as expected have a lower current consumption in compari-son to Bluetooth classic. The reacompari-son for why BLE have a lower over-all current consumption is that BLE is more energy efficient during the time when nothing is waiting to be sent thanks to its efficient usage of sleep mode.

Bluetooth classic on the other hand as shown in the measure-ments had a lower peak current consumption compared to BLE. The

(56)

46 7 Conclusions

higher peak for BLE means that it becomes less efficient to use the more often a notification is sent which also could be seen in the Section 5.5 . In case of a time interval short enough between notifi-cations which was not used in this thesis then it would be seen that BLE at least when using PM2 becomes even more current consum-ing than Bluetooth classic.

7.1.2 Configuring BT121

The parameter that could be configured for BT121 that directly affected the current consumption was mainly the power mode as described in Section 4.3.6. PM1 has higher current consumption compared to PM2 while in sleep mode and while notifying. PM2 on the other hand have longer current peaks while notifying.

The conclusion reached when comparing the two different power modes are that PM2 is more efficient when notifications comes with time interval that is not too short in between them, while PM1 are more efficient when that low time interval is reached which it was not in this thesis.

7.1.3 Configuring GATT profile and packing of data

How the GATT profile and the packing of data should be con-figured in order to have an as low current consumption as possible are a result of the conclusions from Section 7.1.2. In order to have an as low current consumption as possible PM2 is the most opti-mal choice and the time between notifications should be as long as possible.

In order to have to send notifications as seldom as possible while still sending the same amount of sensor data the data packets and their corresponding characteristic value should be as long as possi-ble. The longest possible characteristic value for BLE notification is 20 bytes as mention in Section 4.3.2.2, so for the 32 bytes long sen-sor packets in this thesis they had to split up in two characteristics in order to fulfil the criteria of maximum length of 20 bytes.

7.2 Future work

The future work is to find new ways to reduce the power con-sumption on the ground station. One obvious way is to change the

(57)

7.2 Future work 47 BT121 to another device made for BLE without an integrated ARM processor. The device for only BLE will probably be cheaper and will reduce the power consumption.

One way to reduce the power consumption could be to test to decrease the clock rate of the system. With a lower clock rate it is possible to reduce the power consumption.

One can also investigate if the BT121 has performance enough to do everything that the external ARM processor does today. BT121 has an integrated ARM processor with I/O Pins and support for I2C, UART, SPI and A/D conversion. Only using the BT121 will reduce the price and reduce the power consumption.

(58)

(59)

A

Appendix

A.1 project.xml

<?xml version="1.0" encoding="UTF-8" ?>

<hardware in="hardware.xml" />

<sdp>

</sdp>

(60)

50 A Appendix <!--<scripting>

<image out="BT121_windsond.bin" /> </project>

A.2 did.xml

<ServiceRecord>

(61)

A.3 hardware.xml 51

A.3 hardware.xml

<wakeup_pin enabled="true" port="1" pin="8" />

A.4 spp.xml

<ServiceRecord> <ServiceClassIDList> <ServiceClass uuid128="1101"/> </ServiceClassIDList> <ProtocolDescriptorList> <Protocol> <UUID16 value="0100"/> </Protocol> <Protocol>

(62)

52 A Appendix <UUID16 value="03"/> <UINT8 value="05"/> </Protocol> </ProtocolDescriptorList> <BrowseGroupList> <UUID16 value="1002"/> </BrowseGroupList> <LanguageBaseAttributeIDList> <UINT16 value="656e"/> <UINT16 value="006a"/> <UINT16 value="0100"/> </LanguageBaseAttributeIDList>

<ServiceName text="Bluetooth Serial Port"

language_id="0100"/> <BluetoothProfileDescriptorList> <Profile> <UUID16 value="1101"/> <UINT16 value="0100"/> </Profile> </BluetoothProfileDescriptorList> </ServiceRecord>

A.5 GATT.xml

<?xml version="1.0" encoding="UTF-8" ?> <gatt> <service uuid="1800" >

<description>Generic Access Profile </description>

<properties read="true" const="true"/> <value>Windsond Profile</value>

(63)

A.5 GATT.xml 53

</characteristic>

</characteristic> </service>

<service uuid="180f" advertise="true"

id="c_battery_level"> <description>Battery</description>

</service>

<service uuid="87cd3ecd-ce4a-4be9-8220-eff926a64445"

advertise="true">

<description>Windsond Service</description>  <characteristic

uuid="5e45c714-8dcf-4bd6-aa56-ad478b345f22"

id="c_windsond_packet_1">

<description>Windsond measurements</description> <properties read="true" notify="true"/>

<characteristic

uuid="79a310fe-db6e-4be3-8947-c01f0219e3bf"

id="c_windsond_packet_2">

<description>Windsond measurements</description> <properties read="true" notify="true"/>

(64)

54 A Appendix <value variable_lenght="true" lenght="20">2</value> </characteristic>

</service> </gatt>

(65)

Bibliography

[1] Bluegiga. BT121 Bluetooth Smart Ready Module – Bluegiga.

https://www.bluegiga.com/en-US/products/bt121-bluetooth-smart-ready.

Accessed: 2016-04-21.

[2] Matti Siekkinen, Markus Hiienkari, Jukka K. Nurminen, and Johanna Nieminen. How low energy is bluetooth low energy? comparative measurements with zigbee/802.15.4. In 2012 IEEE Wireless Communications and Networking Conference Workshops (WCNCW), 2012.

[3] Bluetooth. Specification of the Bluetooth System-Covered Core Package version: 4.0. https:

//www.bluetooth.com/specifications/bluetooth-core-specification/archived-specifications.

Accessed: 2016-04-05.

[4] Gomez C. Overview and evaluation of bluetooth low energy. An Emerging Low-Power Wireless Technology,

12(12):232–237, 2012.

[5] R. Heydon. Bluetooth low energy: the developer’s handbook. Upper Saddle River, NJ : Prentice Hall, 2012.

[6] N. C. Gupta. Inside Bluetooth low energy. Boston: Artech House, second edition, 2013.

[7] C. Cufi K. Townsend and R. Davidson. Getting started with Bluetooth Low Energy: Tools and Techniques for Low-Power Networking. O’Reilly Medial, 2014.

[8] J. Rowberg. Using or bypassing flow control with UART communication : Bluegiga Technologies.

https://bluegiga.zendesk.com/entries/

(66)

56 Bibliography

23143152--REFERENCE-Using-or-bypassing-flow-control-with-UART-communication. Accessed:

2016-05-04.

[9] USB Charger Doctor - In-line Voltage and Current Meter.

https://www.adafruit.com/product/1852. Accessed:

2016-11-04.

[10] Bluegiga BLE113 Bluettoth Smart Module.

http://www.silabs.com/products/wireless/ bluetooth/bluetooth-low-energy-modules/ble113-bluetooth-smart-module_{. Accessed:} 2017-04-02. [11] ST BlueNRG-MS. http://www.st.com/en/wireless-connectivity/bluenrg-ms.html_{. Accessed: 2017-04-02.} [12] µCurrent. https://www.eevblog.com/projects/ucurrent/. Accessed: 2016-11-04.