Technical University of Mombasa

Faculty of Engineering and Technology

DEPARTMENT OF ELECTRICAL AND ELECTRONIC ENGINEERING

Bachelor of Science in Electrical and Electronic Engineering

Project proposal report submitted in partial fulfillment requirements for the degree of
Bachelor Of Science in Electrical and Electronic Engineering

GSM BASED PATIENT HEALTH MONITORING SYSTEM

By
STEPHEN SAGINI MACHOKA

BSEE/0078/2016

Supervisor Mr. Kariuki

Date submitted

1|Page
DECLARATION
I Stephen Sagini Machoka declare the content of this project report representation my own unaided
work, and the report has not previously been submitted for academic examination towards any
qualification. Furthermore, it represents my own opinion and not necessarily those of the Technical
University of Mombasa.

Signed………………………….. Date………………………………..

DEDICATION
I dedicate this proposal report to my family members, fellow classmates and my lecturers who have
been guiding and inspiring me through my journey of education. I thank them for their prayers, support
and motivation.

2|Page
 ABSTRACT
From today world of automation, Application of engineering and technology has proved its
significance in the field of biomedical. It not only made doctors more efficient but also helped
them in improving total process of medication.
In multispecialty hospitals, where there are a huge number of wards and in each ward, there is a
lot of patients, doctors cannot supervise the patient each and every moment. For this, doctors
form the time slots and each ward is visited after specific period of time. But patients may have
some problems in between these time slots. This leads to inconveniency of patient monitoring in
the hospital. The GSM based Patient monitoring system for doctors provides solution for this. It
continuously provides following information to doctors.
Heartbeat of patient
Body temperature of patient

Respiration of patient

This is achieved by using sensors that will measure the parameters. Raw data from the sensors
(temperature sensor, heart rate sensor and respiratory sensor) is received by the Arduino Uno
Board, then sent to the GSM which is used to transmit the data over the network to the mobile
receiver device e.g. mobile phone.
By use of this device patients enjoy many advantages since they can be monitored anywhere
and anytime continuously by the health caregiver.
By so doing, not only the burden cost can be minimized in terms of installation and maintenance
of the existing hardwiring in the hospitals, but also an efficient patient monitoring will be
achieved.

3|Page
 ACKNOWLEDGEMENT
First and foremost, thanks to the Almighty God for the favor throughout my five year stay in
Technical University of Mombasa.

I would also like to thank my supervisor Mr. Kariuki for the support for guidance and
encouragement throughout this project. Thanks to my classmates and everybody who has given
me support.

Lastly, I express my heart felt gratitude to my entire family for their continued support and love.

4|Page
 Table of contents

DECLARATION ................................................................................................................................................... 2
DEDICATION ...................................................................................................................................................... 2
ABSTRACT ......................................................................................................................................................... 3
ACKNOWLEDGEMENT....................................................................................................................................... 4
1 CHAPTER ONE ........................................................................................................................................... 7
1.1 Introduction ...................................................................................................................................... 7
1.2 Problem statement ........................................................................................................................... 8
1.3 Overall objectives .............................................................................................................................. 9
1.4 specific objectives ............................................................................................................................. 9
1.5 Motivation of the project .................................................................................................................. 9
2 CHAPTER TWO ........................................................................................................................................ 10
2.1 Literature review ............................................................................................................................. 10
2.1.1 Arduino Uno overview ............................................................................................................ 12
2.1.2 Summary ................................................................................................................................. 13
2.1.3 Power ...................................................................................................................................... 13
2.1.4 Memory ................................................................................................................................... 14
2.1.5 Input and Output ..................................................................................................................... 14
2.1.6 Communication ....................................................................................................................... 15
2.2 Programming ................................................................................................................................... 15
2.2.1 Automatic (Software) Reset .................................................................................................... 16
2.2.2 USB Overcurrent Protection .................................................................................................... 16
2.3 ATMEGA328 MICROCONTROLLER .................................................................................................. 16
2.3.1 PIN DESCRIPTIONS ................................................................................................................... 17
2.4 Temperature Sensor DS18B20 ........................................................................................................ 19
2.1 MQ3 Alcohol Sensor ........................................................................................................................ 20
2.2 GSM SIM800 module....................................................................................................................... 21
3 METHODOLOGY ...................................................................................................................................... 22
3.1 Block diagram of the Monitoring system ........................................................................................ 22
3.2 Arduino Uno Board.......................................................................................................................... 23
3.3 The Alcohol Sensor .......................................................................................................................... 26
3.4 The DS18B20 temperature sensor .................................................................................................. 27

5|Page
 3.5 ARDUINO GSM SHIELD .................................................................................................................... 28
3.5.1 Power requirements ............................................................................................................... 28
3.5.2 On board indicators................................................................................................................. 28
3.5.3 GSM Library ............................................................................................................................. 31
3.5.4 Sending a SMS message .......................................................................................................... 31
3.5.5 Schematic diagram .................................................................................................................. 37
4 RESULTS AND DISCUSSION ..................................................................................................................... 37
4.1 Normal range................................................................................................................................... 37
4.2 Abnormal range............................................................................................................................... 38
4.3 Conclusions ..................................................................................................................................... 39
4.4 PRACTICAL RESULTS ........................................................................................................................ 39
5 CONCLUSION........................................................................................................................................... 40
6 Challenges ............................................................................................................................................... 41
7 Recommendation ................................................................................................................................... 42
8 References .............................................................................................................................................. 42
9 APPENDIX ................................................................................................................................................ 42
Programming source code .......................................................................................................................... 42

Table of Figures

FIGURE 2.1.......................................................................................................................................................................... 13
FIGURE 2.2.......................................................................................................................................................................... 17
FIGURE 3.1 BLOCK DIAGRAM OF THE SYSTEM.............................................................................................................................. 23
FIGURE 3.2 ARDUINO UNO ..................................................................................................................................................... 24
FIGURE 3.3 LCD DISPLAY ....................................................................................................................................................... 26
FIGURE 3.4 ALCOHOL SENSOR DIAGRAM .................................................................................................................................... 27
FIGURE 3.5 TEMPERATURE SENSOR CCT ..................................................................................................................................... 28
FIGURE 3.6 GSM ON ARDUINO UNO ......................................................................................................................................... 29
FIGURE 3.7 GSM ................................................................................................................................................................. 30
FIGURE 3.8 SCHEMATIC DIAGRAM OF GSM BASED MONITORING SYSTEM .......................................................................................... 37
FIGURE 4.1 NORMAL PATIENT CONDITION.................................................................................................................................. 38
FIGURE 4.2 ABNORMAL PATIENT CONDITION.............................................................................................................................. 39

