iPacemaker IMPLANTABLE PACEMAKER WITH WI-FI AND GSM CONNECTIVITY

MAIN PROJECT REPORT

Submitted by NIDHISH ROY

LADVINE D ALMEIDA ELDHO JOSE DILEEP DINESH

in partial fulfillment for the award of the degree of

Bachelor of Technology
in ELECTRONICS AND BIOMEDICAL ENGINEERING

GOVERNMENT MODEL ENGINEERING COLLEGE Thrikkakara Cochin University of science and technology April 2013

GOVERNMENT MODEL ENGINEERING COLLEGE THRIKKAKARA KOCHI

DEPARTMENT OF ELECTRONICS & BIOMEDICAL ENGINEERING Cochin University of Science and Technology

BONAFIDE CERTIFICATE This is to certify that the project entitled Submitted by is a bonafide work done by them under our supervision.

Dr. Jessy John

HEAD OF DEPARTMENT & PROJECT GUIDE

Mrs. Sincy P S
PROJECT CO-ORDINATOR

ACKNOWLEDGEMENT
At this moment of accomplishment, we are presenting our work with great pride and pleasure, we would like to express our sincere gratitude to all those who helped us in the successful completion of project. First of all, we would like to thank our Principal Prof. Dr. V P Devassia, who provided us with all facilities and support for the development of our work. We would like to thank our project guide Dr. Jessy John, Head of Department of Electronics and Biomedical Engineering for helping us in the successful accomplishment of this project. We would also like to thank our coordinator Mrs. Sincy P S, Assistant professor who gave us constant guidance and support throughout this journey of turbulence. We also thank Mrs. Bella, Mrs. Geethu, Mrs. Vidhya Lab technicians, Department of Electronics and Biomedical Engineering for their constant support and encouragement for our project. We express our sincere thanks to all our lecturers at the college, all our seniors and our entire batch mates for their constant support. Above all we thank almighty for the ever abiding kind blessings.

II

ABSTRACT

Our proposal is to improve the flexibility of the Implantable device (IMD) programming through the use of an embedded user friendly web interface stored in microcontroller which replaces use of software and a dedicated programmer for programming. The important feature is the Wi-Fi alliance complaint hardware which supports every wireless device to establish connection with the IMD. Global system for mobiles (GSM) connectivity can be used in absence of Wi-Fi in remote areas helping in Telemetry. Wireless protection in case of WiFi is enabled through WPA2 security with AES Encryption and HTML Web interface which has inherent security capabilities. Significant power saving has been implemented in project through power down modes.

III

TABLE OF CONTENTS

SL NO.

TOPIC LIST OF FIGURES

PAGE NO. VII

LIST OF TABLES

IX

LIST OF SYMBOLS AND ABBREVATIONS

1. 2. 3. 4.

INTRODUCTION STATE OF ART TECHNOLOGY LITERATURE REVIEW RELATED THEORY 4.1 TYPES OF PACEMAKERS 4.1.1 VENTRICULAR PACING 4.1.1.1 VENTRICULAR ASYNCHRONOUS 4.1.1.2 VENTRICULAR INHIBITED 4.1.1.3 VENTRICULAR TRIGGERED 4.1.2 ATRIAL PACING SYSTEMS 4.1.2.1 ATRIAL ASYNCHRONOUS 4.1.2.2 ATRIAL INHIBITED

1 3 4

5 5 5 6 6 6 6 7

IV

4.1.2.3 ATRIAL TRIGGERED 4.1.3 DUAL CHAMBER PACING SYSTEMS 4.1.3.1 AV SYNCHRONOUS 4.1.3.2 ATRIAL SYNCHRONOUS 4.2 PACING THE UPSI CODE 4.3 ARDUINO 4.4 WI-FI 4.5 OSI MODEL 4.6 HYPERTEXT TRANSFER PROTOCOL 4.7 DEVICE FIRMWARE 4.8 GSM 4.9 COSM 5. DESIGN OF WORK 5.1 BLOCK DIAGRAM OF CIRCUIT 5.2 BLOCK LEVEL TREATMENT 5.2.1 ECG ACQUISITION CIRCUIT 5.2.1.1 INSTRUMENTATION AMPLIFIER 5.2.1.2 LOW PASS FILTER 5.2.1.3 HIGH PASS FILTER 5.2.2 QRS DETECTION CIRCUIT

7 7 7 7 8 8 10 12 16 19 20 21

23 23 23 24 26 28 29

5.2.2.1 BAND PASS FILTER 5.2.2.2 PRECISION RECTIFIER 5.2.2.3 PEAK DETECTOR AND COMPARATOR 5.2.3 PROCESSING AND PACING CIRCUITRY 5.2.4 ARDUINO WIFI SHEILD 5.2.5 GSM MODULE 5.3 PCB DESIGN 5.3.1 PROCESSING AND PACING CIRCUIT 5.3.2 ECG ACQUISITION 5.4 FLOW CHART OF DEVICE 5.4.1 FLOW CHART OF PACING CIRCUIT 5.4.2 FLOW CHART OF COMMUNICATION CIRCUIT 5.5 USER INTERFACE 5.5.1 HOME PAGE 5.5.2 SETTINGS PAGE 5.5.3 LIVE ECG 5.5.4 DATA LOG 6. IMPLEMENTATION 6.1 SYSTEM REQUIREMENTS 6.2 HARDWARE REQUIREMENTS

31 32 32 33 34 36 38 39 39 40 40 40 42 42 43 43 44 45 45 45

VI

6.3 SOFTWARE REQUIREMENTS 6.4 TESTING AND RESULTS 7. 8. CONCLUSION FUTURE WORKS REFERENCES APPENDIX A - COMMUNICATION PROGRAM APPENDIX B PACING PROGRAM APPENDIX C HTML HOME PAGE APPENDIX D HTML SETTINGS PAGE APPENDIX E HTML DATALOG PAGE APPENDIX F ATMEGA328P DATASHEET

45 47 49 50 51 52 59 62 64 66 68

VII

LIST OF FIGURES

FIGURE 4.1 FIGURE 4.2 FIGURE 4.3 FIGURE 4.4 FIGURE 4.5 FIGURE 4.6 FIGURE 4.7 FIGURE 4.8 FIGURE 5.1 FIGURE 5.2 FIGURE 5.3 FIGURE 5.4 FIGURE 5.5 FIGURE 5.7 FIGURE 5.8 FIGURE 5.9 FIGURE 5.10 FIGURE 5.11 FIGURE 5.12

VENTRICULAR ASYNCHRONOUS VENTRICULAR INHIBITED VENTRICULAR TRIGGERED ATRIAL ASYNCHRONOUS ATRIAL INHIBITED ATRIAL TRIGGERED ATRIO-VENTRICULAR SYNCHRONOUS ATRIAL SYNCHRONOUS IPACEMAKER BLOCK DIAGRAM ECG ACQUISITION BLOCK ECG ACQUISITION CIRCUIT AD620 INTERNAL DIAGRAM AD620 PINOUT LOW PASS FILTER LM741 PINOUT HIGH PASS FILTER GAIN STAGE QRS DETECTION BLOCK QRS DETECTION CIRCUIT

6 6 6 6 7 7 7 8 23 23 24 25 26 27 27 28 29 30 30

VIII

FIGURE 5.13 FIGURE 5.14 FIGURE 5.15 FIGURE 5.16 FIGURE 5.17 FIGURE 5.18 FIGURE 5.19 FIGURE 5.20 FIGURE 5.21 FIGURE 5.22 FIGURE 5.23 FIGURE 5.24 FIGURE 5.25 FIGURE 5.26 FIGURE 5.27 FIGURE 5.28 FIGURE 5.29 FIGURE 5.30 FIGURE 5.31 FIGURE 5.32

LM324 PINOUT BANDPASS CIRCUIT PRECISION RECTIFIER PEAK DETECTOR AND COMPARATOR PROCESSING AND PACING CIRCUIT ARDUINO WI-FI SHEILD GSM MODULE PCB FOR PACING AND PROCESSING PCB FOR ECG CIRCUIT FLOW CHART FOR PACING FLOW CHART FOR COMMUNICATION HOME PAGE SETTINGS PAGE LIVE ECG DATA LOG FULL CIRCUIT DIAGRAM ECG ACQUISITION HARDWARE ECG ON CRO QRS DETECTION AND PACING HARDWARE PACING OUTPUT

31 31 32 33 33 35 38 39 39 40 41 42 43 44 44 46 47 47 47 47

IX

LIST OF TABLES

TABLE 1 TABLE 2

PACING INDICATION STD. VALUE GAIN RESISTORS FOR AD620

5 25

LIST OF SYMBOLS AND ABBREVIATIONS

fc
Af WPA DSSS OFDM ISM MAC IMD Q UART FTDI

Centre Frequency Feedback Gain WiFi Protected Access Direct Sequence Spread Spectrum Orthogonal Frequency Division Multiplexing Industrial Scientific and Medical Band Medium Access Control Implantable Device Figure of Merits Universal Asynchronous Receive Transmit Future Technology Devices International

