A Remote Patient Monitoring System using Android ... - UPCommons [PDF]

Jun 30, 2014 - monitoring of some parameters for people with some health problems, like elders. This project is included in the prevention health field. 2.3 Objectives of the project. The aims of this project is create a prototype application in the Android operating system, due is popularity, that will allow the patient to take ...

0 downloads 21 Views 5MB Size

Recommend Stories


Android based Remote Monitoring System
Your big opportunity may be right where you are now. Napoleon Hill

Remote Patient Monitoring
We must be willing to let go of the life we have planned, so as to have the life that is waiting for

Mobile Remote Patient Monitoring
Seek knowledge from cradle to the grave. Prophet Muhammad (Peace be upon him)

Harassment Monitoring System Using Android Smartphone
The greatest of richness is the richness of the soul. Prophet Muhammad (Peace be upon him)

Employee Monitoring System Using Android Smartphone
Seek knowledge from cradle to the grave. Prophet Muhammad (Peace be upon him)

Remote Tank Monitoring System
Why complain about yesterday, when you can make a better tomorrow by making the most of today? Anon

Android Based LAN Monitoring System
You have survived, EVERY SINGLE bad day so far. Anonymous

UPCommons
The only limits you see are the ones you impose on yourself. Dr. Wayne Dyer

Remote HealthCare Monitoring System Using Arduino Board over Distributed Ubiquitous
No matter how you feel: Get Up, Dress Up, Show Up, and Never Give Up! Anonymous

Remote Monitoring System using Internet of Things (IoT)
If you want to go quickly, go alone. If you want to go far, go together. African proverb

Idea Transcript


´ rniczo-Hutnicza im. Akademia Go Stanislawa Staszica

A Remote Patient Monitoring System using Android Mobile Devices