6|Page
1 CHAPTER ONE
1.1 Introduction
Patient monitoring by definition is the repeated or continuous observation of vital signs or
physiologic functions to ensure patient safety and guide therapeutic interventions. Today, most
advanced monitoring systems depend on invasive sensors, cables, and bulky monitors to recognize,
transfer, process, and display the bio-signals to be monitored. Therefore, continuous advanced
monitoring is mainly restricted to the intensive care unit, the operating room, and the post
anesthesia care unit. Most other monitoring in the hospital continues to be basic and intermittent—
including monitoring on medical and surgical general care wards. When at home, before-and-after
hospital admission, patients are usually not monitored at all.

Current ward monitoring protocols typically consist of intermittent spot checks by a nurse about
every 4–8 h. This leaves patients unmonitored for most of the time during their hospital stay [
(Leuvan CH, 2008)]. Alterations in vital signs as warning signs of clinical deterioration are
frequently not or only belatedly recognized by the conventional spot check-based monitoring
strategy. In hospitalized patients recovering from non-cardiac surgery, severe prolonged
hypoxemia is common and unfortunately seriously underestimated using intermittent vital sign
checks [ (Duus CL, 2018)]. Similar patterns regarding the rate of recognized abnormal vital signs
were observed for tachycardia, bradycardia, tachypnea, and bradypnea. In patients recovering from
abdominal surgery on the general care ward, postoperative hypotension (mean arterial pressure <
65 mmHg for ≥ 15 min) has been shown to occur in about one fifth of patients and not to be
recognized by routine vital sign assessments in about half of the cases. In addition to missing
critical changes in vital signs, the recognition of abnormal vital signs by a bedside nurse often
triggers a long chain of commands resulting in delays until an intervention can be taken. A closed
claims analysis of opioid induced respiratory compromise on the general care ward identified
nearly half of all these events occurred within 2 h of the last nursing check. In addition, the authors
concluded that nearly all of these events would have been prevented by better continuous
monitoring and education [ (Lee LA, 2015;)]. Considering that most nursing spot checks of vital
signs leave gaps of about 4 h in-between two consecutive assessments, this period is associated
with the highest vulnerability

Automated continuous noninvasive ward monitoring is a promising approach to closely follow

changes in vital signs over time and thus identify patients who are deteriorating in a timely fashion.
The rationale behind continuous ward monitoring is that most hospitalized patients do not
deteriorate all of a sudden. Although complications often become clinically apparent as acute
cardiocirculatory or respiratory failure and acute changes in consciousness, we know for a long
time that subtle abnormalities in vital signs usually precede these life-threatening conditions,
sometimes by 6–12 h [ (Chen L, . 2017)]. Subtle changes in blood pressure, heart rate, respiratory
rate, or oxygen saturation are early signs of clinical deterioration eventually leading to adverse
events.

7|Page
Automated continuous noninvasive ward monitoring may enable clinical deterioration to be
identified well before a serious adverse event occurs. There is already some evidence that
intensified and automated ward monitoring of vital signs may improve patient outcome by a
reduction of rescue events . Before-and-after studies showed that the deployment of an electronic
automated advisory vital signs monitoring and notification system, is associated with significant
improvements in key patient-centered clinical outcomes in patients treated on the normal ward.

1.2 Problem statement

While most advanced monitoring is in place in intensive care units, nearly half of all adverse
events in hospitalized patients occur on the general care ward ( Perman SM, Stanton E, Soar J,
Berg RA, Donnino MW, Mikkelsen ME,, october 28-29 2021).]. Ironically, this area—also
referred to as “the patient’s room”—is traditionally regarded as a place of recovery for the more
stable medical or surgical patients, who will (in the absence of setbacks) transition to leave the
hospital. This indicates that the general care ward plays a pivotal role in the care for patients in
the postoperative period, a period in which patients are especially prone to developing clinical
deterioration and life-threatening complications. Not only are catastrophic cardiorespiratory
events common in general care ward environments, their outcomes are significantly worse
compared with similar events in monitored intensive care units. For example, a large national
registry identified 44, 551 index events across more than 300 US hospitals. More importantly
these acute respiratory events on inpatient wards had an associated in-hospital mortality of
approximately 40% [ (Sun Z, 2015)]
.
Considering all this, there is great need for adoption of a continuous monitoring system that can mitigate
the challenges faced.

8|Page
1.3 Overall objectives
To design, implement, construct and test a prototype of a GSM based patient health monitoring system

1.4 specific objectives

1. To design a prototype GSM based patient health monitoring system
2. To implement a GSM based patient monitoring system
3. To test the prototype

1.5 Motivation of the project

The idea of this project was born out of the consideration of the problems that surround the
Kenyan health sector during this pandemic. This period is one the worst in the Kenyan health
sector history and the whole world at large. The pandemic has not only hit the patients, but has
also largely attacked the health care givers. There is great inadequacy in proper and sufficient
patient monitoring mechanisms and equipment, inadequate spaces (wards) in the public health
facilities and the unaffordable high cost of private health facility bills

9|Page
2 CHAPTER TWO
2.1 Literature review
Dae-Ki Cho (cho, 2015) et al did research on a remote medical monitoring system using
Bluetooth P2P networks [1]. In his research paper; with his colleagues from the University of
California, Los Angeles, one of their goals was to examine the possibility and effectiveness of
hospital networking using Bluetooth and data mulling of medical records from patients to an
Internet medical database. Patient data was collected from body sensors and stored on a Bluetooth
enabled gateway. The system was then designed such that once a designated caregiver (e.g. a
nurse), comes within the patient range, the patient’s gateway would initiate a connection to the
caregiver’s Bluetooth gateway (typically, a Smartphone) and transfer the stored data using a
Peerto-Peer (P2P) technique called Blue Torrent. Data can be transferred either on a preset
schedule (every 10 minutes) or immediately upon the availability of a caregiver. Later, the
caregiver, upon completing his/her round of patient visits, uploads the patient data to a central
server. This delivery can occur either directly (i.e. the same caregiver receives and then delivers
the data to server), or indirectly (the data has been opportunistically transferred from nurse to
nurse in a P2P manner). Blue Torrent is a P2P file sharing application based on ubiquitous
Bluetooth-enabled devices. It was originally proposed for sharing multimedia content such as
movie clips or music files, but it can easily be adopted and used for transfer of medical monitoring
data.
Blue Torrent works similarly to BitTorrent by splitting the files sent into small chunks before
propagating them to other nodes. The key difference between Bit Torrent and Blue Torrent is that

10 | P a g e
Blue Torrent is designed for single hop data transfers. This is due to the fact that TCP transfers
are unreliable over multi-hop wireless paths in general, and the challenges experienced in
maintaining a multi-hop (e.g. scatter net type) path in Bluetooth particularly. Thus, in Blue
Torrent, random pieces are transferred only between adjacent peer nodes and it also handles
transfers of multi-block files. Just like in BitTorrent, each node keeps track of the pieces received
at any point in time. Each receiving node will endeavor to complete the assembly of the file by
requesting the missing packets of the file from available neighboring nodes.
Other than the relaying of medical records from patients to the central Internet database, the
Bluetooth network may also be used to alert a medical attendant that a patient has a medical
emergency requiring immediate attention.