Chapter 1 INTRODUCTION
Artificial pacemaker is one of the modern marvels in the medical science. Electronic pacemakers play a vital role in todays society, providing approximately half a million people with a better quality and prolonged life. Numerous advancements have been made in pacemaker technology over the last fifty years, making current pacemakers highly sophisticated cardiac rhythm managers capable of correcting a myriad of complex heart abnormalities. The primary function of a typical pacemaker is to sense a persons heartbeat, and pace the heart via electric stimulation when irregularities are detected. This is accomplished in many different ways due the variances found in heart conditions. A pacemaker uses electrical impulses, delivered by electrodes contacting the heart muscles, to regulate the beating of the heart. Pacemakers find applications, either because the heart's native pacemaker is not fast enough, or there is a block in the heart's electrical conduction system. Basic pacemaker consist of two parts, an electronic unit which generates stimulating impulses of controlled rate and amplitude, known as pulse generator; and the lead which carries electrical impulses from the pulse generator to the heart. Modern pacemakers are sophisticated electronic devices, capable of providing assistance on demand, i.e. when the excitatory and conductive system of the heart fails to operate normally. In order to accommodate specific patient needs, modern pacemakers can be programmed by setting particular parameters in such way that the resulting pacemaker therapy is optimal for the patient. Unfortunately, reprogramming a pacemaker is not an easy task: both sufficient time and knowledge of pacemaker functionality and possible pacemaker therapy must be available. It has been observed that due to a lack of one or both of these factors, in many patients, a given pacemaker therapy is suboptimal: in many implanted pacemakers even the original factory settings are kept unchanged. Today, the pacemaker technology is moving fast, and the role of software in pacemaker functioning is increasing, yielding pacemaker devices that are almost annually enhanced in their capabilities. The iPacemaker is new generation implantable pacemaker that provides leading edge pacing technology through ECG sensing and QRS detection circuitry, Microcontrollers which runs software for pacing algorithms and user interface and wireless connectivity devices Wi-Fi and GSM for reprogramming the device.
1

A notable aspect of the project is the use of embedded web server stored in the microcontroller in replacement for the software to be installed on the computer for wireless device programming and monitoring. WPA2 security for Wi-Fi with AES encryption provides solid protection for the device. The embedded web interface in microcontroller is designed using HTML3.0. The HTML 3.0 specification provides a number of new features, and is broadly backwards compatible with HTML 2.0. Moreover, HTML 3.0 adds relatively little complexity to a browser making it suitable for embedded applications. GSM facility in the device improves its scope to be programmed anywhere with SMS containing pacing parameters code and password. It also helps the doctor to view the status of the device and patient conditions from remote areas which paves the way for Telemetry. The Real-time monitoring of the device world-wide over the internet is implemented through COSM interface. COSM, formerly pachube provides software as a service (SaaS) for monitoring sensor networks. The project is developed using Arduino technology which is a new open-source physical computing platform which is simple, cheap and has extensible hardware and software support. In short, our project provides a viable solution to problems existing in life-saving implantable devices and delivers a sophisticated device to improve the life conditions of millions of cardiac patients over the world.

Chapter 2 STATE OF ART TECHNOLOGY

Cardiac pacemakers often requires replacement or reprogramming since ICD can be subject to malfunction, instability issues or variations in pacing parameters. Existing pacemaker systems make use of wireless programmer stand alone or networked with a computer for programming the implanted device. These programming devices normally includes display screen, keyboard, programming head that provides communication link between the programmer and the patients implantable device through RF transmission, Electrode leads for ECG acquisition, etc. Various facilities implemented in the programmer include viewing patient ECG, collecting diagnostic data, evaluating parameter settings, programming pacemaker parameters and rate responsive setup. Currently using pacemakers possess a disadvantage that a dedicated programmer with its associated programmer is required for programming the device greatly affecting the flexibility of reprogramming and monitoring of the device. Maintaining an assured permanent connectivity with the device helps in monitoring of device anywhere over the world and thereby improves the lifestyle conditions of the patient. The solution proposed to overcome the above disadvantages include the use of webserver embedded in the microcontroller which provides options for checking the overall status of the device, monitoring of the patient ECG, reprogramming the implanted device etc., Moreover assured connectivity with the device can be established through making use of GSM facility allowing the device to be monitored by sending an SMS containing request code. The power utilisation came to be a significant issue when wireless connectivity is provided for the device, However many power-down modes already present in GSM and Wi-Fi helps in handling these issues.

Chapter 3 LITERATURE REVIEW

The goal of pacemaker follow-up is not only to predict the end-of-life (EOL) of the pulse-generator but also to detect malfunctions and optimize pacing system performance and longevity. In the prospective study conducted by regional university general hospital of patras in the paper A Long Term Follow-up of Patients with a Permanent Pacemaker: Necessity of Specific Programmer, they evaluated the effectiveness of pacemaker follow-up with the use of magnet rate measured by the miniclinic compared with a complete set of tests using pacemaker programmers, in the absence of a trans telephonic monitoring. They analysed the possible pacemaker dysfunction-related symptoms, the device malfunctions, and the necessity for specific parameter corrections. [1] Motivated by desire to improve patient safety, and mindful of conventional tradeoffs between security and power consumption for resource constrained devices, the study conducted in the thesis Pacemakers and Implantable Cardiac Debrillators: Software Radio Attacks and Zero-Power Defences introduced three new zero-power defences based on RF power harvesting. Studies conducted by them shows that providing security and privacy on an IMD involves health risk factors and tight resource constraints. Another risk to IMD availability is excessive power consumption by mechanisms other than those needed for the devices primary function. Solution proposed by them in the situation is zero-power authentication that similarly harvests RF energy to power a cryptographically strong protocol that authenticates requests from an external device programmer at no cost to the battery. In general, security is more compact, discriminable, and most importantly, can be implemented in generalized networks such as Wi-Fi with zero power utilisation. In the article, Telemonitoring of the Pacemaker by Duke University Medical Centre, the implementation of Telemonitoring through GSM was suggested which could provide a practical substitute to the time-consuming and expensive in-office visits. However reliability is an issue here because of any interference caused by relying on most widely used and available network. [2]

Chapter 4 RELATED THEORY

The rhythmic beating of the heart is due to the triggering pulses that originate in an area of specialized tissue in the right atrium of the heart. This area is known as the sino-atrial node. In abnormal situations, if this natural pacemaker ceases to function or becomes unreliable or if the triggering pulses does not reach the heart muscles because of blocking by damaged tissues, the natural and normal synchronization of the heart action gets disturbed. When monitored, this manifests itself through a decrease in the heart rate and changes the ECG waveform. By providing external electrical stimulation impulses to the heart muscle, it is possible to regulate the heart rate. These impulses are given by an electronic instrument called a pacemaker. The basic operation of the pacing circuit is as follows. When the sensing part of the circuit does not sense any abnormality of the normal heart rhythm no signal will be sent from the microcontroller to pace and so nothing will happen and the switch will remain open. Once the sensing circuit notices the heart beat slowing down the

microcontroller will send a signal to the pacing circuit causing the switch to close and thus completing the circuit. This pulse can be programmed to be of various amplitudes and widths. These values for any specific person are determined in tests when pacemaker is first implanted. Once the heart goes back to a normal rhythm the switch opens and pacemaker gets ready for the next pulse. [3] The pulse amplitude as well as the pulse width has to be variable to account for physiological differences between people. The pulse amplitude has to be variable from between 1.2V to 7V. The timing is also incredibly important in delivering a pulse. A

pulse at the wrong time could cause the heart to go into ventricular fibrillation. Whether a pulse is administered as well as the timing of the pulse is controlled by the microcontroller.

4.1 TYPES OF PACEMAKERS 4.1.1 Ventricular Pacing Systems 4.1.1. 1VOO Ventricular Asynchronous In this mode the pacemaker stimulates at a fixed rate and voltage. There is no sensing and hence the pacemaker will continue to pace irrespective of the underlying

rhythm. The pacemaker will capture the heart if the impulse delivered falls outside the refractory period of the intrinsic beat.

Fig 4.1 Ventricular

Asynchronous

4.1.1. 2 VVI-Ventricular inhibited Spontaneous impulses are sensed and the subsequent output is stopped. If no spontaneous impulses occur the pacemaker will pace at the regular rate at which the pacemaker is set.

Fig 4.2 Ventricular Inhibited

4.1.1. 3VVT- Ventricular Triggered In this mode when a spontaneous ventricular intrinsic beat is seen the output of the pacemaker is delivered. It must be noted that the beat will not be fully captured by the pacemaker as the output delivered will fall in the refractory period of the intrinsic beat and make no contribution to the depolarisation of the heart (this is called a pseudo-fusion beat).

Fig 4.3 Ventricular Triggered

4.1.2 Atrial Pacing Systems 4.1.2. 1AOO Atrial Asynchronous This mode is rarely used. As in VOO, the pacemaker stimulates at a fixed rate irrespective of the underlying rhythm.

Fig 4.4 Atrial Asynchronous

4.1.2. 2AAI Atrial Inhibited This mode is the same as the VVI mode except the lead is positioned next to atrial myocardium and therefore the pacemaker will inhibit when an intrinsic atrial beat is seen.

Fig 4.5 Atrial Inhibited

4.1.2. 3AAT Atrial Triggered In this mode when a spontaneous atrial intrinsic beat is seen the output of the pacemaker is delivered. It must be noted that the beat will not be fully captured by the pacemaker as the output delivered will fall in the refractory period of the intrinsic beat and make no contribution to the depolarisation of the heart (this is called a pseudo-fusion beat).

Fig 4.6 Atrial Triggered

4.1.3 Dual Chamber Pacing Systems 4.1.3.1 DOO AV Synchronous The D in the USCI code stands for dual, meaning atria and ventricle. In this instance, both chambers are paced at a fixed rate with no sensing, irrespective of the underlying rhythm. This mode is rarely used and can be seen with application of a magnet on most DDD pacemaker models.

Fig 4.7 Atrio-ventricular Synchronous

4.1.3. 2Atrial Synchronous (VAT) This mode occurs when the atrial intrinsic rate is sensed and the ventricular chamber is paced. The pacemaker output is triggered to a sensed event, that event being a
7

sinus P wave. In this way AV synchrony is maintained and the response will be physiological because it will follow the intrinsic rate of the sinus node.

Fig 4.8 Atrial Synchronous