Author: ` Alex Cors Bardolet

30th June 2014

Supervisor: Andrzej Glowacz

Contents Contents

3

1 Abstract

7

2 Introduction 9 2.1 Justification of the project . . . . . . . . . . . . . . . . . . . . 9 2.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Objectives of the project . . . . . . . . . . . . . . . . . . . . . 10 3 Proposition 3.1 Actual state of art . . . . . . . . . . . . . . . . 3.1.1 Heart Rate . . . . . . . . . . . . . . . . 3.1.1.1 Optical method . . . . . . . . . 3.1.1.2 Armband . . . . . . . . . . . . 3.1.2 Breath rate . . . . . . . . . . . . . . . . 3.1.2.1 Mechanical method . . . . . . . 3.1.2.2 Variation of thoracic impedance 3.1.2.3 Comparative of methods . . . . 3.1.3 Blood pressure . . . . . . . . . . . . . . 3.1.3.1 Sphygmomanometers . . . . . . 3.1.3.2 Pressure MEMS based solutions 3.1.3.3 Comparative of methods . . . . 3.1.4 Research . . . . . . . . . . . . . . . . . . 3.1.4.1 Wearable sensors . . . . . . . . 3.1.4.2 Inside body . . . . . . . . . . . 3.1.5 Commercial applications in the market . 3.2 Final proposition . . . . . . . . . . . . . . . . . 3.2.1 Best resolution / comfort . . . . . . . . . 3.2.2 Sensors used . . . . . . . . . . . . . . . . 3

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

11 11 11 11 12 12 12 13 14 15 15 15 16 16 16 17 17 18 18 19

4

CONTENTS

4 Hardware implementation 4.1 Description of the system . . . . . 4.1.1 Computing electronic . . . 4.1.2 Firmware of the Arduino . 4.1.3 Accelerometer . . . . . . . 4.1.4 Gyroscope . . . . . . . . . 4.1.5 Bluetooth communication 4.1.6 Power supply . . . . . . . 4.1.6.1 LiPower Shield . 4.1.7 Docking Shield . . . . . . 4.1.8 System assembled . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

5 Sensors 5.1 Breath rate sensor . . . . . . . . . . . . . . . 5.1.1 Introduction . . . . . . . . . . . . . . . 5.1.2 Description of the system . . . . . . . 5.1.3 Description of the signal . . . . . . . . 5.1.3.1 Orientation of the sensor . . . 5.1.3.2 Signal from the accelerometer 5.1.4 FIR Filtered . . . . . . . . . . . . . . . 5.1.4.1 Conclusions . . . . . . . . . . 5.1.5 IIR Filtered . . . . . . . . . . . . . . . 5.1.5.1 Test in the Android device . . 5.1.5.2 Conclusions . . . . . . . . . . 5.1.6 Gyroscope . . . . . . . . . . . . . . . . 5.1.6.1 Description of the signal . . . 5.1.6.2 Band-pass filter . . . . . . . . 5.1.6.3 Conclusion . . . . . . . . . . 5.1.7 Noise cancellation . . . . . . . . . . . . 5.1.8 Algorithm validator . . . . . . . . . . . 5.1.9 Algorithm detector of peaks . . . . . . 5.2 Thermometer . . . . . . . . . . . . . . . . . . 5.2.1 Introduction . . . . . . . . . . . . . . . 5.2.2 Description of the system . . . . . . . 6 Server part 6.1 Introduction . . . . . . . . 6.2 Description of the system . 6.2.1 Database . . . . . 6.2.2 Software used . . . 6.2.3 Hardware used . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . .

21 21 22 23 25 25 26 27 28 29 30

. . . . . . . . . . . . . . . . . . . . .

33 33 33 33 35 35 36 37 39 39 40 42 42 43 44 45 46 47 48 48 48 49

. . . . .

53 53 53 53 55 55

CONTENTS

5

6.2.4

Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7 Android application 57 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2 Application flow diagram . . . . . . . . . . . . . . . . . . . . . 58 7.3 Captures of the application . . . . . . . . . . . . . . . . . . . 58 8 Conclusion

61

Bibliography

63

6

CONTENTS

Chapter 1 Abstract The aim of this thesis is to validate the use of mobile applications for taking care of the health of patients in a preventive way. First of all, the results of a research of the actual actual state of art are presented. With this results, a proposition is done. This preposition includes the acquisition and realization of some sensors, the realization of a mobile application and the programming of a server application. The sensors used includes a ex profeso breath rate sensor and a commercial thermistor used for human temperature measures. All this sensors will be connected trough a device that handles the power and communication. After that, an Android application have been done to control this device and show the results of the measures. The value of the measures are sent to a remote server in order to store information. At the end, some indications are pointed about how this project could be further developed after discussing the prototype with several professionals of the medicine.

7

8

CHAPTER 1. ABSTRACT

Chapter 2 Introduction 2.1

Justification of the project

Nowadays and every day more, health is a matter of concern. With the rise of medicine and technology, many injures can be detected and controlled. Those checks usually involve big expensive dedicated machinery and visits to the hospital, even if is only for routine checking. At the same time, the use of smartphones is quite generalized in the society, and it will increase meanwhile the prices of the technology is falling. Even if the smartphone has big computational capabilities, internet connection and several peripheral connection capabilities, it is not massively used in the personal medic field, though is been used in the personal fitness equipment field. It would be a very convenient solution to merge as many prevention medic functions as possible into the smartphones to make this checking as popular as possible.

2.2

Background

Personal health technologies are subject of many research now. There are, therefore, quite a lot of papers and scientific research of methods for measuring different parameters of the human health, such as breath rate, temperature, blood pressure, etc. All this papers have different approaches for making this measures more easily, comfortable for the patient and lowering the cost as much as possible. 9

10

CHAPTER 2. INTRODUCTION

Even if some of this technology it is been used for recreational sport purposes, it is not been used massively in real medical application for reasons as high cost and high discomfort of the reading systems. However, it cannot be found any project that integrates some of those sensors or measure techniques in one usable practical and relatively inexpensive solution for the patients. Some of this first prototypes uses very expensive dedicated hardware in order to measure only one parameter of the human health. With that said, is not the aim of the project to substitute the need of a real medic. This application could help to detect abnormal reading, that could mean some future health complications. Can also be used for constant monitoring of some parameters for people with some health problems, like elders. This project is included in the prevention health field.

2.3

Objectives of the project

The aims of this project is create a prototype application in the Android operating system, due is popularity, that will allow the patient to take reading of several sensors in order to have an insight of his health. This application will also allow saving the data into a remote server for further medical analysis of the data taken. Using this same principle of making this system as much easy to access for the people, some sensor will be developed.

Chapter 3 Proposition In order to do a project proposition, the sensors and actual technology in the market have to be analyzed. After acquire awareness of the actual possibilities of the sensors and also the actual mobile applications, the main features of the project can be setted.

3.1

Actual state of art

This section contains a big picture of the technology that is used nowadays. That includes sensors that are available for the general public, applications for smartphones, etc.

3.1.1

Heart Rate

3.1.1.1

Optical method

There is a quite new way of measuring the heart rate of a subject using the on-board camera that all smartphones have. The subject has to put gently the fingertip of the index finger in the camera, and wait for several seconds (around 10). The program takes photos of the finger, so the measurement must be done in a well illuminated place. With his photos, the program can detect the heart rate by counting how many pulsations there are in the veins of the fingertip counting how many dilatations have been in a given amount of time. Using the same principle that it has been described before, there are some devices in the market, very compact, that are placed at the finger tips. A led illuminates the finger, and with the camera placed in the other side, dilatations can be detected. The usage is simple; the device is connected to 11

12

CHAPTER 3. PROPOSITION

the smartphone with a wire (USB or 3.5 mm jack) or wireless (Bluetooth) and the program in the smartphone does all the calculations and displaying. Most of this devices also incorporates an oximeter in the same device (SpO2). 3.1.1.2

Armband

There are also dedicated instruments made to measure the heart rate. Some of them can also measure blood pressure. This instruments are very similar to a sphygmomanometer, which is compose for a inflatable armband with a little monitor that displays the measurement. The market for this devices are the personal training and instruments for taking care of old people. Apart of the display, there’s the possibility (in some of the top range models) of Bluetooth connectivity.

3.1.2

Breath rate

There are several methods for measuring the breath rate of a patient, with different approaches and precision rates. 3.1.2.1

Mechanical method

The first method is reading the mechanical movement of the lambs expanding and contracting. This movement can be read using and accelerometer, a gyroscope or both. A sinusoidal like signal is received from the sensor. The breath rate can be calculated by counting the maximums or the minimums of this signal in a period of time. There are different approaches using this method; some Android applications can measure the breath rate of a subject by using the internal accelerometers that almost every smartphone has. With the subject laying face up in a bed, the smartphone is placed on the chest. The application start to monitoring the movements that the accelerometer sensor reads, and by doing some filtering the breath rate signal is isolated from another signals. Another approach using accelerometers is placing a dedicated hardware attached in the chest of the patient on some tight clothes. It uses the same principle that the last method, but with this approach it can be used when the patient is doing a wither range of activities. There is no need for the patient to be laying face up. Also, because the accelerometers of the smartphones does not have a very good performance, with a dedicated accelerometer or gyroscope, a better signal can be achieved and further analysis can be done.

3.1. ACTUAL STATE OF ART

13

The communication between the sensor and the mobile phone can be done by wire or by some wireless communication, like Bluetooth.

3.1.2.2

Variation of thoracic impedance

The second method is using the thoracic body impedance to measure respiration. Some electrodes has to be placed in the chest of the patient. The breath rate can be recorded by the fluctuations of the thoracic impedance while the patient is breathing.

The thoracic impedance model can be described as the sum of two terms.

Ztotal = Zk + ∆R

(3.1)

The first term of the sum is quite constant in each patient, and it is approximately 500Ω. The other one, the term that fluctuates with the breath, have a variation between 0.1Ω and 1Ω.

The variation of the thoracic impedance while the patient is breathing it is caused for two main factors: 1. During inspiration, there is an increase in the gas volume of the chest in relation of the fluid volume; this increase causes conductivity to decrease, so the impedance increases. 2. Also during inspiration, the length of the conductance paths increases because of the expansion.

Both factors cause the total impedance to increase. Using the circuit in the figure 3.1, that impedance variation can be measured.

14

CHAPTER 3. PROPOSITION

Figure 3.1: Impedance variation detector circuit

3.1.2.3

Comparative of methods

In the next table can be seen a comparative between the different breath rate measure techniques commented before.

Method Mechanical method (Inboard accelerometer) Mechanical method (External Accelerometer) Impedance method

Comparative of methods Advantages Disadvantages * No external hardware needed

* More resolution * More usable, in different situations

* The patient has to lay face up * Alteration of the results * Some external hardware is needed

* Several interferences to * Electrodes attached to deal with the patient * Most difficult to implement

Table 3.1: Comparative of methods in breath rate measuring

3.1. ACTUAL STATE OF ART

3.1.3

15

Blood pressure

Meanwhile the measurement of the breath rate and the heart rate can take advantage of some in-board hardware already present in most of the smartphones, blood pressure needs specialized instrumentation. There are several options: 3.1.3.1

Sphygmomanometers

The sphygmomanometers is the regular instrument that is used in hospital to measure the blood pressure. The basic set up is an inflatable circular peace of fabric that is placed generally around the arm (it can also be done around the wrist). When the fabric is fully inflated and therefore there is some blood constriction in that area, little variations of air displacement can be sensed due the pressure done by the blood trying to flow in he constricted vein. There are some versions of sphygmomanometers that are portable and allows wireless communication with the smartphone. Some of them need the smartphone in order to display the information, because there is no any display inboard. 3.1.3.2

Pressure MEMS based solutions

Another approach to measure blood pressure is using pressure sensors. The sensors used in blood pressure are MEMS based solutions. MEMS (MicroElectro-Mechanical Systems) allow to have very big sensibility in a very small chip, and a reasonable prices, so this kind of devices are quite popular due its price. There are another advantages, as the lightness of the sensor or the compactness. MEMS pressure sensors works placing some piezoresistors in a diaphragm. This piezoresistors have the right orientation and they are forming a bridge in order to maximize the sensibility. When the diaphragm is pressed, the piezoresistors change their resistance value. Blood pressure readings can be done reading the variation of the total resistance of the bridge. This kind of sensors are usually enclosured in finger tips devices in order to keep the sensor and the finger without any relative movement and get better readings. The connectivity with the smartphone can be done by wire (USB) or wireless (Bluetooth).

16

CHAPTER 3. PROPOSITION

3.1.3.3

Comparative of methods

In the next table can be seen a comparative between the different blood pressure measure techniques commented before.

Method

Comparative of methods Advantages Disadvantages

Sphygmomanometers * Good resolution

* Big * Expensive solution

* Cheapest solution Pressure MEMS

* More portable and * Not good resolution compact

Table 3.2: Comparative of methods in blood pressure measuring

3.1.4

Research

Because health is a very important topic, and people are becoming more aware of taking care of his own health, there is a lot of research being done nowadays. Some of the today’s prototypes can be in the market soon and they could be interesting for this project. 3.1.4.1

Wearable sensors

One of the most inconvenient things about monitoring the health is using specialized devices in order to monitor parameters of the patient’s health. Even when they are quite light and convenient to connect with the smartphone (wireless), it would be very interesting if there would be no need of external hardware. It is not in the market yet, but exists a solution that save many sensors to the patient. It is a shirt that fits tight to the patient, and using sensors present in the same shirt, it can monitors several parameters. Some of them are heart rate, breath rate, activity, calories, movement, etc. The communication with the smartphone is wireless.

3.1. ACTUAL STATE OF ART

17

The advantages are obvious; there is no need of carrying any external device, and because all the sensors are inside the clothes, the readings are better and the patient does not have the discomfort of having more heavy instruments on it.

3.1.4.2

Inside body

Another way of suppressing the need of having external hardware is putting sensors inside patient’s body. Using MEMS technology, it is possible to manufacture small enough sensors to be putted inside a human body. The actual applications are CGM (Continuous Glucose Monitoring) sensors for diabetic patients, but the same approach can be used to monitor different components in the blood stream and detect parameters for other disease.

This system offers a direct way to have readings from the patient without the need of any external hardware except the same smartphone. The communication with the sensor and the smartphone is done by Bluetooth. The sensor gets the energy inductively from the exterior when it has to be read.

The biggest drawback of this kind of sensors it the durability. Most of them can only last for several weeks, maybe a month, even with a steel jacket. Silicon ones can only last 24 hours. There is a lot of research being done in order to improve durability and lower the prices.

3.1.5

Commercial applications in the market

There are several applications available for the Android OS, and all are focused in only one function. Most of them are free to download and use, but have some premium features as remote recording of the measures taken. For the heart rate, ”Instant heart”, ”Heart rate”. Both uses the measuring method with the camera. The first one works well, the second one no. For the breath measurement, ”Cardio Respiratory Monitor Free”. It doesn’t work, no with me. For the Blood pressure, there is no applications that measures that because there’s no inboard sensor that can be used. They are only for recording and making graphs.

18

CHAPTER 3. PROPOSITION

3.2

Final proposition

After analyze the state of art to the health care technology, a proposition for the project can be done.

3.2.1

Best resolution / comfort

Figure 3.2: Proposition

Different configuration of connection with the smartphone and the sensors could be used for the project. The configuration chose use Bluetooth as possible because is the most comfortable for the patient.

Advantages • • Drawbacks • • •

Comfortable for the patient (wireless connection when possible) Dedicated hardware means better resolution Expensive Hard to manage simultaneous Bluetooth connections Bluetooth is a battery drainer resource (smartphone and external sensors)

3.2. FINAL PROPOSITION

3.2.2

19

Sensors used

Initially, it has been planed to use the three sensors in the project, a breath rate sensor, a blood pressure sensor and a heart rate sensor, as it can be seen in the past propositions of the project. The idea was to gather quite a lot of important data from the patients. After the proposition, when it was time to buy the sensors or evaluate the possibility of building the sensors, we faced the problem of finding real usable commercial solutions. Most of the sensors that were found had really expensive prices and was impossible to use them without using the software solution provided by the manufacturer, so were no usable in the application created in this project. Only one sensor was found with a theoretically open API (the set of software instructions that allow to control and use the sensor), the Wireless Blood Pressure Monitor form the company Withings, but the lack of support and the price desist to use it in the project. Due this situation, it was decided to continue with the only sensor that can be manufactured with relatively expectable success, the breath rate sensor. In the project, though, can be seen options that would allow the incorporation of more sensors. Using even only one sensor allow to experiment with the data analysis in the Android platform and to create the whole Android application and server scripts and validate the whole concept.

20

CHAPTER 3. PROPOSITION

Chapter 4 Hardware implementation 4.1

Description of the system

In order of having different measures of the human body different sensors are needed, but some background hardware is needed as well, the hardware that process the information, provides energy, etc. In this chapter is going to be described this basic hardware and the sensors, though the sensors will be analyzed in further chapters.

The prototype includes functionalities such as wireless communication though Bluetooth, battery, digital processing, etc.

At the first stages of the prototype development, the whole system was directly attached into the chest of the patient, connected with the sensor with only a small cable. That was causing a problem in the readings, especially in the walking ones. Because the whole system has a noticeable weight compared with the sensor, having it hanging in the clothes of the patient was introducing a big amounts of noise produced for the inertia of the system moving. That problem was fixed making the wire longer and having the system into the patient’s pocket, for example.

The next diagram shows the different parts of the whole system and how are they connected. 21

22

CHAPTER 4. HARDWARE IMPLEMENTATION

Figure 4.1: Blocks of the different hardware and its connections

4.1.1

Computing electronic

Electronically, the system created is based in the electronic board Arduino Leonardo. This board is a microsystem itself. It includes some convenient functionalities as a CPU ATmega 324u (16 Mhz) with I2C connection (communication with accelerometer and battery level controller), serial communication (communication directly with the smartphone or indirectly using a serial Bluetooth module) and voltage regulators inboard. The ATmega 324u includes, at the same time, RAM and flash memory in order of storing the program.

The programming of the board is done using the Arduino programming software, which is open source and it is available for free [6]. The programming language used is Processing, which is a variant of C. The Arduino software includes the Processing compiler and the programming USB interface to load the program into the Arduino board.

The accelerometer needs a tension of 3.3V. The Arduino board also includes a lineal regulator that converts from 5 to 3.3 volts.

4.1. DESCRIPTION OF THE SYSTEM

23

Figure 4.2: Arduino Duemilanove

Finally, Arduino also counts with a huge community because is the most widely used amateur electronic board. Also in all the Arduino family is using the same connectors which creates a de facto standard. All together makes possible that many electronic supplies are producing a high number of expansion boards (called shields) that are pin to pin compatible. Actually, most of them are stackable in top of the basic Arduino board, making possible to use several shields at the same time. That allows very fast prototyping and quite cheap components.

4.1.2

Firmware of the Arduino

The Arduino, in order of execute the desired function, has to be programmed. Because the Arduino is in the hardware set up, the programming of the Arduino will be commented in this section, letting the software section comment the Android part, more high level. The firmware of Arduino has to perform several tasks: • Listen of the petition coming from the bluetooth module (reading petition). • Read the accelerometer through I2C. • Send back the value through the bluetooth module again. • Check the value of the battery through I2C. • Write the value of the battery level in the LEDs on the Docking Shield.

24

CHAPTER 4. HARDWARE IMPLEMENTATION

The board Arduino Duemilanove implements the I2C serial communication protocol in the analogic input 4 and 5, being A4 (SDA) and A5 (SCL). To control the I2C the open source Wire library is used. This library have all the functions needed to initialize communications, read and write from the devices, etc. It uses the timer 0. To control the accelerometer and the gyroscope another library is used, provided by the manufacturer of both sensors, Pololu, the L3G library [7]. It includes all the directions of the I2C port for bot accelerometer and gyroscope, and its configuration registers and the magnetometer and its configuration value, even if they are not used in this project. However, the fuel gauge of the LiPo battery has not operation library, so manual I2C communication has to be done in this case. The reading of the battery level value is done every around 4.2 seconds, which is the maximum value that allow the ATMega 328 timer with only register configuration. This time is enough for having a good monitoring of the battery and very low CPU demanding, barely noticeable. The timer 1 is used for this purpose because the timer 0 is used in the I2C communication protocol. Also, the timer 1 can achieve bigger value, due the comparative value is in a 16 bits register instead of a 8 bits register like it is in he timer 0. The lecture of the accelerometer is done under petition from the Bluetooth module. The Bluetooth module is connected though serial, so the Arduino is listening it until it gets a petition. Then the Arduino reads the accelerometer value, codifies the values of the three axis into a single string, and it writes it into the serial again. The Bluetooth module, which is bidirectional, will send the information of the lecture back to the smartphone.

4.1. DESCRIPTION OF THE SYSTEM

4.1.3

25

Accelerometer

The accelerometer is included in the board LSM303DLHC made by Pololu, which includes an accelerometer 3D, compass 3D (magnetometer), voltage regulation and I2C compatibility with TTL levels (0-5V, which are the levels that Arduino uses).

Figure 4.3: Module LSM303DLHC with the pinout

Some of the relevant specifications of the accelerometer are: • Adjustable scale: ±2g, ± 4g, ± 8g, ± 16g • Maximum rating of samples: 5376 Hz • Resolution: 16 bits

4.1.4

Gyroscope

This component has been added during the development of the project. In the begging, it was not planned to use one gyroscope, but after having some results the usage of a gyroscope was contemplated for improving some of the readings. This gyroscope is included in the board L3GD20 made by Pololu, which includes, as in the accelerometer, all the voltage regulation components and I2C compatibility with TTL levels, apart of the 3D gyroscope itself. Some of the relevant specifications of the gyroscope are:

26

CHAPTER 4. HARDWARE IMPLEMENTATION • Configurable sensitivity range: ±250◦ /s, ± 500◦ /s, ± 2000◦ /s • Inboard selectable Low-Pass, High-Pass or Band-Pass filters • Resolution: 16 bits

Figure 4.4: Module L3GD20 with the pinout

4.1.5

Bluetooth communication

In order to communicate with the circuit, a bluetooth module is used. In concrete, the HC-06 bluetooth slave and master module. The interface is by serial port, and it implements all the bluetooth protocol. Is enough for the Arduino to read and write from its serial for transmit through bluetooth.

Figure 4.5: Module HC-06

4.1. DESCRIPTION OF THE SYSTEM

27

The board also includes all the power requirements of module. It can be powered with 3.3V, which the Arduino board is already producing, and because is already included in the HC-06 board, no additional lever shifter is required to convert it into the 1.8V that the module is using internally.

4.1.6

Power supply

The power requirements of the breath rate sensor can be satisfied using three different methods; 9V battery, USB connection or LiPo battery through Arduino LiPower shield.

The first way of powering the circuit and the more simple is by connecting a 9V battery in the power connector of the Arduino board. Because of the power requirements exposed in the last table, the standard capacity of the commercial alkaline batteries (565 mAh) and the fact that the Arduino board is using a linear regulator for adapting 9V to 5V (so is dissipating around 45% of the energy in heat) makes that way not the best solution, but is the easiest to implement and the lighter.

Powering the circuit by USB is possible, but is not very usable due the fact that a wire is needed to provide charge to the Arduino from the power supply. That limits the use of this method when there’s no other chance of powering the sensor and the patient is lying or sitting.

The last way is the best technological solution. It uses an already designed shield for Arduino that manages the power conversion from a LiPo battery to 5V required to power the Arduino. This shield also manages the charging process of the battery using a mini-USB connector. The conversion of the energy is done efficiently because a step-up and step-down circuit is used (conversion efficiency around 90%). Also, the available soldering paths in the shield opens the possibility of attaching the battery in the board itself, making that option very convenient.

28 4.1.6.1

CHAPTER 4. HARDWARE IMPLEMENTATION LiPower Shield

Figure 4.6: LiPower shield with indicated connectors

The LiPower Shield is a convenient shield (extension hardware-compatible with the regular Arduino layout) that allow to control, use and charge a LiPo Battery with all the tension converters included. It has been designed and are sell by Sparkfun. This shield, thought, comes with some code requirements. The most important one is that the shield allow the battery drain passed the recovery point. The LiPo technology in batteries has one important characteristic, and it is that the battery cannot be totally flat. If that happens, when the battery is charged again it would explode or set on fire. That is why is important to control that with the code because the shield is not taking care of it. Another thing to take care in the shield is that it comes with a limitation resistor that limits the maximum charging intensity to 100 mA. Due that the battery used is 2000mAh, it would take around 20 hours to completely charge it. The shield allows to change this resistor value to increase the maximum charging value to 500 mA, which is a significant increment. A resistor has to be placed into the R10 spot with a value of 2,5K. A value of 2,2 or 2,7K can be used instead due they are normalized values in the E12 standardization scale.

4.1. DESCRIPTION OF THE SYSTEM

4.1.7

29

Docking Shield

Another shield has been included in the system, the docking shield. This shield is made ex profeso, and tries to solve the problem of create convenient connectors for all the separate elements of the system. The elements to connect are the Arduino with the LiPower shield itself, the Bluetooth module and the accelerometer. The connectors have to be supportive (the whole system is used attached in a patient, so is moving all the time) but can’t be soldered because during the prototyping is convenient to plug and unplug the different elements.

Figure 4.7: Docking shield (front in the left, back in the right)

This shield is done using a perfboard with some Arduino compatible connectors. It includes also plugs for the bluetooth (4 pin plug) and the accelerometer (4 pins plug). The shield also connects the Arduino serial, the 3,3V rail and the ground with the bluetooth module and the accelerometer with the I2C port, the 5V rail and the ground. Finally, only for debugging purposes and to check the battery level, this shield includes 3 3mm LEDS (green, yellow and red) that show the level of charge of the battery. They are all connected to ground with a jumper, which can be connected when the lever of charge wants to be measured. That avoids the battery to be continuously drained through the LEDS. The LEDS are controlled with the Arduino through three digital outputs.

30

CHAPTER 4. HARDWARE IMPLEMENTATION

This is the circuit of the Docking shield:

Figure 4.8: Schematic of the Docking shield

4.1.8

System assembled

In the next figures can be seen the whole system assembled, with all the sensors and modules connected and all the shields stacked.

Figure 4.9: Module L3GD20 and LSM303DLHC soldered with paralel axis orientation. They are connected with the system with a half meter cable.

4.1. DESCRIPTION OF THE SYSTEM

Figure 4.10: Picture of the system fully assembled

Figure 4.11: Picture of the system fully assembled

31

32

CHAPTER 4. HARDWARE IMPLEMENTATION

Chapter 5 Sensors 5.1 5.1.1

Breath rate sensor Introduction

An ex profeso breath rate sensor has been done in this project because all the commercial sensors that had been found were too big (so were uncomfortable for the patient), too expensive or they had mobility problems. The sensor has been designed to be quite inexpensive and as comfortable as it was possible. Using several papers published for experts (bibliography [1], [2], [3], [4] i [5],) the sensor will be implemented using an accelerometer of 3 degrees of freedom attached in the chest of the patient. The data resulting would be filtered by the smartphone. The connection can be done by serial or by Bluetooth.

5.1.2

Description of the system

The board described below is a prototype, so some components should chance in case of commercial releasing. The system designed have to fulfils the next goals: • Take in minimum 50 samples per second (it would be better if it can provide even more samples) • Be as lightweight as possible • Be as cheap as possible • As is a portable device, be as low-power as it can be. 33

34

CHAPTER 5. SENSORS

With the description of the hardware a reading of data can be done from the accelerometer for the smartphone, but this data needs filtering. This filtering is done in the smartphone due its computational capabilities.

The nature of the noise depends on the activity that the patient is realizing in the moment of the reading. The aim of this filter is to be able to read the signal of the breath rate sensor during long periods of time, doing normal bases activities, such as sitting, laying or walking. Other activities would require of better hardware to keep the sensor attached in the chest of the patient, as intensive sport.

Average breath rate Activity Per minute Sitting 12 / 20 Walking 15 / 22 Normal sport (not professional) 35 / 45 Endurance sport (professional) 60 / 70

[Hz] 0.2 / 0.33 0.25 / 0.37 0.58 / 0.75 1 / 1.17

Table 5.1: Average breath rate in different daily activities

In the last table it can be seen some of the breath rate frequencies that can be expected depending on the physical activity that the patient is doing. Due that the target of the project is not a sport application, only frequencies between sitting until walking will be taken in consideration. Also, due the nature of the prototype, more massive than a finish commercial product, the inertia being held in the dress of the patient during some intensive physical exercise can cause discomfort to the patient and complicate the readings if the sensor.

Different techniques can be applied for filtering the signal. During this project, three different implementations had been tested, FIR filtered, IIR filtered and Adaptive filter with least mean square approximation (LMS). All the tests had been done with Octave software, and the sample signals are actual measures.

5.1. BREATH RATE SENSOR

5.1.3

35

Description of the signal

The signal read from the breath rate sensor is full of noise that needs to be filtered in order to use the information. The accelerometer sensor, due its construction, have intrinsically a lot of noise associated in its readings. Also, the noise depends in function of the activity that the patient is doing. Because the accelerometer reads essentially the movement of the patient (actually increments of movement), all the other noises that are not normal breath movements, like walking or running will be also reflected in the measured signal. Even variations of the orientation of the patient will alter the measure (if the patient is lying or standing). 5.1.3.1

Orientation of the sensor

Figure 5.1: Orientation of the axis respect the chest of the patient.

The sensor is orientated like is shown in the last image; the X axis is the one that measures the oscillation of the chest during the respiration. The other 2 axis might still read some of the signal, because the displacement of the chest is not completely perpendicular at the body, but only in the X axis most of the signal can be read. The best situation in the chest is in the middle of one of the breast, in the case of the male. This is where it is been found to be the biggest amplitude

36

CHAPTER 5. SENSORS

of signal, empirically. If the patient is a woman, the best place is in between of the breasts, but case has not been proved with this system. 5.1.3.2

Signal from the accelerometer

Figure 5.2: Lying signal.

Figure 5.3: Sitting signal.

5.1. BREATH RATE SENSOR

37

Figure 5.4: Walking signal.

In the last graph, in the left it can be seen the signal from the three axis of the accelerometer, and in the right it can be seen the frequential composition of the signal x (the one with more breath rate signal consistently through the different activities). As it can been seen in the graph in the lying and sitting signals (figures 5.2 and 5.3), the signal can be spotted even without filtering and there is a clear peak of energy in the frequential analysis. In the case of walking (figure 5.4), the breath rate signal cannot be seen even in the frequential analysis, because is obfuscated for the walking noises (it should be around 0.5 Hz).

5.1.4

FIR Filtered

The first implementation taken into consideration for filtering the signal coming from the accelerometer is a low-pass filter. It has been seen that there is not a lot of lower frequencies than the breath rate one, but there is much important ones, especially in the walking signal. It will be implemented in a FIR filter because is the easiest to implement and test. Also, if that would not be a convenient implementation, the work done working in this one can be used in the IIR and Adaptive. One of the main points of this kind of filters is that is always going to be stable. In the other hand, one of the main faults of this kind of filters is that

38

CHAPTER 5. SENSORS

it might take a lot of resources, depending of the order of the filter required. To achieve the results that can be seen in the graph 5.5 on page 38, a 500 order has been needed, which is a lot of computer power in a portable device.

Another problem of using such a big order in the filter, is that the establishment time is a significant part of the signal, and would not recommended to use the establishment part of the filtered output for peak detecting. In this case, with a Fs of 50 Hz and 20 seconds of measure, this measure has 1000 samples, and because the order is 500, half of the filtered measure is not recommended to be used. With his order, 10 extra seconds are needed in order of having a 60 seconds measure with the register of the filter full of values, so 70 seconds are needed to do a complete minute measure.

Figure 5.5: Frequency response of the filter FIR.

5.1. BREATH RATE SENSOR 5.1.4.1

39

Conclusions

The main conclusion after using a FIR filter is that a huge amount of operation have to be done using this high order in the filter, making the CPU overwork and adding long establishment delays.

5.1.5

IIR Filtered

An IIR implementation was considered after seen the huge amount of resources in computational terms that a FIR was using. That, in a mobile device, is a problem due its not that high computational resources if it is considered that all the mathematical operations run in very high level (Java) without any direct hardware support. Related with the high usage of CPU and RAM memory, there is also an issue with the power consumption. The program could be running for prolonged periods of time, therefore it should be as much battery saver as possible.

The configuration of this filter, as it can be seen in the figure 5.6 on page 40, has been made setting the band pass ending at 0,75 Hz, and the band suppress starting at 2 Hz, with an attenuation band of 60 dB.

In the Android class used to implement the IIR filter, the value of the coefficients calculated with Octave (A and B coefficients) have been use with the maximum of decimals to avoid instability. The elliptic method for calculating the coefficients has been used due is a method that minimize the number of the order of the filter, which in this application is important as it has been explained.

Because the elliptic method has been used, the results of the graph 5.6 have been achieved using only a filter of order 4. Although the CPU usage of analysing a IIR filter iteration is bigger that a FIR one (the second one does not have output feedback to process), the number of the order is 2 order of magnitude less in the IIR, so save a lot of CPU usage, battery and do not introduce noticeable establishment times.

40

CHAPTER 5. SENSORS

Figure 5.6: Frequency response of the filter IIR.

5.1.5.1

Test in the Android device

A Java implementation of this filter has been tested in the Android device and included into the Android application for real testing, with a patient. Even with using only a 4 order in the filter and measures of 20 seconds, the processing take several seconds in a medium range terminal (hardware details are in the Android application section).

The filter has been tested in the patient while the patient was developing different activities, like lying in a bed, being sited or walking. The results in the 2 firsts cases (lying and sitting) have been good, having a good signal from the breath rate sensor, where the signal of the breath rate can be easily seen. In the walking, though, the results were erratic. In some measures the signal was good enough to filter the breath rate, but sometimes it wasn’t.

5.1. BREATH RATE SENSOR

Figure 5.7: Example of a reasonable clear walking signal

Figure 5.8: Example of a not very clear walking signal

41

42

CHAPTER 5. SENSORS

As it can be seen in the graph 5.7 but specially the graph 5.8, there is noise around the breath rate frequency (approximately 0.4 - 0.5 Hz, according the table 5.1 at page 34). This frequencies can not be filtered because the respiration can be contained in this frequencies if the patient would have been walking during time enough.

5.1.5.2

Conclusions

Thought the value of the breath rate is guaranteed when the patient is sitting or lying, it cannot be guaranteed when the patient is walking. The signal obtain after the filtering is good enough most of the times, but depends hugely on how the patient is walking (position of the back), existence of steep slopes (like stairs) and another dynamical factors. The signal is quite good in a perfectly smooth ground with the patient walking in a firm manner, but not otherwise.

Another factor might a static factor, like the position in the chest where the sensor is attached or the procedure of attachment.

5.1.6

Gyroscope

Due the results from the accelerometer during walking, it has been decided to use another sensor, a gyroscope.

The gyroscope is a sensor that allows to measure angular movements. Is similar to the accelerometer because they both measure movements, so both signal will be a priori easy to merge and combine to achieve a single signal. The use of the gyroscope was discarded in pro of the accelerometer because is easier to work with the accelerometer. The magnitudes in the gyroscope are rotational, so some weighting is needed, which is not needed in the accelerometer signal. Also, gyroscopes, like accelerometers, tend to be noisy, because both of them work similarly, but gyroscope are more likely to have more noise that the accelerometers.

The goal is to use the gyroscope signal and try to compensate as much noise as is possible into the accelerometer signal.

5.1. BREATH RATE SENSOR 5.1.6.1

Description of the signal

Figure 5.9: Caption of the gyroscope lying

Figure 5.10: Caption of the gyroscope sitting

43

44

CHAPTER 5. SENSORS

Figure 5.11: Caption of the gyroscope walking

The results observed coming from the gyroscope (graphs 5.9, 5.10 and 5.11) are quite promising. As with the accelerometer, the signals coming from the breath rate in the lying and sitting situations are very clear. In this case, although, there is quite a lot of energy in between 0.3 and 0.5 Hz, mixed with the walking noise (the same one observed in the accelerometer) and some low frequency noise. That opens the possibility of using another type of filtering, erasing the low frequency noise together with the walking high frequency noise as before.

5.1.6.2

Band-pass filter

In order to delete the low frequency noise of the signal and the high frequency noise of the walking, a band-pass filter has been designed. The values of this filter are the ones established in the table 5.1 in page 34, including only the lying, sitting and walking activities.

5.1. BREATH RATE SENSOR

45

Figure 5.12: Frequency response of the band-pass filter IIR

Because the filter has a very steep behaviour in a relatively small bandpass, the attenuation could not be as high as it was in the low-pass filter, only of 40 dB. The maximum ripple allowed could be keep as 1 dB. This less steep filter is not a problem due the fact that the gyroscope have more energy in the interesting frequencies, so less steepness is required. The order of this filter is as low as 4, so it doesn’t introduce any more CPU load or lag than the low-pass filter. 5.1.6.3

Conclusion

The results obtained using this filter with the signal coming from the gyroscope are very good and better than expected. Still some small ”false peaks” can be seen in the picture, but because the interferences are much smaller in magnitude can be filtered in the peak detector algorithm.

46

CHAPTER 5. SENSORS

Figure 5.13: Example of singal and frequency response of a walking measure filtered with the band-pass filter.

5.1.7

Noise cancellation

Another different technique for having a better signal has been taken in consideration. Is the noise cancellation, in concrete on that uses the Least Mean Squares (LMS) algorithm. The principle of this algorithm is having 2 correlated signals, one with the desired signal with some noise and the other with only noise. The idea is to create a signal with the second noise signal that could cancel, or at least minimize, the noise in the first signal. The results achieved with this technique has not been successful. It has been tried to use different axis of the same sensors or even axis of different sensors (accelerometer and gyroscope), but the signals have not enough correlation, and the best results barely improve at all the input signal. To achieve more correlation closer signals are needed. It would be ideal to have 2 of the same sensors and situate them in places of the patient’s body that the first one have breath rate signal in it but not the second one. With the noise of the second one some of the noise of the first one could be erase,

5.1. BREATH RATE SENSOR

47

so a good breath rate signal should remain. The position of the placement is critical, because the walking noise has to be almost identical for this system to work, and beforehand is difficult to thing such a combination of places. After some measures and testing some signals, it has been decided to not use this system due its difficulty to make it work.

5.1.8

Algorithm validator

Once the filtered signal obtained, there is the need of doing one check in order to validate the measure. Because maybe the sensor was not attached correctly or for another reasons, the signal measure could not contain any value but white noise. In order to detect that some algorithm has to be used for not save false signals into the server. The method used is calculating the energy of the filtered signal. That will show if there is any signal in the breath rate expectable frequencies or not. If there is not enough, the signal will not be validated and, of course, it will not continue in further analysis. The value of the energy has been calculate per measure, so the formula is independent on the sample frequency or the length of the measure. Taking in consideration that the signal is discrete, the equation used is:

Epersample =

Pn signal[i] 2 i=1

Fs · T

(5.1)

Empirically and after some measures, it has determine that for the well done accelerometer measure, the average energy per measure is around 1000, meanwhile a bad measure the average is around 0.04. The big difference allow to have a arbitrary point fare away of the 2 values. It has been established as 10. Similarly, the vale average energy per measure in a correct measure made with the gyroscope is around 60000, meanwhile the not good one is around 4. Again, there is a big difference and the arbitrary middle point has been established in 1000.

48

5.1.9

CHAPTER 5. SENSORS

Algorithm detector of peaks

With the signal filtered and validated, to obtain the number of respiration per second it has been used an algorithm that counts the maximums of the filtered signal. To do so, three points are tracked with an equal number of points in between. If the middle point has a bigger value that the other two, a peak is detected. This algorithm is executed in jumps big enough for not being very computer-demanding and small enough for not missing any peak. This value is adjusted automatically depending of the acquisition frequency setted in the application.

Figure 5.14: Example of the peak detector algorithm.

5.2. THERMOMETER

5.2

49

Thermometer

5.2.1

Introduction

During this project was being done, the opportunity to add a real medical sensor has appeared. In concrete, is a tympanic temperature sensor (TTSP400), a thermometer that is putted inside the ear for more accurate and consistent results than using traditional thermometers in other parts the body, like in the armpit or the mouth. Electrically, this sensor is equivalent to the YSI 400 series. Is a thermistor type NTC, with the speciality of be quite linear (in thermistor standards) between a close range of human temperatures (between 25 to 45 degrees Celsius).

• • • •

Accuracy: ±0.1o C (In the range between 25 to 45o C) Type: NTC (Negative Temperature Coefficient) R0 : 25o C Beta coefficient: 3892

5.2.2

Description of the system

Because this temperature sensor is much less demanding in all the parameters, the system used for the breath rate sensor can easily accommodate this sensor. This sensor uses a direct analogical interface, due through the cable only the temperature dependent resistor is connected. The Arduino Duemilanove board already have 6 ADC inboard (analogical to digital converters), so one of this is used for reading this sensor. Because the nature of thermal measures, no filtering or any digital process of the signal really needs to be done in the smartphone. It has, though, to be calculated the value of the temperature from the value of the resistor read. This process is done in the Arduino itself. The formulation, starting from this circuit of picture 5.15 can be modelled in the equations 1, 2 and 3:

50

CHAPTER 5. SENSORS

Figure 5.15: Linearization of the thermistor.

Vout = Vdd

Rn Rn + RL

B Rn = R0 e

T =



1 T



1 T0



B B T0

(5.2)

RL Vout + ln R0 (V dd −Vout )

(5.3)

(5.4)

The value of the resistor Req in the circuit 5.15 is 1K. This value is achieved with several resistor connected in parallel to reduce the effect of the tolerances of the resistor. With this configuration a little self-heating of the resistor has been detected of the thermistor. This self-heating is produced for the Joule effect in the thermistor with the intensity used to measure the value. For production purposes, the circuit should be changed for another configuration.

5.2. THERMOMETER

Figure 5.16: Picture of the thermistor

51

52

CHAPTER 5. SENSORS

Chapter 6 Server part 6.1

Introduction

The program includes the functionality to save all the data registered into a remote server. This server should be acceded only for the user of the application and the medical personal authorized in order to check all the data for further analysis. Also, it would be interesting if the server is done in a mobile solution, because that would open possibilities, like hosting the server in mobile devices or in medical vehicles.

6.2 6.2.1

Description of the system Database

The database is structured in 2 types of table. The first one contains the users and the passwords of all the users registered in the system. This database is used, then, for the functions of adding new users and validation of the users already logged. The other type of table contains all the measures of each user. There is one of this table for each user. When a new user is registered in the first table, the one that contains the users and the passwords, a new table is created for saving the future measures of this user. The data of this table have the next of the table 6.1: 53

54

CHAPTER 6. SERVER PART DATE(varchar(14))

TYPE(varchar(2))

MESURE(float)

REF(int)

Table 6.1: Structure in data table

• DATE: Which contain the data when the measure was token. • TYPE: Type of measure, coding the different possible measures (BR = Breath Rate, etc). • MEASURE: Value of the measure itself. • REF: Value that relates different measures. The DATE field have the information when the measure was took. Is coded in a 14 VARCHAR variable, using the codification YYYYMMDDhhmmss, where ”Y” is year, ”M” is month, ”D” is day, ”h” is hour, ”m” is minute and ”s” is second. The REF field relates measures that have been taken in a burst. That is useful in order to save data for future processing, like in continuous acquisition mode, allowing make plots of some data during different set ups. All this data will, took during the same burst, will have the same positive and bigger than zero index. Data token in non burst modes, will have this index equal to 0.

Figure 6.1: Diagram of the data base

6.2. DESCRIPTION OF THE SYSTEM

6.2.2

55

Software used

The software used to implement the web service of storage of information and validation of users is a LAMP solution. LAMP stands for Linux Apache MySQL PHP, which describes all the software components. This solution has been chosen for being free and open, and because is the industry standard. The data is stored in MySQL database, but the algorithm used for that are written in PHP. The PHP scripts are the ones that implements all the logic for validate the users and to adapt the data into storable formats. The PHP scripts are run by the Apache web server. Linux stands for being the Operation System used in this case. Use Linux is a must due the hardware set up (described below).

Figure 6.2: Diagram of the server

Also, because the server used is situated in Barcelona (Spain), a DDNS solution has been used in order to access to the server remotely. That required configuration of the modem that hosts the web server.

6.2.3

Hardware used

The hardware used is a credit-card-sized single-board computer called Raspberry Pi (model B). This card is a completely computer on its own, featuring a ARM CPU (800Mh - 1 Gh), 512 Mb of RAM, 16 Gb of storage through SD storage plus external USB storage and all the connections required in a normal computer (HDMI, Ethernet 10/100, USBx2, audio).

56

CHAPTER 6. SERVER PART

This hardware is a very convenient solution due its low price (35$), its very reduced consumption (around 1W in average) and its decent performance. This hardware is enough powerful for the testing and development, but it will not be powerful enough as a final solution. A more powerful and professional solution would be required. The portability, though, is immediate, because it is been implemented into a LAMP solution, very used and standard in the industry of web servers.

6.2.4

Scripts

To implement the commented functionalities different PHP scripts have been used. Below there is a small comment of each of the scripts.

add measurephp When the user is validated, this script save a measure coming from the smartphone in the personal user table, adding at the end of the table. check user.php Check that the user already exists in the user table, and if it does, it check the password. config.php Contains the constants of the MySQL connection. echo.php Returns echo. Is used to check if the server is online, before of any other server instruction. new user.php After checking that the user that is intended to create does not already exist in the user table, creates a new user. It consists of adding a new entry of the user table with the new user name and password, and creating a table to store future measures. give ref number.php With a given user and a given type of sensor, it checks in the user table for other series of measures and return a identifier or measure that is not used (unique one).

Chapter 7 Android application 7.1

Introduction

For programming the android application the official programming suite made by Google (owner of the Android OS) called Android Studio has been used [8]. This software is free to use and includes many useful functionalities in the Android application development, as a downloader of all the APKs of Google, a compiler, a programmer to send the application from the computer into an Android device, a debugger, etc.

The smartphone that has been used for developing and testing the application is a BQ Aquaris 4.5, with a CPU ARM Dual Core Cortex A9 at 1GHz, 1 Gb of RAM memory, 4 Gb of internal memory, 16Gb of SD memory, screen of 4.5 inches. The version of the Android, in this device, is 4.1, but the application is compatible with Android 2.3 or further.

The requirements estimated for this application are not very high, and it depends a lot of how many sensors are working at the same time, and the amount of data processing that would take (different sensors can have big variations between computational requirements). Due the use of many threads for the sensor reading and the data processing, any dual-core with at least 1GHz of CPU speed would be enough. 57

58

7.2

CHAPTER 7. ANDROID APPLICATION

Application flow diagram

Figure 7.1: Flow diagram of the application

7.3

Captures of the application

Some screenshots of the application running can be seen starting in the figure 7.2 to figure 7.10.

7.3. CAPTURES OF THE APPLICATION

Figure 7.2:

Figure 7.3:

59

Figure 7.4:

In the figure 7.2 can be seen the first menu that the user see when he or she opens the application. Pressing the button ’settings’ the user goes to an another menu (figure 7.3) to choose between many configuration settings. In the figure 7.4 there is the menu of the connection settings. It contains the information for connecting to the server. In the figure 7.5 can be seen the activity where the breath rate measurement happen. When the breath rate sensor is connected, the button ”Make measure” is setted pushable. If it gets pushed, the measure starts and the dialogue of the figure 7.6 and it disappears when the measure is done. The length of the measure and another parameters can be adjusted in the configuration breath rate activity (figure 7.7). Similarly than in the breath rate sensor, the thermistor have an activity (figure 7.8) for starting the measure. Differently, though, it has a timer possibility, that allows to automatically do measures every certain amount of time. This time an another parameters can be setted in the thermistor configuration activity (figure 7.6). The figure 7.10 contains all the settings related of the registration and authentication. In this activity a new user can be created so the data of the measures will be saved in the server. In this activity the user can be also logged in or logged out, if the user have already been created.

60

CHAPTER 7. ANDROID APPLICATION

Figure 7.5:

Figure 7.6:

Figure 7.7:

Figure 7.8:

Figure 7.9:

Figure 7.10:

Chapter 8 Conclusion The purpose of this project was to answer if an inexpensive health care system could be done. The answer is yes. Using technologies that already exists and are growing in popularity, such as smartphones, and some dedicated hardware a health care system can be done. During this project a Breath rate sensor has been done using combined information from different papers, making this sensor quite pioneer in this kind of sensors. Also, a widely used in medical applications thermistor sensor has been used. The device developed in the project is versatile enough to handle different sorts of sensors, and incorporate more if it is required. The goals of the project can be summarized in the next points:

• During the project a fully functional Android application have been developed. This application acquires information from the sensors, display the information to the user and send the information to a remote server. • The usage of a smartphone as a preventive and monitoring health tool have been validated as useful. • Two sensors have been created in order to validate the application. • During the development of the breath rate sensor several techniques and sensors have been used, and some of then have been validated to work in a range of conditions • Due the modular nature of the program realized, it can be easily expanded or modified for commercial purposes. 61

62

CHAPTER 8. CONCLUSION

Even if this project validates the viability of this device, different improves can still be done in the project. After talking with some experts, the next points should be used as a guide for further development of the project:

• Make the hardware smaller and specially able to handle temperatures until −20◦ C. • Make applications for checking the data stored in the server and display it in a user-friendly manner. This applications should be for Android or PC. They should display the information in graphs. • Another important feature for the consulting applications would be to add thresholds, for automating alert if the magnitude desired is up or down some minimums or maximums. • Add a display in the same device for fast checking of the value.

Bibliography [1] T. Torfs, T. Sterken, S. Brebels, J. Santana, R. van den Hoven, N. Saillen, N. Bertsch, D. Trapani, D. Zonta Power Wireless Sensor Network for Structural Health Monitoring of Buildings using MEMS Strain Sensors and Accelerometers . [2] Tran Duc Tan, Nguyen Tien Anh, Gian Quoc Ahn Lowcost Structural Health Monitoring Schoem Using MEMS-based accelerometers 2011. [3] Ja-Woong Yoon, Yeon-Sik Noh, Yi-Suk Kwon, Won-Ki Kim and HyungRo Yoon Improvement of Dynamic Respiration Monitoring Through Sensor Fusion of Accelerometer and Gyro-sensor . [4] P.D. Hung, S. Bonnet, R. Guillemaud, E. Castelli, P. T. N. Yen Estimation of respiratory waveform using an accelerometer . [5] A. Bates, M. J. Ling, J. Mann and D. K. Arvind Respiratory rate and flow waveform estimation from tri-axial accelerometer data 2010. [6] www.arduino.cc [7] www.github.com/pololu/l3g-arduino [8] https://developer.android.com/sdk/installing/studio.html

63

Smile Life

When life gives you a hundred reasons to cry, show life that you have a thousand reasons to smile

Get in touch

© Copyright 2015 - 2024 PDFFOX.COM - All rights reserved.