• The conventional Bluetooth-based patient monitoring system’s not suitable for

emergencies. Bluetooth connection establishment takes 5 to 10 seconds and this delay
can cause severe problems in medical environments.
• At times access to Bluetooth and Wi-Fi access points may be intermittent, thus patient
data dispatching to an Internet server will suffer high latency

(Rishahb Jain, 2018)Here in his research he came up with IoT based Health Monitoring
System [3] which records the patient heart beat rate and body temperature and also send an
email/SMS alert whenever those readings go beyond critical values. Pulse rate and body
temperature readings are recorded over Thing Speak and Google sheets so that patient health
can be monitored from anywhere in the world over internet. A panic will also be attached so
that patient can press it on emergency to send email/SMS to their relatives

(Zhuang, 2016)Ho ting cheng and weihua Zhuang came up also with a related research
(Bluetooth-enabled in-home patient monitoring system) [4]. In their study they focused on
early detection of Alzheimer’s disease. They did in home patient location tracking and the
location information will then be recorded in a local database. With knowledge of the
movement pattern of a patient, a medical practitioner will be able to determine whether ta target
patient is developing Alzheimer’s disease.

11 | P a g e
(purnima, 2014)Purnima from Army Institute of Technology India, did a research in patient
monitoring (Zigbee and GSM based patient Health monitoring system) [2]. In his paper, patient
parameters were measured (temperature, heartbeat, ECG) and wirelessly transmitted using
ZigBee. The patient health is monitored and the acquired data is analyzed at a centralized ARM
microcontroller. If a particular patient’s health parameters fall below the threshold value, an
automated SMS is sent to the pre-configured Doctor’s mobile number using GSM module
interfaced to the ARM microcontroller.

2.1.1 Arduino Uno overview

The Arduino Uno is a microcontroller board based on the ATmega328. It has 14 digital
input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, a 16 MHz ceramic
resonator, a USB connection, a power jack, an ICSP header, and a reset button. It contains
everything needed to support the microcontroller; simply connect it to a computer with a USB
cable or power it with an AC-to-DC adapter or battery to get started. is the Arduino Uno board
diagram.

The Uno differs from all preceding boards in that it does not use the FTDI USB-to-serial driver
chip. Instead, it features the Atmega16U2 (Atmega8U2 up to version R2) programmed as a
USB-to-serial converter.
The latest revision of the board has the following new features:

• 1.0 pinout: added SDA and SCL pins that are near to the AREF pin and two other new
pins placed near to the RESET pin, the IOREF that allow the shields to adapt to the
voltage provided from the board. In future, shields will be compatible with both the
board that uses the AVR, which operates with 5V and with the Arduino Due that
operates with 3.3V. The second one is a not connected pin that is reserved for future
purposes.
• Stronger RESET circuit.
• Atmega 16U2 replace the 8U2.

12 | P a g e
 Figure 2.1

2.1.2 Summary
Microcontroller ATmega328
Operating Voltage 5V
Input Voltage (recommended) 7-12V
Input Voltage (limits) 6-20V
Digital I/O Pins 14 (of which 6 provide PWM output)
Analog Input Pins 6
DC Current per I/O Pin 40 mA
DC Current for 3.3V Pin 50 mA
Flash Memory 32 KB (ATmega328) of which 0.5 KB used by bootloader
SRAM 2 KB (ATmega328)
EEPROM 1 KB (ATmega328)
Clock Speed 16 MHz
2.1.3 Power
The Arduino Uno can be powered via the USB connection or with an external power supply.
The power source is selected automatically by the board.

External (non-USB) power can come either from an AC-to-DC adapter or a battery. The adapter
can be connected by plugging a center-positive plug into the board's power jack. Leads from a
battery can be inserted in the Gnd and Vin pin headers of the POWER connector.

13 | P a g e
The board can operate on an external supply of 6 to 20 volts. If supplied with less than 7V,
however, the 5V pin is bound to supply less than five volts and the board may be unstable. If
supplied with more than 12V, the voltage regulator may overheat and damage the board.
Therefore, that means the recommended range is 7 to 12 volts.

The power pins are as follows:

• VIN. The input voltage to the Arduino board when it's using an external power source
(as opposed to 5 volts from the USB connection or other regulated power source). You
can supply voltage through this pin, or, if supplying voltage via the power jack, access it
through this pin.
• 5V. This pin outputs a regulated 5V from the regulator on the board. The board can be
supplied with power either from the DC power jack (7 - 12V), the USB connector (5V),
or the VIN pin of the board (7-12V). Supplying voltage via the 5V or 3.3V pins
bypasses the regulator, and can damage your board therefore it is discouraged.
• 3V3. A 3.3-volt supply generated by the on-board regulator. Maximum current that can
be drawn is 50 mA.
• GND. Ground pins.
• IOREF. This is a pin on the Arduino board that provides the voltage reference with
which the microcontroller operates. A properly configured shield can read the IOREF
pin voltage and select the appropriate power source or enable voltage translators on the
outputs for working with the 5V or 3.3V.

2.1.4 Memory
The ATmega328 has 32 KB (with 0.5 KB used for the bootloader). In addition to that it also has
2 KB of SRAM and 1 KB of EEPROM (which can be read and written with the EEPROM
library).
2.1.5 Input and Output
Each one of the 14 digital pins on the Arduino Uno can be used for input or output, using the
functions , digital Write, and digital Read. They operate at 5 volts with each pin providing or
receiving a maximum of 40 mA. Each pin has an internal pull-up resistor
(disconnected by default) of 20-50 KΩ. In addition to this, some pins have specialized
functions:

• Serial: 0 (RX) and 1 (TX). Receives (RX) and transmits (TX) TTL serial data.
These pins are connected to the corresponding pins of the ATmega8U2 USB-to-TTL
serial chip. External Interrupts: 2 and 3. These pins can be configured to
trigger an interrupt on a low value, a rising or falling edge, or a change in value.
• PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analog Write
function.
• SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI
communication using the SPI library.
• LED: 13. There is a built-in LED connected to digital pin 13. When the pin is HIGH
value, the LED is on, when the pin is LOW, it's off.

14 | P a g e
The Uno has 6 analog inputs, ranging from A0 through A5, each of which provide 10 bits of
resolution (i.e. 1024 different values). By default, they measure from ground to 5 volts, though
it is possible to alter the upper end of their range using the AREF pin and the analog Reference
function. For the analog inputs too, some pins have specialized functionality:

• TWI: A4 or SDA pin and A5 or SCL pin. Support TWI communication using the
Wire library.

There are two more pins on the board:

• AREF. Reference voltage for the analog inputs. Used with analog Reference.
• Reset. Bring this line LOW to reset the microcontroller. Typically used to add a
reset button to shields which block the one on the board.

2.1.6 Communication
The Arduino Uno has a number of avenues for effecting communicating with computers, other
Arduinos, or other microcontrollers. The ATmega328 provides UART TTL (5V) serial
communication, which is available on digital pins 0 (RX) and 1 (TX). An ATmega16U2 on the
board channels this serial communication over USB and appears as a virtual com port to
software on the computer. The ‘16U2’ firmware uses the standard USB COM drivers, and no
external driver is needed. However, on Windows computers, a ‘.inf file’ is required. The
Arduino software includes a serial monitor which allows simple textual data to be sent to and
from the Arduino board. The RX and TX LEDs on the board will flash when data is being
transmitted via the USB-to-serial chip and USB connection to the computer (but not for serial
communication on pins 0 and 1).
A Software Serial library allows for serial communication on any of the Uno's digital pins.

In addition, the ATmega328 also supports I2C (TWI) and SPI communication. The Arduino
software includes a Wire library to simplify use of the I2C bus and for SPI communication,
SPI library is used.

2.2 Programming
To program the Arduino Uno, the Arduino software is used; it is an open source software so it
can be easily downloaded from the Arduino website. Once the software is installed, select
"Arduino Uno from the Tools > Board menu (according to the microcontroller on the board).

The ATmega328 on the Arduino Uno comes preboned with a bootloader that allows the user to
upload new code to it without the use of an external hardware programmer. It communicates
using the original STK500 protocol (reference, C header files).

Alternatively, the bootloader can be bypassed and the microcontroller programmed through the
ICSP (In-Circuit Serial Programming) header using Arduino ISP or similar.

15 | P a g e
2.2.1 Automatic (Software) Reset
To do away with the need of a physical press of the reset button before an upload, the Arduino
Uno is designed in a way that enables it to be reset by software running on a connected
computer. The reset line of the ATmega328 is connected to one of the hardware flow control
lines (DTR) of the ATmega8U2/16U2 via a 100 nano-farad capacitor. Asserting (taking low)
this line causes the reset line to drop long enough to reset the chip. The Arduino software uses
this capability to allow you to upload code by simply pressing the upload button in the Arduino
environment. This means that the bootloader can have a shorter timeout, as the lowering of DTR
can be well-coordinated with the start of the upload.

This setup has other implications. When the Uno is connected to either a computer running Mac
OS X or Linux, it resets each time a connection is made to it from software (via USB). For the
following half-second or so, the bootloader is running on the Uno. While it is programmed to
ignore malformed data (i.e. anything besides an upload of new code), it will intercept the first
few bytes of data sent to the board after a connection is opened. If a sketch running on the board
receives one-time configuration or other data when it first starts, make sure that the software
with which it communicates waits a second after opening the connection and before sending this
data.

The Uno contains a trace that can be cut to disable the auto-reset. The pads on either side of the
trace can be soldered together to re-enable it. It's labeled "RESET-EN". You may also disable
the auto-reset by connecting a 110-ohm resistor from 5V to the reset line.

2.2.2 USB Overcurrent Protection

The Arduino Uno has a resettable polyfused that protects your computer's USB ports from
shorts and overcurrent. Although most computers provide their own internal protection, the fuse
provides an extra layer of protection. If more than 500 mA is applied to the USB port, the fuse
will automatically break the connection until the short or overload is removed.

2.3 ATMEGA328 MICROCONTROLLER

ATMEGA328 microcontroller in fig 2.2 below runs up to 20MHz with an external crystal the
package can be programmed in a circuit with an operating voltage 1.8V to 5V.

16 | P a g e
 Figure 2.2

2.3.1 PIN DESCRIPTIONS

VCC
Vcc this is the voltage supply pin that powers the processor

GND
This is a zero potential connection point

Port B (PB7:0) XTAL1/XTAL2/TOSC1/TOSC2

Port B is an 8-bit bi-directional I/O port with internal pull-up resistors (selected for each bit).
The Port B output buffers have symmetrical drive characteristics with both high sink and source
capability. As inputs, Port B pins that are externally pulled low will source current if the pull-up
resistors are activated. The Port B pins are tri-stated when a reset condition becomes active,
even if the clock is not running.

17 | P a g e
Depending on the clock selection fuse settings, PB6 can be used as input to the inverting
Oscillator amplifier and input to the internal clock operating circuit.
Depending on the clock selection fuse settings, PB7 can be used as output from the inverting
Oscillator amplifier.
If the Internal Calibrated RC Oscillator is used as chip clock source, PB7.6 is used as TOSC2.1
input for the Asynchronous Timer/Counter2 if the AS2 bit in ASSR is set.

Port C (PC5:0)
Port C is a 7-bit bi-directional I/O port with internal pull-up resistors (selected for each bit). The
PC5.0 output buffers have symmetrical drive characteristics with both high sink and source
capability. As inputs, Port C pins that are externally pulled low will source current if the pull-up
resistors are activated. The Port C pins are tri-stated when a reset condition becomes active,
even if the clock is not running.

PC6/RESET
If the RSTDISBL Fuse is programmed, PC6 is used as an I/O pin. Note that the electrical
characteristics of PC6 differ from those of the other pins of Port C.
If the RSTDISBL Fuse is unprogrammed, PC6 is used as a Reset input. A low level on this pin
for longer than the minimum pulse length will generate a Reset, even if the clock is not running.
Port D (PD7:0)
Port D is an 8-bit bi-directional I/O port with internal pull-up resistors (selected for each bit).
The Port D output buffers have symmetrical drive characteristics with both high sink and source
capability. As inputs, Port D pins that are externally pulled low will source current if the pull-up
resistors are activated. The Port D pins are tri-stated when a reset condition becomes active,
even if the clock is not running.

AVCC
AVCC is the supply voltage pin for the A/D Converter, PC3:0, and ADC7:6. It should be
externally connected to VCC, even if the ADC is not used. If the ADC is used, it should be
connected to VCC through a low-pass filter. Note that PC6.4 use digital supply voltage, VCC.

AREF

18 | P a g e
AREF is the analog reference pin for the A/D Converter.

ADC7:6 (TQFP and QFN/MLF Package Only)

In the TQFP and QFN/MLF package, ADC7:6 serve as analog inputs to the A/D converter.
These pins are powered from the analog supply and serve as 10-bit ADC channels.

2.4 Temperature Sensor DS18B20

Body temperature circuit is to measure the body temperature of patient. The normal temperature
for human is 37.0 degree Celsius. Temperature sensor in fig.2.3 below contains three pins that
connected directly to the Arduino Uno board. These sensors have a quoted accuracy of +/-
0.5degree C in the range -10-degree C to +85-degree C.

figure 2.3 temperature sensor 1