4.2 PACING THE USCI CODE The USCI code is the standard code for labelling the mode of pacing. 1 letter chamber(s) paced 2 letter chamber(s) sensed 3 letter Mode of action Either the atria or ventricles can be paced and hence either pure atrial, pure ventricular or both atrial and ventricular pacing can be employed. Therefore modes of AAI, VVI, VVT, VAT, DDI, DDD and others may be chosen. The mode of action is either inhibited (I), where the pacemaker will suppress its output if an intrinsic beat is seen or triggered (T), where the output of a pacemaker is triggered to a sensed event.[4] The revised code is as follows: I Chamber(s) paced O = None A = Atrium II Chamber(s) sensed O = None A = Atrium III Response to sensing O = None T = Triggered O = None R = Rate modulation V = Ventricle D = Dual (A+V) V = Ventricle D = Dual (A+V) I = Inhibited D = Dual (A+V)
Table 1 Pacing indication
rd nd st

IV Rate modulation

V Multisite pacing O = None A = Atrium

V = Ventricle D = Dual (A+V)

4.3 ARDUINO Arduino is an open source electronic prototyping platform based on flexible, easy to use hardware and software. The hardware consists of a simple open hardware design
8

for the Arduino board with an Atmel AVR processor and on-board input/output support. The software consists of a standard programming language compiler and the boot loader that runs on the board. Arduino can sense the environment by receiving input from a variety of sensors and can affect its surroundings by controlling lights, motors, and other actuators. The microcontroller on the board is programmed using the arduino programming language (based on Wiring) and the Arduino development environment (based on Processing). Arduino projects can be stand-alone or they can communicate with software running on a computer (e.g. Flash, Processing, MaxMSP).The boards can be built by hand or purchased preassembled. 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. An important aspect of the Arduino is the standard way that connectors are exposed, allowing the CPU board to be connected to a variety of interchangeable add-on modules known as shields. Some shields communicate with the Arduino board directly over various pins, but many shields are individually addressable via an IC serial bus, allowing many shields to be stacked and used in parallel. Official Arduino have used the megaAVR series of chips, specifically the ATmega8, ATmega168, ATmega328, ATmega1280, and ATmega2560. A handful of other processors have been used by Arduino compatibles. Most boards include a 5 volt linear regulator and a 16 MHz crystal oscillator (or ceramic resonator in some variants), although some designs such as the LilyPad run at 8 MHz and dispense with the on-board voltage regulator due to specific form-factor restrictions. An Arduino's microcontroller is also pre-programmed with a boot loader that simplifies uploading of programs to the on-chip flash memory, compared with other devices that typically need an external programmer. Serial Arduino boards contain a simple level shifter circuit to convert between RS-232-level and TTL-level signals. Current Arduino boards are programmed via USB, implemented using USB-toserial adapter chips such as the FTDI FT232. Arduino hardware is programmed using a Wiring-based language (syntax and libraries), similar to C++ with some slight simplifications and modifications, and a Processing-based integrated development environment. [5]

Features Microcontroller Operating Voltage Input Voltage (recommended) Input Voltage (limits) Digital I/O Pins Analog Input Pins DC Current per I/O Pin DC Current for 3.3V Pin Flash Memory ATmega328 5V 7-12V 6-20V 14 (of which 6 provide PWM output) 6 40 mA 50 mA 32 KB (ATmega328) of which 0.5 KB used by boot loader

4.4 Wi-Fi Wi-Fi is a popular technology that allows an electronic device to exchange data wirelessly (using radio waves) over a computer network, including high-speed Internet connections. The Wi-Fi Alliance defines Wi-Fi as any "wireless local area network (WLAN) products that are based on the (IEEE) 802.11 standards". A device that can use Wi-Fi can connect to a network resource via a wireless network access point. Such an access point (or hotspot) has a range of about 20 meters indoors and a greater range outdoors. Hotspot coverage can comprise an area as small as a single room with walls that block radio waves or as large as many square miles this is achieved by using multiple overlapping access points. IEEE 802.11 is a set of standards for implementing wireless local area network (WLAN) computer communication in the 2.4, 3.6 and 5 GHz frequency bands. The 802.11 family consist of a series of half-duplex over-the-air modulation techniques that use the same basic protocol. The most popular are those defined by the 802.11b and 802.11g protocols, which are amendments to the original standard.802.11b and 802.11g use the 2.4 GHz ISM band and can control their interference and susceptibility to interference by using direct-sequence spread spectrum (DSSS) and orthogonal frequencydivision multiplexing (OFDM) signalling methods, respectively. 802.11a uses the 5 GHz U-NII band, which, for much of the world, offers at least 23 non-overlapping channels rather than the 2.4 GHz ISM frequency band, where adjacent channels overlap.
10

802.11b has a maximum raw data rate of 11 Mbit/s and uses the same media access method defined in the original standard. However, 802.11b devices suffer interference from other products operating in the 2.4 GHz band which include microwave ovens, Bluetooth devices, baby monitors, cordless telephones and some amateur radio equipment. 802.11g works in the 2.4 GHz band but uses the same OFDM based transmission. It operates at a maximum physical layer bit rate of 54 Mbit/s exclusive of forward error correction codes and has more immunity to interference. 802.11g hardware is fully backward compatible with 802.11b hardware. The communication through Wi-Fi is managed by four-layer set of protocols: the first manages the physical media where the connection is established, the second (Internet Protocol) allows exchange of basic data units called datagrams, then TCP (Transmission Control Protocol) provide reliable, connection- oriented, full-duplex streams. Finally there is an application layer that implements high level services. Each connected device is designated by a 32-bit number, usually written as four numbers separated by dots (eg. 158.110.1.3). To this number may also associate a name, composed by labels separated by dots (eg. hydrus.cc.uniud.it) through the DNS protocol (STD13). On a single computer, many connections may be active at the same time; to allow this; a port number is also associated to each connection. Some port number is reserved to specific application protocols allowing the easy retrieval of such applications. To send a message on a network, an application has to put its data in a structure called packet or datagram, and address them correctly. Every computer on the network can talk, as a peer, with any other computer. TCP/IP is a connectionless protocol. Information is transferred in packets. Each of these packets is sent through the network individually. On the basic TCP/IP protocol, other more abstract protocols application protocols- have been developed to carry out specific tasks; these protocols usually follow the client/server architecture. Client/server is a computational architecture that involves client processes requesting services from server processes. Client programs usually manage the user interface part of application; validate data entered by the user and send messages to a server program, requesting the server to perform a service. Server programs generally receive requests from client programs, perform tasks to satisfy the requests and send responses to clients. The server may run on another machine on the network, and manages shared resources such as data, devices and communication links. The

11

communication between client and server is carried out according to a set of precise rules called client- server protocol. [5] 4.5 OSI MODEL Every communication network follows OSI model - The Open Systems Interconnection (OSI) model (ISO/IEC 7498-1) is a product of the Open Systems Interconnection effort at the International Organization for Standardization. It is a prescription of characterizing and standardizing the functions of a communications system in terms of abstraction layers. Similar communication functions are grouped into logical layers. A layer serves the layer above it and is served by the layer below it. OSI had two major components: an abstract model of networking, called the Basic Reference Model or seven-layer model, and a set of specific protocols. There are seven layers, labelled 1 to 7, with layer 1 at the bottom. Each layer is generically known as an N layer. A service data unit (SDU) is a specific unit of data that has been passed down from an OSI layer to a lower layer, and which the lower layer has not yet encapsulated into a protocol data unit (PDU). An SDU is a set of data that is sent by a user of the services of a given layer, and is transmitted semantically unchanged to a peer service user. 1. The physical layer defines electrical and physical specifications for devices. In particular, it defines the relationship between a device and a transmission medium, such as a copper or fibre optical cable. This includes the layout of pins, voltages, line impedance, cable specifications, signal timing, hubs, repeaters, network adapters, host bus adapters (HBA used in storage area networks) and more. The major functions and services performed by the physical layer are: Establishment and termination of a connection to a communications medium. Participation in the process whereby the communication resources are effectively shared among multiple users. For example, contention resolution and flow control. Modulation or conversion between the representation of digital data in user equipment and the corresponding signals transmitted over a

communications channel. These are signals operating over the physical cabling (such as copper and optical fibre) or over a radio link.

12

Parallel SCSI buses operate in this layer, although it must be remembered that the logical SCSI protocol is a transport layer protocol that runs over this bus. Various physical-layer Ethernet standards are also in this layer; Ethernet incorporates both this layer and the data link layer. The same applies to other local-area networks, such as token ring, FDDI, ITU-T G.hn and IEEE 802.11, as well as personal area networks such as Bluetooth and IEEE 802.15.4. 2. The data link layer provides the functional and procedural means to transfer data between network entities and to detect and possibly correct errors that may occur in the physical layer. Originally, this layer was intended for point-to-point and point-to-multipoint media, characteristic of wide area media in the telephone system. Local area network architecture, which included broadcast-capable multiaccess media, was developed independently of the ISO work in IEEE Project 802. The ITU-T G.hn standard, which provides high-speed local area networking over existing wires (power lines, phone lines and coaxial cables), includes a complete data link layer which provides both error correction and flow control by means of a selective repeat Sliding Window Protocol. The functions of data link layer: 3. Framing Physical Addressing Flow Control Error Control Access Control Media Access Control(MAC)

The network layer provides the functional and procedural means of transferring variable length data sequences from a source host on one network to a destination host on a different network (in contrast to the data link layer which connects hosts within the same network), while maintaining the quality of service requested by the transport layer. The network layer performs network routing functions, and might also perform fragmentation and reassembly, and report delivery errors. Routers operate at this layer, sending data throughout the extended network and making the Internet possible. [5] The network layer may be divided into three sub layers:

13

1) Sub network access that considers protocols that deal with the interface to networks, such as X.25; 2) Sub network-dependent convergence when it is necessary to bring the level of a transit network up to the level of networks on either side. 3) Sub network-independent convergence handles transfer across multiple networks. A number of layer-management protocols, a function defined in the Management Annex, ISO 7498/4, belong to the network layer. These include routing protocols, multicast group management, network-layer information and error, and network-layer address assignment. It is the function of the payload that makes these belong to the network layer, not the protocol that carries them. 4. The transport layer provides transparent transfer of data between end users, providing reliable data transfer services to the upper layers. The transport layer controls the reliability of a given link through flow control, segmentation/desegmentation, and error control. Some protocols are state-and connection-oriented. This means that the transport layer can keep track of the segments and retransmit those that fail. The transport layer also provides the acknowledgement of the successful data transmission and sends the next data if no errors occurred. Tunnelling protocols operate at the transport layer, such as carrying non-IP protocols such as IBM's SNA or Novell's IPX over an IP network, or end-to-end encryption with IPsec. While Generic Routing Encapsulation (GRE) might seem to be a network-layer protocol, if the encapsulation of the payload takes place only at endpoint, GRE becomes closer to a transport protocol that uses IP headers but contains complete frames or packets to deliver to an endpoint. L2TP carries PPP frames inside transport packet. [5] Although not developed under the OSI Reference Model and not strictly conforming to the OSI definition of the transport layer, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) of the Internet Protocol Suite are commonly categorized as layer-4 protocols within OSI. 5. The session layer controls the dialogues (connections) between computers. It establishes, manages and terminates the connections between the local and remote application. It provides for full-duplex, half-duplex, or simplex operation, and establishes check pointing, adjournment, termination, and restart procedures. The OSI model made this layer responsible for graceful close of sessions, which is a
14

property of the Transmission Control Protocol, and also for session check pointing and recovery, which is not usually used in the Internet Protocol Suite. The session layer is commonly implemented explicitly in application environments that use remote procedure calls. 6. The presentation layer establishes context between application-layer entities, in which the higher-layer entities may use different syntax and semantics if the presentation service provides a mapping between them. If a mapping is available, presentation service data units are encapsulated into session protocol data units, and passed down the stack. This layer provides independence from data representation (e.g., encryption) by translating between application and network formats. The presentation layer transforms data into the form that the application accepts. This layer formats and encrypts data to be sent across a network. It is sometimes called the syntax layer. The original presentation structure used the Basic Encoding Rules of Abstract Syntax Notation One (ASN.1), with capabilities such as converting an EBCDIC-coded text file to an ASCII-coded file, or serialization of objects and other data structures from and to XML. [5] 7. The application layer is the OSI layer closest to the end user, which means that both the OSI application layer and the user interact directly with the software application. This layer interacts with software applications that implement a communicating component. Such application programs fall outside the scope of the OSI model. Application-layer functions typically include identifying

communication partners, determining resource availability, and synchronizing communication. When identifying communication partners, the application layer determines the identity and availability of communication partners for an application with data to transmit. When determining resource availability, the application layer must decide whether sufficient network or the requested communication exists. In synchronizing communication, all communication between applications requires cooperation that is managed by the application layer. Some examples of application-layer implementations also include: On OSI stack: o FTAM File Transfer and Access Management Protocol o X.400 Mail
15

o Common Management Information Protocol (CMIP) On TCP/IP stack: o Hypertext Transfer Protocol (HTTP), o File Transfer Protocol (FTP), o Simple Mail Transfer Protocol (SMTP) o Simple Network Management Protocol (SNMP). Neither the OSI Reference Model nor OSI protocols specify any programming interfaces, other than as deliberately abstract service specifications. Protocol specifications precisely define the interfaces between different computers, but the software interfaces inside computers, known as network sockets are implementationspecific. For example Microsoft Windows' Winsock, and Unix's Berkeley sockets and System V Transport Layer Interface, are interfaces between applications (layer 5 and above) and the transport (layer 4). NDIS and ODI are interfaces between the media (layer 2) and the network protocol (layer 3). [5]

4.6 HYPERTEXT TRANSFER PROTOCOL (HTTP) The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. [1] Hypertext is a multi-linear set of objects, building a network by using logical links (the so-called hyperlinks) between the nodes (e.g. text or words). HTTP is the protocol to exchange or transfer hypertext. The standards development of HTTP was coordinated by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), culminating in the publication of a series of Requests for Comments (RFCs), most notably RFC 2616, which defines HTTP/1.1, the version of HTTP in common use. HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body. A web browser is an example of a user agent (UA). Other types of user agent include the indexing software used by search providers (web crawlers), voice browsers, mobile apps and other software
16

that accesses, consumes or displays web content. HTTP is designed to permit intermediate network elements to improve or enable communications between clients and servers. High-traffic websites often benefit from web cache servers that deliver content on behalf of upstream servers to improve response time. Web browsers caches previously accessed web resources and reuse them when possible to reduce network traffic. HTTP proxy servers at private network boundaries can facilitate communication for clients without a globally routable address, by relaying messages with external servers. HTTP is an application layer protocol designed within the framework of the Internet Protocol Suite. Its definition presumes an underlying and reliable transport layer protocol and Transmission Control Protocol (TCP) is commonly used. However HTTP can use unreliable protocols such as the User Datagram Protocol (UDP), for example in Simple Service Discovery Protocol (SSDP). HTTP resources are identified and located on the network by Uniform Resource Identifiers (URIs)or, more specifically, Uniform Resource Locators (URLs)using the http or https URI schemes. URIs and hyperlinks in Hypertext Mark-up Language (HTML) documents form webs of inter-linked hypertext documents. [1] HTTP/1.1 is a revision of the original HTTP (HTTP/1.0). In HTTP/1.0 a separate connection to the same server is made for every resource request. HTTP/1.1 can reuse a connection multiple times to download images, scripts, style sheets etc. after after the page has been delivered. HTTP/1.1 communications therefore experience less latency as the establishment of TCP connections presents considerable overhead. An HTTP session is a sequence of network request-response transactions. An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a server (typically port 80). An HTTP server listening on that port waits for a client's request message. Upon receiving the request, the server sends back a status line, such as "HTTP/1.1 200 OK", and a message of its own. The body of this message is typically the requested resource, although an error message or other information may also be returned. HTTP defines methods (sometimes referred to as verbs) to indicate the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server. The HTTP/1.0 specification defined the GET, POST and HEAD methods and the HTTP/1.1 specification added 5 new methods: OPTIONS, PUT, DELETE,
17

TRACE and CONNECT. By being specified in these documents their semantics are well known and can be depended upon. Any client can use any method and the server can be configured to support any combination of methods. If a method is unknown to an intermediate it will be treated as an unsafe and non-idempotent method. There is no limit to the number of methods that can be defined and this allows for future methods to be specified without breaking existing infrastructure. GET requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. HEAD asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. POST requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URL. The data Posted might be, as examples, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database. PUT requests that the enclosed entity be stored under the supplied URL. If the URL refers to an already existing resource, it is modified; if the URL does not point to an existing resource, then the server can create the resource with that URL. DELETE deletes the specified resource. TRACE echoes back the received request so that a client can see what (if any) changes or additions have been made by intermediate servers. An OPTION returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource. CONNECT converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy. PATCH Is used to apply partial modifications to a resource. HTTP servers are required to implement at least the GET and HEAD methods and, whenever possible, also the OPTIONS method. In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a
18

connection could be reused for more than one request. Such persistent connections reduce request latency perceptibly, because the client does not need to re-negotiate the TCP connection after the first request has been sent. Another positive side effect is that in general the connection becomes faster with time due to TCP's slow-start-mechanism. Version 1.1 of the protocol also made bandwidth optimization improvements to HTTP/1.0. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before waiting for each response. Another improvement to the protocol was byte serving, where a server transmits just the portion of a resource explicitly requested by a client. [1] There are three methods of establishing a secure HTTP connection: HTTP Secure, Secure Hypertext Transfer Protocol and the HTTP/1.1 Upgrade header. HTTP/1.1 Upgrade header is used for implementing security in our project. A client request (consisting in this case of the request line and only one header) is followed by a blank line, so that the request ends with a double newline, each in the form of a carriage return followed by a line feed. The "Host" header distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.

4.7 DEVICE FIRMWARE Programming can always be improved in virtually any system. There always exists the potential for problems due to the interpretation of compilers. Even a system which has been thoroughly tested can still have numerous problems waiting to surface under the right circumstances. Therefore it is our suggestion to investigate the code thoroughly, and perform numerous tests to verify correct functionality. One suggestion would be to use assembly language to implement the control functions. Lower level languages, although difficult to use, provide a more concrete solution. In electronic systems and computing, firmware is the combination of persistent memory and program code and data stored in it. Typical examples of devices containing firmware are embedded systems (such as traffic lights, consumer appliances, and digital watches), computers, computer peripherals, mobile phones, and digital cameras. The firmware contained in these devices provides the control program for the device. Firmware is held in non-volatile memory devices such as ROM, EPROM, or flash memory. Changing the firmware of a device may rarely or never be done during its economic lifetime; some firmware memory devices are permanently installed and cannot be changed after
19

manufacture. Common reasons for updating firmware include fixing bugs or adding features to the device. This may require physically changing ROM integrated circuits, or reprogramming flash memory with a special procedure. Firmware such as the ROM BIOS of a personal computer may contain only elementary basic functions of a device and may only provide services to higher-level software. Firmware such as the program of an embedded system may be the only program that will run on the system and provide all of its functions. [5] One improvement which could be made in programming would be to make all of the parameters obtained from the specifications fully programmable by the end user. That is, a simple user interface could be created to set the upper and lower rate limit, pulse amplitudes, etc. Any system which is to be used by people other than Engineers (Doctors in this case) should provide an intuitive and simple user interface. This is the largest downfall of many systems which are produced. 4.8 GSM GSM (Global System for Mobile Communications, originally Group Special Mobile), is a standard set developed by the European Telecommunications Standards Institute (ETSI) to describe protocols for second generation (2G) digital cellular networks used by mobile phones. GSM is a cellular network, which means that cell phones connect to it by searching for cells in the immediate vicinity. There are five different cell sizes in a GSM networkmacro, micro, pico, femto and umbrella cells. The GSM standard was developed as a replacement for first generation (1G) analog cellular networks, and originally described a digital, circuit switched network optimized for full duplex voice telephony. This was expanded over time to include data communications, first by circuit switched transport, then packet data transport via GPRS (General Packet Radio Services) and EDGE (Enhanced Data rates for GSM Evolution or EGPRS). Cell horizontal radius varies depending on antenna height, antenna gain and propagation conditions from a couple of hundred metres to several tens of kilometres. The longest distance the GSM specification supports in practical use is 35 kilometres. There are also several implementations of the concept of an extended cell, where the cell radius could be double or even more, depending on the antenna system, the type of terrain and the timing advance. [1] GSM was designed with a moderate level of service security. The system was designed to authenticate the subscriber using a pre-shared key and challenge-response.
20