Normal human being body temperature is about 37.0 degree Celsius or 98.6-degree Fahrenheit.
However, body temperature also varies depend on sickness or individual conditions such as
metabolism or physiological conditions.
The temperature sensor measures, transmits a digital signal to the Arduino board. In the
Arduino board a decision is made:
If the temperature is within 36 to 42 degrees Celsius, it’s deemed to be normal, a signal value is
sent to the LCD display unit, but if the temperature measured falls outside of the limits, it’s sent

19 | P a g e
to the display unit and the GSM SIM900 GSM/GPRS module which is sent to the mobile phone
of the care giver.
2.1 MQ3 Alcohol Sensor
MQ-3 alcohol sensor below in fig.2.4 detects ethanol in the air. It is used to detect alcohol in the
human breath. It has 6pins, the cover and the body. 2 pins are used for heating system, while other
2 are for connecting power and ground. It also has Alumina tube cover by SnO2, which is tin
dioxide. And between them there is an Aurum electrode. See the sensor with the pins in (figure
2.4)
Operating voltage 5V

Load resistance 200 KΩ

Heater resistance 33Ω ± 5%

Heating consumption <800mw

Sensing Resistance 1 MΩ – 8 MΩ

Concentration Scope 25 – 500 ppm

Preheat Time Over 24 hour

figure 2.4 alcohol sensor 1

If coil inside electrode is heated, SnO2 ceramics will become the semi – conductor which means
that it can make some current flow. When there are alcohol molecules in the breath of the patient,
it meets the electrode that is between alumina and tin dioxide, ethanol burns into acetic acid then

20 | P a g e
more current is produced. So, the more alcohol molecules there are, the more current we will get.
Because of this current change, we get the different values from the sensor.

Normal respiration in a human adult is 12 to 16 breaths per minute.

When there is no presence of alcohol in the breath of the patient, it indicates that the patient is
normal. Presence of alcohol indicates the patient’s breathing is too fast or too slow.
2.2 GSM SIM800 module
A modem is a device that modulates an analog carrier signal to encode digital information, and also
demodulates such a carrier signal to decode the transmitted information. Below is the image of the modem
fig.2.5

figure 2.5 GSM SIM 1

Very low-cost cellphone module. A mini GSM / GPRS breakout board based on SIM800L
module, supports quad-band GSM/GPRS network, available for GPRS and SMS
message data remote transmission.

21 | P a g e
The board features compact size and low current consumption. With power saving
technique, the current consumption is as low as 1mA in sleep mode.
It communicates with microcontroller via UART port, supports command including 3GPP
TS 27.007, 27.005 and SIMCOM enhanced AT Commands.
In transmission the module can consume up to 2 Amps of current. You will need to power
the module between 3.7V and 4.2V.

Features
- Quad-band 850/900/1800/1900MHz
- Connect onto any global GSM network with any 2G SIM
- Make and receive voice calls using a headset or an external speaker such as this and an
electret microphone such as this.
- Send and receive SMS messages.
- Send and receive GPRS data (TCP/IP, HTTP, etc.).
- Find GSM (GPRS) location - this is not GPS.
- AT command interface with "auto baud"

3 METHODOLOGY
This project is divided into two parts:

Hardware design
Software design

Hardware design focuses on the main controller hardware, Arduino Uno board and how is
connected to the sensors, the display unit and the GSM.

3.1 Block diagram of the Monitoring system

The block diagram below in fig 3.1 is the basic connection of all components of the monitoring
system.

22 | P a g e
 Figure 3.1 block diagram of the system

Implementation of the hardware design is consisting of the following components:

1. Arduino Uno board
2. GSM SIM900 GSM/GPRS module
3. Temperature sensor
4. Heartbeat sensor
5. Alcohol sensor
6. 20x4 LCD Display unit
7. GSM Mobile Phone
8. Bread board
9. Jumper wires

3.2 Arduino Uno Board

23 | P a g e
The Arduino Uno in fig.3.2 is the heart of the whole system because it controls all the other
components used in the prototype. It receives all the raw data from the sensors, processes it and
sends it for display. In case of need to send it over the GSM network, it also prompts the GSM
module to send to the required GSM device. It achieves all these by the use of the ATmega328P
microcontroller that does all the processing after receiving the inputs from the sensors and gives
the output the LCD display and the GSM module

Figure 3.2 arduino uno

A circuit will be developed and a prototype with the Arduino Uno as the heart and the controller
of the GSM enable patient monitoring system.

The 20x4 LCD

The 20x4 LCD below in fig.4.4 uses the common HD44780 interface

Pin 1- Ground
Pin 2- +5V
Pin 3- Contrast adjustment
Pin 4- H/L Register Select
Pin 5- H/L Read/Write
Pin 6- H/L Enable
Pin 11- DB4
Pin 12- DB5

24 | P a g e
Pin 13- DB6
Pin 14- DB7

A shown in the diagram below:

Pin 1 to GND
Pin 2 to 5V
Pin 3 to Wiper
Pin 4 to Arduino pin 12
Pin 5 to GND
Pin 6 to Arduino pin 11
Pin 11 to Arduino pin 5
Pin 12 to Arduino pin 4
Pin 13 to Arduino pin 3
Pin 14 to Arduino pin 2

25 | P a g e
 Figure 3.3 LCD display

3.3 The Alcohol Sensor

The alcohol sensor is an MQ3 gas sensor. The MQ series of gas sensors uses a small heater
inside with an electro-chemical sensor. They are sensitive to a range of gases and are used
indoors and at room temperature. Figure below in fig.3.4 shows the connection of the sensor to
the Arduino.

26 | P a g e
 Figure 3.4 alcohol sensor diagram

3.4 The DS18B20 temperature sensor

The DS18B20 sensor can be powered by between 3.0V and 5.5V so connection of its GND pin
to 0V and the VDD pin to +5V from the Arduino is possible. Alternatively, the DS18B20 can
also extract its power from the data line which means only two wires can be needed to connect
it effectively making it great for use as an external sensor. Below is a circuit diagram of the
sensor connected to the Arduino. See fig 3.5

27 | P a g e
 Figure 3.5 temperature sensor cct

3.5 ARDUINO GSM SHIELD

The Arduino GSM Shield is used to connect the Arduino to the internet using the GPRS wireless
network. This module is plugged onto the Arduino board, a SIM card from an operator offering
GPRS coverage is plugged and a few simple instructions followed to start enjoying the services
of communication and connectivity. Through this shield one can also make/receive voice calls
(you will need an external speaker and microphone circuit) and send/receive SMS messages.

3.5.1 Power requirements

The manufacturer recommends that the board be powered with an external power supply that can
provide between 700mA and 1000mA. The producer discourages powering an Arduino and the
GSM shield from a USB connection, as USB cannot provide the required current for when the
modem is in heavy use.

The modem can need up to 2.5A of current at peak usage, which mostly occurs during data
transmission. This current is availed through the large orange capacitor on the board's surface.