Communications between the subscriber and the base station can be encrypted. The development of UMTS introduces an optional Universal Subscriber Identity Module (USIM), that uses a longer authentication key to give greater security, as well as mutually authenticating the network and the user whereas GSM only authenticates the user to the network (and not vice versa). The security model therefore offers confidentiality and authentication, but limited authorization capabilities, and no non-repudiation. The GSM network is structured into a number of discrete sections: The Base Station Subsystem (the base stations and their controllers). The Network and Switching Subsystem (the part of the network most similar to a fixed network). This is sometimes also just called the core network. The GPRS Core Network (the optional part which allows packet based Internet connections). The Operations support system (OSS) for maintenance of the network. The ETSI GSM 07.05 (3GPP TS 27.005) specifies AT style commands for managing the SMS feature of GSM. AT commands instructions used to control a modem. AT is the abbreviation of ATtention. Every command line starts with "AT" or "at". That's why modem commands are called AT commands. Many of the commands that are used to control wired dial-up modems, such as ATD (Dial), ATA (Answer), ATH (Hook control) and ATO (Return to online data state), are also supported by GSM/GPRS modems and mobile phones. Besides this common AT command set, GSM/GPRS modems and mobile phones support an AT command set that is specific to the GSM technology, which includes SMS-related commands like AT+CMGS (Send SMS message), AT+CMSS (Send SMS message from storage), AT+CMGL (List SMS messages) and AT+CMGR (Read SMS messages). [1]

4.9 COSM Cosm (formerly Pachube (pronounced Patch bay)) is an on-line database service allowing developers to connect sensor-derived data to the Web and to build their own applications based on that data. Cosm is a secure, scalable platform that connects devices and products with applications to provide real-time control and data storage. Cosm's provisioning service allows end users to pair their device with applications to control it or use its data. Cosm web service that enables you to store, share & discover real-time sensor, energy and environment data from objects, devices & buildings around the world.

21

The key aim is to facilitate interaction between remote environments, both physical and virtual. Apart from enabling direct connections between any two responsive environments, it can also be used to facilitate many-to-many connections: just like a physical "patch bay" (or telephone switchboard). Cosm manages millions of data points per day from thousands of individuals, organizations & companies around the world. Pachube stores, converts & serves data in multiple data formats, which makes it interoperable with both established web protocols & existing construction industry standards. [5] Cosm allows users to: 1. Embed real-time graphs & widgets in their website. 2. Analyse & process historical data pulled from any public Cosm feed. 3. Send real time alerts from any data stream to control your scripts, devices & environments. Out-of-the-box configurable tools include a zoomable graph, a mapping/tracking widget, an augmented reality viewer, SMS alerts & apps for various smartphones. 4. Build mobile & web apps that create value: With a rapid development cycle & dozens of code examples & libraries, Cosm's 'physical-to-virtual' API makes it possible to build applications that add value to networked objects & environments. 5. Share data & create communities: Cosm is built to encourage open ecosystems. Examples: electricity meters, weather stations, building management systems, air quality monitors, biosensors, Geiger counters. Cosm is not just a social networking project for sensor data. Cosm evolved out three strands of thought: 1. The geographical non-specificity of architecture these days as people live their lives in constant connection with people in remote spaces. 2. A desire to open up the production process of smart homes in reaction to current trends for placing the design and construction process solely in the hands of knowledgeable others. Cosm makes use of CSV and JSON, as well as of Extended Environments Markup Language (EEML), which extends the construction industry protocol IFC. An extensive RESTful API makes it possible to both serve and request data in all formats. Data can be pushed to Pachube using an HTTP PUT request (especially useful for those operating behind firewalls or with non-static URLs). [5]
22

Chapter 5 DESIGN OF WORK

5.1 BLOCK DIAGRAM OF THE CIRCUIT

BANDPASS FILTER

PRECISION RECTIFIER

UART

SIM300 MODEM
SIMLOCK K

SPI FLASH EEPROM POWER SUPPLY WLAN SIP

THRESHOLD SET QRS DETECTION CIRCUIT

LED

GSM MODULE

AT16 CONTROLLER FIRMWARE UPDATE PORT

SLAVE SELECT

RX
INSTRUMENTATION AMPLIFIER SECOND ORDER LOWPASS FILTER SECOND ORDER HIGHPASS FILTER ECG ACQUISITION XTAL INPUT BANDPA OSC PORT/ADC SS OUTPUT PORT AVR

TX
SPI

STATUS LED

USART ICSP PROGRAMMER

EEPROM

SPI

ARUDUINO WIFI SHIELD

MICROCONTROLLER

Pacing pin

Fig 5.1 iPacemaker Block Diagram

5.2 BLOCK LEVEL TREATMENT 5.2.1 ECG Acquisition circuit

Instrumentation Amplifier Amplifier

Low Pass Filter

High Pass Filter

Fig 5.2 ECG Acquisition Block

This stage is used to acquire the ECG signal from the body using electrodes. It consists of an instrumentation amplifier stage used to provide an initial gain to the signal & is made using IC AD620. One of features of the AD620 instrumentation amplifier is low current noise, this benefit allows its use in the Electrocardiography (ECG) monitors.
23

AD620 can improve the dynamic range for better performance when low bias current and low current noise coupled with the low voltage noise. It is followed by low pass and high pass filter which is used to remove 50 Hz power line interference & other unwanted noise from the signal.

Fig 5.3 ECG acquisition circuit 5.2.1.1 Instrumentation Amplifier

Fig 5.4 Instrumentation amplifier ECG waveform is an important source for persons health, such that atrial fibrillation can be detected by distortion in the p wave. Thus for correct evaluation of the persons ECG, a precise device is needed to make the measurement misinterpretations may prove fatal. For this reason the gain should be enough to make the signal observable, however, it should be not large enough to saturate the devices. The following diagram shows the internal diagram of AD620 which is useful in deriving the gain of the instrumentation amplifier.

24

Fig 5.5 AD620 internal diagram

AD620 as seen in fig 5.12 is made of three operational amplifiers. The resistances are precise thus it has great CMRR and can be used in commercial circuits. The resistance between the two inverting inputs of the input operational amplifiers is called as Rg. The resistance Rg defines the gain of the instrumentation amplifier such that for the input stage of the differential amplifier the differential gain is: GD = (1+2 R2 /RG) The lowest gain possible with the above circuit is obtained with RG completely open (infinite resistance), and that gain value is 1. For the total gain of the devices one can refer to the look up table given below.

Table 2 Standard values of gain for AD620

Features of AD620 The AD620 is a low cost, high accuracy instrumentation amplifier that requires only one external resistor to set gains of 1 to 1000. Furthermore, the AD620 features 8-lead SOIC and DIP packaging that is smaller than discrete designs, and offers lower power (only 1.3 mA max supply current), making it a good fit for battery powered, portable (or remote) applications.

25

1. Excellent DC performance 2. Low noise 3. Excellent AC specifications The pin out of AD620 is given in the figure below.

Fig 5.6 AD620 pin out

Design Gain= 200 From the above table, Standard value RG = 200 ~ 220 5.2.1.2 Low pass Filter A low pass filter is an electronic circuit that passes low frequency signals but attenuates (reduces the amplitude of) signals with frequencies higher than the cut-off frequency. The actual amount of attenuation for each frequency varies from filter to filter. It is sometimes called a high-cut filter, or treble cut filter when used in audio applications. Normally we using second order low pass filter for eliminating noise from the ECG signal. As with low-pass filters, high-pass filters have a rated cut-off frequency, above which the output voltage increases above 70.7% of the input voltage. The capacitive highpass filter's cut-off frequency can be found with the formula. F cut off = 1/2RC

26

Fig 5.7 Low pass filter The low pass filter and subsequent stages are designed using op-amp IC LM741. Features of LM741 The LM741 series are general purpose operational amplifiers which feature improved performance over industry standards like the LM709. 1. Over load protection on input and output. 2. No latch-up when the common-mode range is exceeded. The pin out of LM741 is given in the figure below.

Fig 5.8 LM741 pin out

Design Second Order Low Pass Filter f= 1/(2RC) Let f= 20 HZ, C= 0.1 F R=1/(2fC)= 1(2*3.14*20*0.1*10)= 83.69k~ 82k Let gain= 1
27

1+Rf/R1= 1 Rf/R1= 0 Let Rf = 0k Therefore cut off frequency become 20 HZ 5.2.1.3 High Pass Filter

Fig 5.9 High pass filter The High Pass Filter is the exact opposite to the low pass filter. This filter has no output voltage from DC (0Hz), up to a specified cut-off frequency (c) point. This lower cut-off frequency point is 70.7% or -3dB (dB = -20log Vout/Vin) of the voltage gain allowed to pass. The High pass filter is pulled up to Vcc. The frequency range "below" this cut-off point is generally known as the Stop Band while the frequency range "above" this cut-off point is generally known as the Pass Band. The cut-off frequency or -3dB point can be found using the formula, c = 1/(2RC) The phase angle of the output signal at c is +45. Generally, the high pass filter is less distorting than its equivalent low pass filter. High pass filter provides better operating capabilities of IC and elimination of DC drift from ECG signal due to noise, motion artefacts etc. Design Second Order High Pass Filter f= 1/2 (R2R3C2C3)1/2 Let C2= C3= 100F f= 1 HZ
28

R2= R3= R 1= 1/2*3.14*R*100*10 ^ - 6 R = 2.361 k ~ 2.2 k Therefore cut off frequency become 0.8 HZ 5.2.1.4 Intermediate stage amplifier Full gain cannot be provided in instrumentation amplifier stage or filter stages. Therefore it is necessary to provide a gain stage to provide proper amplification to signal. A gain = 1 + RF / Rin

Fig 5.10 Gain stage Design Let gain= 3.5 1+Rf/R1= 3.5 Rf/R1= 2.5 Let Rf = 5.6k Then R1= 2.2k

5.2.2 QRS Detection Block

Band-pass Filter

Precision Rectifier

Peak Detector & Comparator

Fig 5.11 QRS Detection Block

29

This stage is used to detect the QRS complex in an ECG signal. It consist of a Band-pass filter of centre frequency 17 Hz & bandwidth 6 Hz to separate QRS complex from the ECG signal. A precision rectifier that follows rectifies the negative half cycle. This is followed by a peak detector and a comparator. The threshold of QRS is set to 1/3rd of its own value by a voltage divider. These circuits are all made using IC LM324.

Fig 5.12 QRS detection circuit

Features of LM324 LM324 is a low power quad operational amplifier, it has these features: 1. Internally frequency compensated for unity gain 2. Large DC voltage gain 100 dB 3. Wide bandwidth (unity gain) 1 MHz (temperature compensated) 4. Wide power supply range: Single supply 3V to 32V. 5. Very low supply current drain (700 A)-essentially independent of supply voltage 6. Low input biasing current 45 nA (temperature compensated) 7. Low input offset voltage 2 mV and offset current: 5 nA 8. Input common-mode voltage range includes ground 9. Differential input voltage range equal to the power supply voltage 10. Large output voltage swing 0V to V+ 1.5) The pin out of LM324 is given in the figure below.

30

Fig 5.13 LM324 pin out

5.2.2. 1 Band-pass filter A band-pass filter is a circuit which is designed to pass signals only in a certain band of frequencies while attenuating all the bands outside it. The important parameters to be considered in a band-pass filter are high & low cut off frequency (fh&fl), the bandwidth (BW), the center-frequency (fc), center frequency gain & selectivity or Q. A narrow band-pass filter with multiple feedbacks is used here.

Fig 5.14Bandpass circuit

Design R3=Q/2fcCAf Bandwidth=6 hz Fc=17 hz Af=2 Let C5=C6=C7=C=.1f Q=fc/BW=2.83

31

R3=132.6k= 150k R9=Q/2fcC(2Q2-Af)=18k R4= Q/fcC=530k 5.2.2.2 Precision Rectifier The precision rectifier, which is also known as a super diode, is a configuration obtained with an operational amplifier in order to have a circuit behaving like an ideal diode and rectifier. It can be useful for high-precision signal processing.

Fig 5.15 Precision rectifier

An alternative version is given on the right. In this case, when the input is greater than zero, D3 is OFF and D1 is ON, so the output is zero because one side of R6 is connected to the virtual ground, and there is no current through it. When the input is less than zero, D3 is ON and D1 is OFF, and the output is like the input with an amplification of R6/R5. This circuit has the benefit that the op-amp never goes into saturation; but its output must change by two diode voltage drops (about 1.2V) each time the input signal crosses zero, so the slew rate of the operational amplifier, and its frequency response (gain-bandwidth product) still limit high frequency performance; especially for low signal levels although an error of less than 1% at 100kHz is possible. 5.2.2. 3 Peak Detector & Comparator Peak detector is used for detecting peak levels of a signal. In the following circuit a capacitor keeps the peak voltage level of the signal; optionally, a switch can be used for resetting the detected level.

32

Fig 5.16 Peak Detector and Comparator circuit

Comparator used as a threshold detector, to detect heart beat event executed by the heart and generate a pulse with each QRS wave. Comparator is used compare a reference voltage of 1/3v of QRS with output of precision rectifier. If it exceeds the reference voltage then comparator will drive the microcontroller such that no pacing sign. 5.2.3 Processing and Pacing Circuitry

Fig 5.17 Processing and Pacing Circuitry

This section mainly includes two microcontrollers with headers for connection with the GSM and Wi-Fi module. First microcontroller is the central processing device for controlling the Wi-Fi and GSM module and providing parameters to the second microcontroller. The GSM Module (SIM300) is interfaced with the microcontroller through UART (Rx & Tx) and the Wi-Fi module interfaced through SPI containing SCK,MOSI,MISO,SS pins etc. The second microcontroller is used exclusively for pacing. This helps in removing any interruption caused during pacing due to device hangs, or when the microcontroller is busy with
33

transferring website or controlling GSM device etc. The power consumed is only a little by using Atmega microcontrollers.

5.2.4 Arduino Wi-Fi Shield The Arduino Wi-Fi Shield allows an Arduino platform developed device to connect wirelessly using the 802.11 wireless specifications (Wi-Fi). It is based on the HDG104 Wireless LAN 802.11b/g System in-Package. An Atmega 32UC3 provides a network (IP) stack capable of both TCP and UDP. Wi-Fi library helps to write sketches which make connections using the shield. The Wi-Fi Shield can connect to wireless networks which operate according to the 802.11b and 802.11g specifications. There is an on-board micro-SD card slot, which can be used to store files for serving over the network. The on-board micro SD card reader is accessible through the SD Library. When working with this library, SS is on Pin 4. Use the Wi-Fi library to write sketches which connect to the internet using the shield. The Wi-Fi shield connects to an Arduino board using long wire-wrap headers which extend through the shield. This keeps the pin layout intact and allows another shield to be stacked on top. [5] Features:

Connection via: 802.11b/g networks Encryption types: WEP and WPA2 Personal On-board micro SD slot FTDI-style connection for serial debugging of Wi-Fi shield Micro-USB for updating the Wi-Fi shield firmware Open source firmware making it possible to add new protocols directly on the shield.

The Wi-Fi Shield communicates with Arduino using the SPI bus (through the ICSP header), so is compatible with any of the boards that have this type of bus.

ICSP headers. Integrated antenna on the PCB. Operating voltage 5V (supplied from the Arduino Board). Use as a standalone Wi-Fi connected microcontroller.

34

Fig 5.18 Arduino Wi-Fi shield

35

Our device communicates with the Wi-Fi shield's processor using the SPI bus (through the ICSP header). HDG104 and SD card share the SPI bus, only one can be active at a time. Since both peripherals are used in our program, we used corresponding libraries to take care of SPI sharing problems. The shield can connect to encrypted networks that use either WPA2 Personal or WEP encryption or an open connection. Onboard Mini-USB connector can be used for updating the Atmega 32U using the Atmel DFU protocol. The programming jumper adjacent to the power bus and analog inputs should be left unconnected for typical use. It is only used for DFU programming mode. An on-board FTDI connection enables serial communication with the 32U for debugging purposes. The shield contains a number of informational LEDs: L9 (yellow): LINK (green): ERROR (red): DATA (blue): this is tied to digital pin 9 indicates a connection to a network indicates when there is a communication error indicates data being transmitted/received

5.2.5 GSM Module (SIM 300) The GSM Module allows an Arduino board to connect to the internet, make/receive voice calls and send/receive SMS messages. The shield uses a radio modem M10 by Quectel. It is possible to communicate with the board using AT commands. The GSM library has a large number of methods for communication with the shield. The module uses digital pins 2 and 3 for software serial communication with the M10. Pin 2 is connected to the M10s TX pin and pin 3 to its RX pin. [1] SIM300 is a Tri-band GSM/GPRS engine that works on frequencies EGSM 900 MHz, DCS 1800 MHz and PCS1900 MHz SIM300 provides GPRS multi-slot class 10 capabilities and support the GPRS coding schemes CS-1, CS-2, CS-3 and CS-4. It has a tiny configuration of 40mm x 33mm x 2.85 mm. The important features are the keypad and SPI LCD interface, two serial ports and two audio channels. SIM300 provide RF antenna interface with two alternatives: antenna connector and antenna pad. The antenna connector is MURATA MM9329-2700. The SIM300 is designed with power saving technique, the current consumption to as low as 2.5mA in SLEEP mode. The SIM300 is integrated with the TCP/IP protocol; Extended TCP/IP AT

36

commands are developed for customers to use the TCP/IP protocol easily, which is very useful for those data transfer applications. The shield supports AIN1 and AOUT1 as audio interfaces; an analog input channel and an analog output channel. The input, exposed on pins MIC1P/MIC1N, can be used for both microphone and line inputs. An electret microphone can be used for this interface. The output, exposed as lines SPK1P/SPK1N, can be used with either a receiver or speaker. Through the modem, it is possible to make voice calls. In order to speak to and hear the other party, you will need to add a speaker and microphone. The SIM300 is designed with power saving technique, the current consumption to as low as 2.5mA in SLEEP mode. [1] Specifications:

Available with SIM 300 and SIM 900 GSM/GPRS engine. Can be interfaced via RS 232 as well as TTL. Operates on 7-9 Volts AC or 9-12 Volts DC Power. Current Consumption: 250mA in normal operation may go to 2 Amps while transmission.

Supports Voice, Data/Fax, SMS, GPRS and integrated TCP/IP stack. Supports AT commands (GSM 07.07, 07.05 and enhanced AT commands). Pin out for RS 232 Tx/Rx, TTL Tx/Rx, VCC, GND, MIC, Speaker, Power On, and RTC.

Can configure Serial port baud rate between 1200 and 115200 bps (9600 default). All software version based on V10.0. The SIM300 dont provide the reset pin. When customer use SIM300 audio function, dont need use MIC bias. It may reduce the customers BOM. The speakers circuit is same as SIM100S.

Interfaces: RS-232 Interface with Hardware Flow Control support. (5 signals - TX, RX, RTS, CTS & GND through D-type 9 connector). Serial port baud rate adjustable 1200 to115200 BPS. 4 pin 0.1" connector for Speaker & Mic connection. 8-pin flip type reliable SIM card holder. DC socket for Power Adapter.
37