3.5.2 On board indicators

The shield contains a number of status LEDs:

• On: shows the Shield gets power.

• Status: turns on to when the modem is powered and data is being transferred to/from the
GSM/GPRS network.

28 | P a g e
 • Net: blinks when the modem is communicating with the radio network.

To use the shield, a SIM card is inserted into the holder. The metal bracket is slid away from
the edge of the shield and the cradle lifted up.

The SIM is inserted in the plastic holder so the metal contacts are facing the shield, with the notch
of the card at the top of the bracket. The SIM is slid all the way into the bracket. The SIM is
pushed to the board and the metal bracket slid towards the edge of the shield to lock it in place.
Once the SIM is inserted, the GSM shield is mounted on top of an Arduino board as shown in fig
.3.6. To upload sketches to the board, I connect it to your computer with a USB cable and upload
my sketch with the Arduino IDE. Once the sketch has been uploaded, the board can be
disconnected from the computer and power it with an external power supply.

Figure 3.6 gsm on Arduino uno

29 | P a g e
Digital pins 2, 3 and 7 are reserved for communication between the Arduino and modem as
shown below in fig 4.8. Communication between the GSM shield and Arduino is handled by the
software serial library on pins 2 and 3. Pin 7 is used for the modem reset.

Figure 3.7 GSM

When modem is powered the yellow status LED turns on, and you can try connecting to the
network.
Developer versions of the GSM shield require the user to press the Power button on the shield
for a few moments to turn the modem on.

30 | P a g e
3.5.3 GSM Library
Communication between Arduino and the GSM shield is handled by the GSM library. The
majority of functions are for data management, voice, and SMS communication. In addition, there
are a number of utilities for managing information about the modem and the SIM card's PIN too.

3.5.4 Sending a SMS message

Once you have connected to your network with the developed sketch, tests can be done on some
of the other functionality of the board. The sketch developed will connect to a GSM network
and send a SMS message to a phone number of provided.
We designed the circuit using the fritzing software and programmed using the Arduino IDE
software and the Arduino Uno circuit board and the GSM SIM800L module using the GSM
libraries.

The following code is for initializing library in Arduino:

// initialize the library instance

#include <OneWire.h>
#include "SIM800.h"
#include <SoftwareSerial.h>
#include <LiquidCrystal.h>
#include "sms.h" SMSGSM
sms;

The following code is for interfacing the Arduino circuit board with the LCD display:

LiquidCrystallcd(7, 8, 9, 10, 11, 12);

// Temp Data
bytei; byte present
= 0; bytetype_s;
byte data[12];
byteaddr[8];
floatcelsius,
fahrenheit;
OneWire ds(5); // on pin 10 (a 4.7K resistor is necessary)

The following code is for programming the GSM SIM800 to send the sms:

31 | P a g e
char text[]="System Online"; //SMS to send
intnumdata; boolean started=false;
charsmsbuffer[160]; char n[20];
inttempThreshold = 35; intbreaThreshold =
100; intalcoSensor; intheartRate;
int16_t raw = (data[1] << 8) | data[0];