Rubber Duck GSM antenna or Magnetic Mount Antenna with approx. 3 metre cable. LED status for Power, Signal and Incoming Call.

Fig 5.19 SIM300 GSM Module

5.3 PCB DESIGN The software used for PCB design is DIPTRACE. The program consists of four main modules: Schematic Capture, PCB Layout, Component Editor and Pattern Editor. Schematic and PCB design modules have number of verification features that help control project accuracy on different design stages: The ERC function shows possible errors in Schematic pin connections using defined rules and allows you to correct errors step-by-step. DRC function checks the clearance between design objects, minimum size of traces, and drills. Errors are displayed graphically and we can fix them step-by-step and rerun the DRC in one click after any corrections. Net Connectivity Check verifies if all nets of PCB are electrically connected. This feature uses traces; copper pour filled area and shapes to control connectivity, then reports broken and merged nets with area details. Comparing to Schematic allows you to check if routed PCB is identical with Schematic.
38

5.3.1 Circuit Array containing Pacing, Processing and QRS Detection It is a single sided PCB with efficient placing of ICs for small size and reduced track-length. The track width is 0.03 inch. Elliptical pads have been laid with diameter of pads 0.07 inch and 0.088 inch. Tracks have angles of 45 degree or so (never 90 degree).

Fig 5.20 PCB for pacing, processing and QRS detection 5.3. 2 ECG Acquisition Circuit PCB design has the similar design conditions with the previously described PCB.

Fig 5.21 ECG Acquisition Circuit

39

5.4 FLOW CHART OF DEVICE SOFTWARE 5.4.1 Flow chart of pacing circuit

Accept pacing parameters

Cycle time = pacing interval

If mode=1

Yes

Output pin made high

Delay = pacing width

Output signal made low

No Yes
Delay within refractory period

If mode=3

If spontaneou s signal present

Yes

No

No

If mode= 2

Yes

If signal present ?

No

No

Yes

Fig 5.22 Flow

chart of pacing circuit

40

5.4.2 Flow chart of communication circuit

41

5.5 USER INTERFACE The user interface, in the industrial design field of humanmachine interaction, is the space where interaction between humans and machines occurs. The goal of this interaction is effective operation and control of the machine on the user's end, and feedback from the machine, which aids the operator in making operational decisions. The End-User interaction with the iPacemaker happens through HTML pages embedded in the micro-controller. There are four pages available for the user to interact with iPacemaker by monitoring and changing parameters. The four pages are Home page, Settings page, Live ECG, and Data log. Detailed descriptions about the pages are given below. The tabs above the web page allows to select different pages in the web interface. 5.5.1 Home page Home page gives complete information about the pacemaker which includes both general and technical information.

Fig 5.24 Home page

The General information includes patient name, age, hospital where pacemaker is implanted, consulted doctor etc. Moreover, various technical details about the pacemaker such as pacing rate, pacing voltage, pacing width, pacing voltage etc. Battery status demands much relevance among technical parameters.

42

5.5.2 Settings page Settings page can be used to change various parameters of the implant pacemaker. The figure below shows the settings page used to vary parameters of the pacemaker.

Fig 5.25 Settings page

The variable parameters inside the pacemaker includes pacing mode, voltage of pacing, pacing rate, pacing width, refractory period etc. If the parameters fall outside the valid limit, then they are automatically reverted to original value. The values are reflected inside microcontroller through GET request. 5.5.3 Live ECG The Live ECG is an important part of this project. The Live ECG allows real-time monitoring of ECG all over the world by logging in into COSM interface. COSM allows pushing and pulling XML, JSON and CSV data to secure and scalable RESTful API and socket-server for bi-directional interaction between devices and the web. Since only relevant data is sent, only low bandwidth internet connection is required.

43

Fig 5.26 Live ECG

The debugging mode in COSM interface helps to check connection with device. The facility to locate the device is already inherent in the interface. 5.5.4 Data log Data logging helps in viewing already logged data in the SD card. The Data is logged whenever doctor changes any parameter or critical events are detected.

Fig 5.27 Data log

RTC helps in logging data with time information.

44

Chapter 6

IMPLEMENTATION
6.1 System Requirements Two disposable surface electrodes Battery Central controller board Wi-Fi module GSM module

6.2 Hardware Requirements Battery (9v NiMH 48 pack) Capacity 2200mAh Configuration 3S1P-9v Peak discharge 30c Pack weight 185g Lead wire should be insulated Filters are provided for extracting QRS complex Same power source for Wi-Fi, GSM and Central board

6.3 Software Requirements Arduino ICSP programmer Arduino 1.03 UART to Serial cable for debugging.

45

46

6.4 Testing and results Different stages of the circuit and their implementation was shown below. The ECG acquisition circuit with AD620 is much small and have greater noise reduction capabilities. The completed hardware section for ECG acquisition is given below.

Fig 5.29 ECG acquisition hardware

The output from ECG acquisition circuit is given below.

Fig 5.30 Output (ECG) on a CRO

The QRS detection and processing circuitry is done on single pcb with minimum distance among components for smaller pcb. All sections work on single supply of +5V.

Fig 5.31 QRS detection and processing hardware

The output from the QRS detection and corresponding pacing based on mode is given below.

47

Fig 5.32 QRS pulse and corresponding pacing based on mode

The web interface (software-section) works normally without any bugs on many commonly used browsers such as firefox, chrome etc. No noticeable security issues were found.

48

Chapter 7 CONCLUSION
In short, our project aims at developing an implantable pacemaker which can be tailor made for different patients as it provides option for re-programmability. The Wi-Fi alliance compliant hardware supports almost every other wireless device to successfully establish connection with the device. The Embedded Web-Server replaces the existing technologies in pacemakers improving the flexibility of programming in a great way. User friendly interface allows doctor to view patient information, change device values, view logging etc., with much ease. GSM facilities have been provided for checking parameters and changing it in remote areas where Wi-Fi absent, helping in Telemetry. The State-of-Art technology was tested on debugging mode with serial interface by wirelessly connecting remote computers and reported no bugs. The pacing circuit works without any interruption and only minute offsets occur in pacing frequency which can be ignored with confidence.

49

Chapter 8 FUTURE WORKS

The continued innovation in programmability and telemetry is paving way for improving diagnostic capabilities of pacemakers. Systems are developing which can facilitate storing of patient details and which can diagnose rhythm disturbances using sophisticated algorithms. Sensors will be combined with electro-gram analysis to differentiate between physiological and pathological alterations in hemodynamic in such a way that appropriate adjustments can be initiated. Imparting some amount of intelligence in pacemakers is one way of improving the life conditions of cardiac patients. The daily activities including even lifting of arm produce a cardiac output. It is recommended that the pacemaker is adjusted accordingly to accommodate these body movements, so that the pacemakers rate will match the bodys activity. [1] Other suggestion for improving pacemakers is to allow them to be compatible with large magnetic fields. A patient needs to avoid large magnetic fields as they can cause pacemakers to reprogram its computer settings. One magnetic field that must be avoided is magnetic resonance imaging (MRIs). MRIs are the gold standard for medical imaging and current patients with pacemakers are unable to have a MRI. MRI compatible pacemakers are now on development process. [2] A development of much wider interest expected in the area is the implementation of specific MAC protocols for medical devices. This can considerably reduce the power consumption by the pacemakers by implementing specific modes like sleep mode, alarm modes and by resorting to specialised network topology. Power efficiency is an important requirement especially for a lifesaving implantable device working on battery. The most innovative future technology in pacemakers is the use of heart beats to power pacemakers. The "energy-harvesting" device would run on piezoelectricity or electricity by motion, and would require little power to operate. Researchers measured induced vibrations in the chest. They then used a "shaker" to reproduce the vibrations in the laboratory and connected it to a prototype cardiac energy harvester they developed. Measurements of the prototype's performance, based on a wide range of simulated heartbeats, showed the energy harvester generated more than 10 times the power required by modern pacemakers.

50

REFERENCES
[1] Louis S.Y.Wong, Shohan Hossain, Andrew Ta, Jorgenb Edvinsson, Dominic H.Rivas, Hans Nass, A very low power CMOS mixed signal IC for implantable pacemaker applications, in IEEE journal of solid state circuits,Vol.39,No.12 December 2004,pp.2446-2455. [2] Wikipedia, http://www.wikipedia.org [3] Nikolaos Kavvadis, Periklis Neofotistos, Spiridon Nikolaidis,C.A. Kosmatopoulos ,Theodore Laopoulos, Measurement Analysis of the software related power consumption in Microprocessors, in the proc. of IEEE transaction on instrumentation and measurement, Vol. 53,No.4,August 2004. [4] Vivek Tiwari, Sharad Malik, Andrew Wolfemike, Tien Chien Lee, Instruction level power analysis and optimization software, in proc.of 9 The international conference on VLSI design, January 1996.pp.326-328 [5] Arduino open-source, http://www.arduino.cc [6] Richard S. Sanders, Michel T. Lee, Implantable pacemakers, in proc. of IEEE, Vol.84, No.3, March 1996.pp.480-486.

51

APPENDIX-A PROGRAM COMMUNICATION

/************************************************************* IPACEMAKER- MICROCONTROLLER1 By ladvine,dileep,eldho,nidhish *************************************************************/ #include <SPI.h> #include <WiFi.h> #include <SD.h> char ssid[] = "iPacemaker"; char pass[] = "bombay123"; int status = WL_IDLE_STATUS; WiFiServerserver(80); File myFile; booleanHe_firsttime = true; booleanHo_firsttime = true; booleanSe_firsttime = true; unsigned long lastConnectionTime = 0; booleanlastConnected = false; const unsigned long postingInterval = 10*100; void setup() { Serial.begin(9600); Serial.print("Initializing SD card..."); pinMode(10, OUTPUT); pinMode(4, OUTPUT); digitalWrite(10, HIGH);
52

// Network SSID // Pass key // the Wifi radio's

// last time in mS //last connection time //delay of updates

// GSM "Baud Rate"

digitalWrite(4, HIGH); delay(30); if (!SD.begin(4)) { Serial.println("initialization failed!"); } else Serial.println("initialization done.");

if (WiFi.status() == WL_NO_SHIELD) { Serial.println("WiFi shield not present"); while(true); } // don't continue // attempt to connect to Wifi network:

while ( status != WL_CONNECTED) { Serial.print("Attempting to connect to Network named: "); Serial.println(ssid); status = WiFi.begin(ssid,pass); delay(1000); } server.begin(); IPAddressip = WiFi.localIP(); Serial.print("IP Address: "); Serial.println(ip); } /*************************************************************/ void loop() { WiFiClient client = server.available(); // listen for incoming clients if (client) {
53

// print the network name (SSID);

// start the web server on port 80

// you're connected now, so print ip address

Serial.println("new client"); String currentLine = ""; String para = ""; String Smode= ""; String Svolt= ""; while (client.connected()) { if (client.available()) { char c = client.read(); Serial.write(c); if (c == '\n') { // if the byte is a newline character // read a byte, then / / make a String to hold incoming data

// print it out the serial monitor

if(currentLine.length() == 0) { if((He_firsttime==true)) { He_firsttime=false; myFile = SD.open("Header1.txt"); while (myFile.available()) { client.write(myFile.read());delay(2); } myFile.close(); client.println(); break; } }

54

else { } } else if (c != '\r') { currentLine += c; } // add it to the end of the Line currentLine = "";

if((currentLine.endsWith("GET /?link=1 HTTP/1.1"))&&(Ho_firsttime==true)) { Ho_firsttime=false; myFile = SD.open("home.txt"); while (myFile.available()) { client.write(myFile.read());delay(2); } myFile.close(); } // HOME PAGE

if((currentLine.endsWith("GET/?link=2HTTP/1.1")&&(Se_firsttime==true)) { // SETTINGS PAGE Se_firsttime=false; myFile = SD.open("settings.txt"); while (myFile.available()) {

55

client.write(myFile.read());delay(2); } myFile.close(); }

if (currentLine.endsWith("GET /?link=3 HTTP/1.1")) { WiFiClient client; IPAddressserver(216,52,233,121); while(1) { intecg = analogRead(A2); if (!client.connected() &&lastConnected) { Serial.println(); Serial.println("disconnecting."); client.stop(); } if(!client.connected()&&(millis()lastConnectionTime>postingInterval)) { if (client.connect(server, 80)) { Serial.println("connecting..."); myFile = SD.open("home.txt"); while (myFile.available()) { client.write(myFile.read());delay(2); }
56

// LIVE ECG using COSM

myFile.close(); client.print("sensor1,"); client.println(ecg); } else { Serial.println("connection failed"); Serial.println(); Serial.println("disconnecting."); client.stop(); } lastConnectionTime = millis(); } lastConnected = client.connected(); }

if((currentLine.startsWith("GET/?Pa"))&&(currentLine.endsWith("Submit1=save "))) { para=currentLine; Smode=para.substring(16,17); if(Smode.equals("1")){analogWrite(A0,1);} if(Smode.equals("2")){analogWrite(A0,2);} if(Smode.equals("3")){analogWrite(A0,3);} Serial.println(); // HOME PAGE

57

Serial.println(Smode); Svolt=para.substring(26,27); if(Svolt.equals("1")){analogWrite(A1,1);} if(Svolt.equals("2")){analogWrite(A1,2);} if(Svolt.equals("3")){analogWrite(A1,3);} if(Svolt.equals("4")){analogWrite(A1,4);} if(Svolt.equals("5")){analogWrite(A1,5);} Serial.println(Svolt); Serial.println(para.substring(36,39)); Serial.println(para.substring(56,59)); } } } // close the connection client.stop(); Serial.println("client disonnected"); } }

58

APPENDIX-B PROGRAM PACING

constint QRS = 7; constint Pin = A0; intPinState = 0; unsigned long flag=0; longpreviousMillis = 0; longcurrentMillis; intQRSv; // will store last time of pacing // the pin where pacing occurs // initial pacing state

/****************************************************************/ int mode=3; int volt=5; intrfpd=150; // 1.NORMAL 2.VENT INHIBITED 3.VENT TRIGGERED // Pacing Voltage // Refractory period

/*****************************************************************/ void pacing(unsigned long interval1,unsigned long interval2) { if((currentMillis - previousMillis> interval1)&&(PinState == 0)) { previousMillis = currentMillis; PinState = volt; analogWrite(Pin, PinState); } currentMillis = millis(); if((currentMillis - previousMillis> interval2)&&(PinState == volt)) { previousMillis = currentMillis; PinState = 0; analogWrite(Pin, PinState);
59

} } /*************************************************/ void setup() { pinMode(QRS,INPUT); volt = map(volt,0,5,0,255); Serial.begin(9600); }

/*************************************************/ void loop() { mode=analogRead(A1); volt=analogRead(A2); Serial.println(mode); Serial.println(volt); if(mode==1) { pacing(835,5); } else { QRSv=0; flag=millis(); while (QRSv==0) //NORMAL PACING

60

{ QRSv=digitalRead(QRS); if((millis()-flag)>900)pacing(835,5); } if(mode==3) { delay((120%rfpd)); PinState = volt; analogWrite(Pin, PinState); delay(5); PinState = 0; analogWrite(Pin, PinState); } } } //VENTRICULAR TRIGGERED

61

APPENDIX-C HTML PAGE HOME

HTTP/1.1 200 OK Content-Type: text/html Connection: close <! DOCTYPE HTML> <! doctype> <html> <body style="background-color: #C0C0C0; height: 82px;"> <h1 class="auto-style1">iPACEMAKER</h1> <form method="get" class="auto-style3 > <button name="link" style="width: 56px" value="1">HOME</button> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; <button name="link" style="width: 75px" value="2"> SETTINGS</button> <button name="link" style="width: 69px" value="3">&nbsp; LIVE ECG</button> <button name="link" style="width: 69px" value="4>DATA LOG</button></form> <br /> <fieldset name="Group1" style="background-color: #CCCCCC"> <legend class="auto-style2"><strong><em>Summary</em></strong></legend> &nbsp;&nbsp;&nbsp;<strong><br>&nbsp; NAME &nbsp;&nbsp; Shijin

Bose<br><br>&nbsp;&nbsp;&nbsp;<strong>AGE&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; </strong> 22<strong><br><br>&nbsp;&nbsp; HOSPITAL&nbsp; :&nbsp; </strong>Medical Trust Hospital, Cochin<strong><br><br>&nbsp; CONSULTED DOCTOR</strong> Dr.
62

MANU VARMA<strong>&nbsp; <em><span class="auto-style6" MBBS,MD,DM (+918645645231)</span></em><br bpm<strong><br><br>PACING Inhibited<br><br><strong>&nbsp; volts<strong><br><br>&nbsp; />PACING MODE&nbsp; PACING RATE&nbsp; : : </strong>72 -

</strong>Ventricular : : :

VOLTAGE&nbsp; PERIOD&nbsp;

</strong>3 </strong>835 </strong>3

REFRACTORY PULSE

ms&nbsp;<strong><br><br>&nbsp; ms<strong><br></strong> <br /></fieldset></body></html>

WIDTH&nbsp;&nbsp;

63

APPENDIX-D HTML PAGE SETTINGS

HTTP/1.1 200 OK Content-Type: text/html Connection: close <!DOCTYPE HTML> <!doctype> <html><body style="background-color: #C0C0C0; height: 82px;"> <h1 class="auto-style1">iPACEMAKER</h1> <form method="get" class="auto-style3"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <button name="link" style="width: 56px" value="1">HOME</button> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; <button name="link" style="width: 75px" value="2"> SETTINGS</button> <button name="link" style="width: 69px" value="3">LIVE ECG</button>&nbsp; <button name="link" style="width: 69px" value="4">;DATA LOG</button> </form> <form method="GET"><div class="auto-style4"> PACING MODE:&nbsp; <select name="Pacinmode"> <option selected="selected" value="1">FIXED RATE</option> <option value="2">R-WAVE INHIBITED</option> <option value="3">R-WAVE TRIGGERED</option> </select><br />
64

PACING VOLTAGE:&nbsp; <input class="auto-style3" name="pacingv" style="width: 28px" type="text" value="3" /> (0-5 v)<br /> PACING RATE:&nbsp;&nbsp; <input name="pacingr" style="width: 29px" type="text" value="835" /> ms<br /> PULSE WIDTH:&nbsp;&nbsp; <input name="pulsew" style="width: 27px" type="text" value="3" /> ms<br /> REFRACTORY PERIOD:&nbsp; &nbsp; <input name="refrpd" style="width: 28px" type="text" value="120" /> ms<br /> GSM ON AIR:&nbsp;&nbsp; <input checked="checked" name="gsm" type="radio" value="1" />on&nbsp;&nbsp; <input name="gsm" type="radio" value="0" />off<br /> <br /> <input name="Submit1" style="height: 23px" type="submit" value="save"

/>&nbsp;&nbsp; <input name="Reset1" style="width: 47px; height: 23px" type="reset" value="reset" /></div> </form></body></html>

65

APPENDIX-E HTML PAGE DATA LOG

<! DOCTYPE HTML> <! doctype> <html> <body style="background-color: #C0C0C0; height: 82px;"> <h1 class="auto-style1">iPACEMAKER</h1> <form method="get" class="auto-style3">&nbsp;&nbsp;&nbsp;&nbsp; <button name="link" style="width: 56px" value="1">HOME</button> &nbsp;&nbsp; <button name="link" style="width: 75px" value="2"> SETTINGS</button> <button name="link" style="width: 69px" value="3"> LIVE ECG</button> <button name="link" style="width: 69px" value="4">DATA LOG</button> </form></body></html>

66