void setup(void) {

lcd.begin(16, 2);
// Print a message to the LCD.
Serial.begin(9600);

The following code is for initializing the GSM shield:

Serial.begin(9600);
Serial.println("GSM initialization");
Serial.println("Loading phone number...");
Serial.println("Initializing number ");
Serial.println("Auto_Check mode...");

The following code is for the process of sending sms to the provided phone number and the
message displayed on the LCD display:

lcd.setCursor(0,0); lcd.print("Patient
Alert Systm");
lcd.setCursor(0,1); // Set LCD cursor position (column 0, row 0)
lcd.print("System Config...");
// Start GSM shield
Serial.println("Patient Alert Systm");
//Start configuration of shield with baudrate.
//For http uses is raccomanded to use 4800 or slower. if
(gsm.begin(2400)) {
Serial.println("\nstatus=READY"); started=true;
} else Serial.println("\nstatus=IDLE");

if(started) {
lcd.setCursor(1,1); // Set LCD cursor position (column 0, row 0)
lcd.print("Sending ConfigMsg");

32 | P a g e
 //Enable this two lines if you want to send an SMS. if
(sms.SendSMS("+254723513536", "System Activated"))
Serial.println("\nSMS sent OK");
lcd.setCursor(0,1); // Set LCD cursor position (column 0, row 0)
lcd.print("ConfigMessaga Sent");
} else
{
Serial.println("Not connected"); lcd.clear();
lcd.setCursor(0,1); // Set LCD cursor position (column 0, row 0)
lcd.print("CONNECTION ERROR");
delay(1000);
}
}

void loop(void) { alcoSensor =

analogRead(A0);
heartRate = analogRead(A1);
bytei; byte present = 0;
bytetype_s; byte data[12];
byteaddr[8];

if ( !ds.search(addr)) {
Serial.println("No more addresses.");
Serial.println();
ds.reset_search(); delay(250);
return;
}

Serial.print("ROM ="); for(i

= 0; i< 8; i++) {
Serial.write(' ');
Serial.print(addr[i], HEX);
}

if (OneWire::crc8(addr, 7) != addr[7]) {
Serial.println("CRC is not valid!"); return;
}
Serial.println();

The following code is for programming the internal working of the Arduino uno processor:

33 | P a g e
// the first ROM byte indicates which chip
switch (addr[0]) { case 0x10:
Serial.println(" Chip = DHT11"); // or old DS1820
type_s = 1; break; case 0x28:
Serial.println(" Chip = DS18B20");
type_s = 0; break; case 0x22:
Serial.println(" Chip = DS1822");
type_s = 0; break; default:
Serial.println("Device is not a DS18x20 family device."); return;
}

ds.reset(); ds.select(addr);
ds.write(0x44, 1); // start conversion, with parasite power on at the end

delay(1000); // maybe 750ms is enough, maybe not

// we might do a ds.depower() here, but the reset will take care of it.

present = ds.reset(); ds.select(addr);

ds.write(0xBE); // Read Scratchpad

Serial.print(" Data = ");

Serial.print(present, HEX);
Serial.print(" ");
for ( i = 0; i< 9; i++) { // we need 9 bytes
data[i] = ds.read(); Serial.print(data[i],
HEX);
Serial.print(" ");
}
Serial.print(" CRC=");
Serial.print(OneWire::crc8(data, 8), HEX); Serial.println();

The following code is for programming the input of the temperature sensor:

// Convert the data to actual temperature

// because the result is a 16 bit signed integer, it should //
be stored to an "int16_t" type, which is always 16 bits //
even when compiled on a 32 bit processor.
int16_t raw = (data[1] << 8) | data[0]; if
(type_s) {
raw = raw << 3; // 9 bit resolution default if
(data[7] == 0x10) {
// "count remain" gives full 12 bit resolution

34 | P a g e
raw = (raw & 0xFFF0) + 12 - data[6];
}
} else {
bytecfg = (data[4] & 0x60);
// at lower res, the low bits are undefined, so let's zero them if
(cfg == 0x00) raw = raw & ~7; // 9 bit resolution, 93.75 ms else
if (cfg == 0x20) raw = raw & ~3; // 10 bit res, 187.5 ms else if
(cfg == 0x40) raw = raw & ~1; // 11 bit res, 375 ms
//// default is 12 bit resolution, 750 ms conversion time
}
celsius = (float)raw / 16.0; fahrenheit
= celsius * 1.8 + 32.0;
Serial.print(" Temperature = ");
Serial.print(celsius);
Serial.print(" Celsius, ");
Serial.print(fahrenheit);
Serial.println(" Fahrenheit");
lcd.clear(); lcd.setCursor(0,0);
lcd.print("Patient Alert Systm");
//Serial.print(" Temperature = ");
lcd.setCursor(0,1); // Set LCD cursor position (column 0, row 0)
lcd.print("Temperature: ");
lcd.setCursor(12,1); // Set LCD cursor position (column 0, row 0)
lcd.print(celsius);
lcd.setCursor(16,1);
lcd.print("Celsius"); //
Serial.print(celsius);

The following code is for programming the alcohol sensor:

//Serial.println(" Alcohol = ");

lcd.setCursor(0,2); // Set LCD cursor position (column 0, row 0)
lcd.print("Respiraxon Stat: ");
lcd.setCursor(17,2); // Set LCD cursor position (column 0, row 0)
lcd.print(alcoSensor); lcd.setCursor(16,2); //Serial.print(alcoSensor);

The following code is for programming the heartbeat sensor:

// Serial.println(" Heart Rate = ");

35 | P a g e
lcd.setCursor(0,3); // Set LCD cursor position (column 0, row 0)
lcd.print("Heart Rate: ");
lcd.setCursor(11,3); // Set LCD cursor position (column 0, row 0)
lcd.print(heartRate); lcd.setCursor(16,3); lcd.print("BPM"); //Serial.print(heartRate);
delay(1000);

The following code is for sending sms alert if the threshold specified are not met:

if(celsius>tempThreshold)
{
sms.SendSMS("+254723513536", "UBNORMAL TEMP");
}
if(alcoSensor>breaThreshold )
{
sms.SendSMS("+25423513536", "UBNORMAL RESP");
}

36 | P a g e
3.5.5 Schematic diagram

Figure 3.8 schematic diagram of gsm based monitoring system

4 RESULTS AND DISCUSSION

In this section I will discuss the simulation results

4.1 Normal range

During this period of simulation, patients’ signs are assumed to be normal that is the heartbeat
rate, temperature and Respiration. The system will only display current signs on the LCD
display. The process continuous until the normal limit exceeds.

37 | P a g e
 Figure 4.1 normal patient condition

4.2 Abnormal range

In case the patient’s signs start deteriorating, the system sends immediately a text message to the
current caregiver phone to seek attention. The system keeps sending the SMS until the caregiver
responds to the patients signs.

38 | P a g e
 Figure 4.2 Abnormal patient condition

4.3 Conclusions
➢ From simulations patients’ parameters; temperature, heartbeat rate and respiration were
successfully simulated.
➢ The system was able to measure all the parameters continuously. Immediately when the
specified limit was exceeded, a virtual sms was received in the virtual phone.
➢ From the results its promising that the implementation of the system can achieve the
project objectives
4.4 PRACTICAL RESULTS

The LCD display results of the temperature, the respiratory and the heartbeat sensor

39 | P a g e
 Figure 4: Body Temperature Displayed

The following is a sms alert sent to the care giver’s phone in case threshold is exceeded.
5 CONCLUSION

Use of wireless technologies and more so the GSM based patient monitoring system could have a
great impact in medical applications since it can provide long term, real time and nonobstructive
medical supervision to the patients. Therefore, this wireless technology effectively enhances the
quality of life and reduces of burden cost especially in the hospitals and nursing care homes for the
old. The challenge of limited bed space in the hospital wards can also be effectively reduced by
the adoption of this system. By the use of the system, the patients can be monitored continuously

40 | P a g e
even after they have been discharged to go home or any other places that could be far from the
doctors, nurses or any other healthcare providers.
For demonstration, I developed a prototype of a GSM based patient monitoring system with a
number of sensors. Based on the results obtained from the project prototype, it was a clear
demonstration that the project achieved the objectives.
It was possible to interface the Arduino Uno board with three sensors (temperature, heart rate and
respiratory sensors) and a GSM module. The sensors were used to collect the temperature, heart
beat and respiratory status of a dummy patient and the information processed and displayed on a
16x2 LCD display. In case the above parameters at any point in time do not meet the given threshold
measurements they trigger the GSM to send an alarm text message to the GSM mobile phone
number given so as to alert the care giver and prompt him/her to respond appropriately. All the
interfacing of the involved components was achieved through the programming using the Arduino
software.
This Project was aimed at producing a better system in terms of coverage of the communication
equipment and also cut on the cost to come up with a cheap system. This was achieved by the use
of the GSM technology instead of the Bluetooth and Wi-Fi technologies that have been used in the
past that are quite limited.

6 Challenges
Although we were successful in the use of cheap sensors, they face a limitation of low accuracy and
susceptibility to noise from the surrounding environment. The heartbeat sensor which uses infra-red
technology is affected by radiations from the surrounding environment so that it will keep
incrementing the values obtained even without introducing the required parameter. We also faced
the challenge of lack of the right sensor for measuring the respiration rate of the patient, and were
forced to replace it with an alcohol sensor which did not serve as a perfect alternative. This was due
to unavailability of a small and cheap respiratory sensor; the ones available were bulky and too
expensive.

41 | P a g e
 7 Recommendation
To be able to successfully commercialize the device for use by the public, some improvements
should be considered so as to bring in more vitals parameters and by so doing make it more
valuable to the patients. This can be achieved by bringing in more sensors in order to
comprehensively be able to monitor the patients.
There is need for better sensors to be used in place of the ones used in this project due to the challenge
of inaccuracy and low immunity to noise from the surrounding leading to poor results .

8 References
1 cho, D.-k., 2015. opportunistic Medical monitoring using bluetooth p2p networks. IEE, 12 10, pp.
4450.
2 Dublin, 2021. Global Remote Patient Monitoring Markets, 2020-2021 & Forecast to 2025 -
ResearchAndMarkets.com, s.l.: BusinessWire.

3 purnima, p. s., 2014. Zigbee and GSM Based patient Health Monitoring System. India, ICECS.

4 Rishahb Jain, 2018. IoT Based Patient Health Monitoring System using ESP8266 and Arduino. circuit
digests, 20 september, pp. 20-40.

5 Zhuang, H. .. T. C. a. W. .., 2016. bluetooth-enabled in-home patient monitoring system. IEEE Wireless
Communications, 10 february, pp. 74-79.

9 APPENDIX
Programming source code
initialize the library instance
#include <OneWire.h>
#include "SIM800.h"
#include <SoftwareSerial.h>
#include <LiquidCrystal.h>
#include "sms.h"
SMSGSM sms;

LiquidCrystallcd(7, 8, 9, 10, 11, 12);

// Temp Data
bytei; byte present
= 0; bytetype_s;
byte data[12];
byteaddr[8];
floatcelsius, fahrenheit;

42 | P a g e
OneWire ds(5); // on pin 10 (a 4.7K resistor is necessary)

char text[]="System Online"; //SMS to send

intnumdata; boolean started=false;
charsmsbuffer[160]; char n[20];
inttempThreshold = 35; intbreaThreshold =
100; intalcoSensor; intheartRate;
int16_t raw = (data[1] << 8) | data[0];

void setup(void) {

lcd.begin(16, 2);
// Print a message to the LCD.
Serial.begin(9600);
// initialize serial communications and wait for port to open:
Serial.begin(9600);
Serial.println("GSM initialization");
Serial.println("Loading phone number...");
Serial.println("Initializing number ");
Serial.println("Auto_Check mode...");
lcd.setCursor(0,0); lcd.print("Patient
Alert Systm");
lcd.setCursor(0,1); // Set LCD cursor position (column 0, row 0)
lcd.print("System Config...");
// Start GSM shield
Serial.println("Patient Alert Systm");
//Start configuration of shield with baudrate. //For
http uses is raccomanded to use 4800 or slower. if
(gsm.begin(2400)) {
Serial.println("\nstatus=READY"); started=true;
} else Serial.println("\nstatus=IDLE");

if(started) {
lcd.setCursor(1,1); // Set LCD cursor position (column 0, row 0)
lcd.print("Sending ConfigMsg");
//Enable this two lines if you want to send an SMS. if
(sms.SendSMS("+254723513536", "System Activated"))
Serial.println("\nSMS sent OK");
lcd.setCursor(0,1); // Set LCD cursor position (column 0, row 0)
lcd.print("ConfigMessaga Sent");
} else
{
Serial.println("Not connected"); lcd.clear();

43 | P a g e
lcd.setCursor(0,1); // Set LCD cursor position (column 0, row 0)
lcd.print("CONNECTION ERROR");
delay(1000);
}
}

void loop(void) { alcoSensor =

analogRead(A0);
heartRate = analogRead(A1);
bytei; byte present = 0;
bytetype_s; byte data[12];
byteaddr[8];

if ( !ds.search(addr)) {
Serial.println("No more addresses.");
Serial.println();
ds.reset_search(); delay(250);
return;
}

Serial.print("ROM ="); for(i

= 0; i< 8; i++) {
Serial.write(' ');
Serial.print(addr[i], HEX);
}

if (OneWire::crc8(addr, 7) != addr[7]) {
Serial.println("CRC is not valid!"); return;
}
Serial.println();

// the first ROM byte indicates which chip

switch (addr[0]) { case 0x10:
Serial.println(" Chip = DS18S20"); // or old DS1820
type_s = 1; break; case 0x28:
Serial.println(" Chip = DS18B20");
type_s = 0; break; case 0x22:
Serial.println(" Chip = DS1822");
type_s = 0; break; default:
Serial.println("Device is not a DS18x20 family device."); return;
}

ds.reset(); ds.select(addr);
ds.write(0x44, 1); // start conversion, with parasite power on at the end

44 | P a g e
delay(1000); // maybe 750ms is enough, maybe not
// we might do a ds.depower() here, but the reset will take care of it.

present = ds.reset(); ds.select(addr);

ds.write(0xBE); // Read Scratchpad

Serial.print(" Data = ");

Serial.print(present, HEX); Serial.print("
");
for ( i = 0; i< 9; i++) { // we need 9 bytes
data[i] = ds.read(); Serial.print(data[i],
HEX);
Serial.print(" ");
}
Serial.print(" CRC=");
Serial.print(OneWire::crc8(data, 8), HEX);
Serial.println();

// Convert the data to actual temperature

// because the result is a 16 bit signed integer, it should //
be stored to an "int16_t" type, which is always 16 bits //
even when compiled on a 32 bit processor.
int16_t raw = (data[1] << 8) | data[0]; if
(type_s) {
raw = raw << 3; // 9 bit resolution default if
(data[7] == 0x10) {
// "count remain" gives full 12 bit resolution
raw = (raw & 0xFFF0) + 12 - data[6];
}
} else {
bytecfg = (data[4] & 0x60);
// at lower res, the low bits are undefined, so let's zero them if
(cfg == 0x00) raw = raw & ~7; // 9 bit resolution, 93.75 ms else
if (cfg == 0x20) raw = raw & ~3; // 10 bit res, 187.5 ms else if
(cfg == 0x40) raw = raw & ~1; // 11 bit res, 375 ms
//// default is 12 bit resolution, 750 ms conversion time
}
celsius = (float)raw / 16.0; fahrenheit
= celsius * 1.8 + 32.0;
Serial.print(" Temperature = ");
Serial.print(celsius);
Serial.print(" Celsius, ");

45 | P a g e
Serial.print(fahrenheit);
Serial.println(" Fahrenheit");
lcd.clear(); lcd.setCursor(0,0);
lcd.print("Patient Alert Systm");
//Serial.print(" Temperature = ");
lcd.setCursor(0,1); // Set LCD cursor position (column 0, row 0)
lcd.print("Temperature: ");
lcd.setCursor(12,1); // Set LCD cursor position (column 0, row 0)
lcd.print(celsius); lcd.setCursor(16,1); lcd.print("Celsius"); // Serial.print(celsius);

//Serial.println(" Alcohol = ");

lcd.setCursor(0,2); // Set LCD cursor position (column 0, row 0)
lcd.print("Respiraxon Stat: ");
lcd.setCursor(17,2); // Set LCD cursor position (column 0, row 0)
lcd.print(alcoSensor); lcd.setCursor(16,2); //Serial.print(alcoSensor);

// Serial.println(" Heart Rate = ");

lcd.setCursor(0,3); // Set LCD cursor position (column 0, row 0)
lcd.print("Heart Rate: ");
lcd.setCursor(11,3); // Set LCD cursor position (column 0, row 0)
lcd.print(heartRate); lcd.setCursor(16,3); lcd.print("BPM"); //Serial.print(heartRate);
delay(1000);
if(celsius>tempThreshold)
{
sms.SendSMS("+254723513536", "ubnormal temp");
}
if(alcoSensor>breaThreshold )
{
sms.SendSMS("+254723513536", "ubnormal temp");
}
}

46 | P a g e