Rapid Prototyping of Computer Systems Spring 2012 Carnegie ... · required design objectives (real time, minimal power consumption, and so forth.) 1.2 Background 1.2.1 Human Computer

RapidPrototypingofComputerSystemsSpring2012

CarnegieMellonUniversity

Phase3

ImplementationandSystemIntegrationReport

Faculty:

DanSiewioerk,AsimSmailagic

Editors:

EditorInChief:MinHunLee

SmartOrthopedics:KeithWilliams

Gastroenterology:LeiFan

VitalClip:SaiNanduri

SoftwareArchitecture:AndrewBresticker

TableofContents1. Introduction

1.1 Purpose 1.1.1 Human Computer Interaction (HCI) 1.1.2 Smart Orthopedics 1.1.3 Gastroenterology 1.1.4 Vital Clip 1.1.5 Software Infrastructure

1.2 Background 1.2.1 Human Computer Interaction (HCI) 1.2.2 Smart Orthopedics 1.2.3 Gastroenterology 1.2.4 Vital Clip 1.2.5 Software Infrastructure

1.3 Group Members 1.3.1 Human Computer Interaction (HCI) 1.3.2 Smart Orthopedics 1.3.3 Gastroenterology 1.3.4 Vital Clip 1.3.5 Software Infrastructure

1.4 Overview - This is an executive summary of the project and approach

2. Conceptual Design 2.1 Problem Definition

2.1.1 Base Line Scenario 2.1.2 Key System Requirements

2.2 Initial Solution Concepts 2.2.1 Visionary Scenario

2.3 Conceptual Design 2.3.1 User Interaction 2.3.2 Smart Orthopedics 2.3.3 Gastroenterology 2.3.4 Vital Clip 2.3.5 Software Infrastructure

3. System Tutorial and Usage Scenario

3.1 Summary of Integrated User Interactions 3.1.1 Human Computer Interaction (HCI) 3.1.2 Smart Orthopedics 3.1.3 Gastroenterology 3.1.4 Vital Clip

3.2 Usage Scenario

3.2.1 Human Computer Interaction (HCI) 3.2.2 Smart Orthopedics 3.2.3 Gastroenterology 3.2.4 Vital Clip

4. Detailed Design 4.1 Human Computer Interaction (HCI)

4.1.1 Functionality 4.1.2 Interactions 4.1.3 Screens 4.1.4 Experimental Evaluation 4.1.5 Software Modules and Status

4.2 Smart Orthopedics 4.2.1 Functionality 4.2.2 Components and pictures 4.2.3 Experimental Measurements 4.2.4 Hardware Architecture 4.2.5 Software Architecture 4.2.6 Software Modules and Status

4.3 Gastroenterology 4.3.1 Functionality 4.3.2 Components 4.3.3 Experimental Measurements 4.3.4 Hardware Architecture 4.3.5 Software Architecture 4.3.6 Software Modules and Status

4.4 Vital Clip 4.4.1 Functionality 4.4.2 Components and pictures 4.4.3 Conceptual drawings of housing and layout 4.4.4 Experimental Measurements 4.4.5 Hardware Architecture 4.4.6 Mock-ups and physical prototypes 4.4.7 Hardware Modules and Status 4.4.8 Software Modules and Status 4.4.9 List of components, cost, power

4.5 Software Infrastructure 4.5.1 Functionality 4.5.2 Software Architecture 4.5.3 Experimental Measurements 4.5.4 Software Modules and Status

4.6 Conclusions 4.6.1 Requirement Feature Table 4.6.2 Summary of Key Design Issues

4.6.2.1 Human Computer Interaction (HCI) 4.6.2.2. Smart Orthopedics 4.6.2.3. Gastroenterology 4.6.2.4. Vital Clip 4.6.2.5. Software Infrastructure

4.6.3 Lessons Learned

5. Project Management 5.1 Implementation and Integration phase results

5.1.1 Task Dependency Chart

5.1.2 Summary of Work Log Hours for Phase 3 5.1.3 Summary by Group of Individual Student Contribution

5.2 Summary of Entire Project 5.2.1 Task Dependency Chart

5.2.2 Ranked Issue List 5.2.3 Summary of Work Log Hours For All Three Phase For Entire Class 5.2.4 Reflections on Work Log Hours and Distribution 5.3 Suggestions for Improving Class

1. Introduction 1.1 Purpose

1.1.1 Human Computer Interaction (HCI)

During this Implementation and System Integration phase, the purpose of the HCI group was to design and develop the user interfaces of the sub systems, such as Smart Orthopedics, Vital Clip, and Gastroenterology. Based on the main high level functionalities found from the Visionary Scenarios, the HCI decided to use a web based mobile application as the primary interaction systems. The HCI group continued to design and refine the wire framings of front end design of web based mobile application. This wire framings of application has been developed, which the user of the Custos can access from any browsers or diverse smart phones.

1.1.2 Smart Orthopedics

1.1.3 Gastroenterology

The objective is to produce a wearable device that is capable of recording sound from the gastrointestinal tract. In the conceptual design stage, we envisaged the device to either be an off-the-shelf solution with a microcontroller handling wired transmission of recorded data to a central data collection device (ideally a smartphone) via USB, or a custom solution that consists of a stethoscope, a microphone, an analog-to-digital converter (ADC) circuit, and a microcontroller that transmits the digital signal to a central data.

Similar products are already available off-the-shelf. For example, American Diagnostic Corporation (ADC®), 3M™ Littmann®, and other manufacturers already produce electronic stethoscopes that have a variety of functionalities, ranging from sound recording to noise cancellation to wireless transmission to a computer via Bluetooth. However, the main problem with these existing products is the packaging: the shape of the head of the stethoscope, though removable in some cases, is too large and difficult to wear for continuous monitoring.

In spite of the mounting problems, we decided to use a Thinklabs stethoscope head, since our research suggested that the Thinklabs sensor would be substantially better than the other commercially available stethoscope heads. We have found these sensors to give more satisfactory results and have built the rest of the system around these sensors.

1.1.4 Vital Clip

The aim of Vital Clip group was to design and implement a device that could detect the pulse at the finger tips accurately using a piezo-electric sensor. As you will see in the explanation of the Visionary Scenario (Section 2.2.2), there are many different situations in which monitoring a person's physiological signals can be helpful. One piece of information that is useful from a wide variety of perspectives is heart rate. A person's heart rate can be useful in determining stress level, intensity of exercise, and health of the vascular system. The Vital Clip was designed to bring this information into the Custos system.

1.1.5 Software Infrastructure

While designing complex systems it is beneficial to have a common framework that aids in performing various tasks without the efforts being duplicated. With this objective, a common software architecture, capable of running different applications was proposed. The software architecture designed and explained below aims at being a generic architecture capable of housing the expected visionary scenario and the various applications created to realize the scenario (Smart Orthopedics, Vital Clip, and Gastroenterology). A flexible framework is designed that aids in providing history information, tracking facility, and real-time feedback to the user and the associated third party - either caregiver or clinician. The architectural design is to realize the modularity and flexibility required to run all the three applications (and possibly could be extended to others) and provide features and capabilities to each of the applications to achieve required design objectives (real time, minimal power consumption, and so forth.)

1.2 Background

1.2.1 Human Computer Interaction (HCI)

The main focus of HCI mainly narrows down broad problem area and gives other group outline how the system should be composed. To determine the outline of the system and the high level needs from our targeted users of the systems, the HCI came up with visionary scenario and main functionalities of the systems that could be helpful to aids the needs of users after interviewing our prospective users. Then, the HCI group worked on developing the front end design, which the user will interact with sub systems of the Custos.

1.2.2 Smart Orthopedics 1.2.3 Gastroenterology

Refer to section 1.1.3

1.2.4 Vital Clip

The motivation behind using piezo-electric sensors for this project is the input given by our business associate (VitalClip, a company based in Pittsburgh) on currently existing product based on a pulse oximeter. This product is able to detect and measure the pulse of a user accurately using pulse-oximeters. But using pulse-oximeters results in higher cost. Using a piezoelectric sensor will bring down the cost and hence make a more appealing product.


In phase one, the software architecture team researched different software modules and determined how they should fit together in a complete system. From this, we formed our initial design. While the design was abstract, we were able to map it to the needs of the various hardware groups and the visionary scenario.

Implementation began in phase two. The goal by the end of the phase was to have data get from end-to-end. This meant having a hardware device transmit data to the server, the server storing that data, and an end user being able to query that data. Due to hardware issues with Smart Ortho’s device, we were not able to get actual sensor data. We instead used a simulator which

transmitted fake data to the server. Testing, however, showed that we could send and query data successfully.

During phase three we finished APIs for the back and front-ends of the system and integrated with the rest of the groups. All three hardware groups can transmit their data to the server to be fetched by the front-end. Data processing is also supported on the server. In this case, it is used for determining whether or not a user’s location is in a ‘safe’ or ‘unsafe’ area. We also added additional functionality to manage users and sessions. Overall, the integration with the rest of the system has been successful.

1.3 Group Members 1.3.1 Human Computer Interaction (HCI) - Carlos Gil - Presenter - Min Hun Lee - Editor - Vishal Agrawal - Leader

1.3.2 Smart Orthopedics - Kartik Kulkarni - Andrew Konecki - Mike Ralph - Scott Robinson - Keith Williams

1.3.3 Gastroenterology - Curtis Layton - Ameya Ambardekar - Lei Fan

1.3.4 Vital Clip - Joseph R Berman – Presenter for Phase 3, Hardware Liaison for Phase 1 and 2 - Michael R Bucher – Leader for Phase 3, Editor for Phase 2, Presenter for Phase 1 - Keshav S Nanduri – Editor for Phase 3, Leader for Phase 2, Editor for Phase 1 - Brian Pfiffner – Presenter for Phase 2, Leader for Phase 1

In the first phase, we (Brian, Keshav and Michael) were involved in identifying various sensors that could be a potential fit for the project, and also doing background research to see what kind of previous work had been done on this subject. We came across a paper from University of Illinois at Chicago that implemented a system based on piezo-electric sensors to determine a subject’s arterial pulse wave velocity. It had details on a circuit that we replicated on a bread board and tested in the lab. Since the purpose of the circuit was different, it did not give us the expected results. Another reference we used was the Pheonix Project, the details of which were given to us by our client. The circuit in this project was the closest we could get that matched our requirements.

In the second phase, we tested the shielded piezo electric sensor that we obtained from Measurement Specialties, a company based in Hampton, VA. The sensor, when tested with the

circuit described in the Pheonix Project gave results comparable to the Model 1010 sensor, a commercially available sensor that can detect and measure pulse at the fingertip. But there were issues like motion artifacts, sensor positioning etc. that lead to inconsistent and noisy results from the circuit.

In the third phase, the team spent time in making the output more consistent and getting better signal to noise ratio from the end product. In this phase, we were also joined by Joseph Berman who had been our liaison from the hardware team in the previous two phases. He shouldered the responsibility of setting up the communication link for VitalClip to the central database that the Software Team had setup. By the end of this phase, the Vital Clip team was able to detect and measure pulse at the finger-tip with accuracy comparable to the Model 1010 sensor and also communicate it to the database. Thus, we were successful in achieving complete functionality in every aspect of the project that we had initially planned for at the beginning of the class.

1.3.5 Software Infrastructure - Andrew Bresticker - Hong Jai Cho - Jonathan Francis - Colin Hass - Akshay Katti - Seoyeon Yang

1.4 Overview

This system of The Custos aims at providing an opportunity to make significant progress in achieving convenience and independence for the patient. This device has been developed to retrofit current health caring facility or the place where those caring is needed with The Custos that records biological and locational information and uses this information to provide the patient a quick and efficient assistant.

The Custos has three main high-level functionalities, such as monitoring user’s location and user’s biological state, and history of information and flagging to alert caregiver the status of patient and are composed of three main hardware devices and mobile web-based application. One hardware device called Smart Orthopedics will track the indoor and outdoor location of the patient. Another device called Gastroenterology will listen to stomach and intestines and record the sound. Last one called Vital Clip will measure the heart rate and blood pressure. All of this collected information will be stored on the database for making a history of information. Those stored data will be processed with several machine-learning algorithms to alert caregiver. With the mobile based application, the caregiver can access the information and be alert at anywhere and anytime.

At this Implementation and Integration Phase, various subsystems are implemented separately and integrated into a final system after identifying the problem space and technology and making decision on the design of the systems. This report will describe the process of implementation of subsystems including software and hardware components.

2. Conceptual Design 2.1 Problem Definition

2.1.1 Base Line Scenario

User

Sarah 29 years old Nurse Caring residents at Vincentian facility

Scenario

In the morning, Sarah is excessively busy. She needs to help all of her assigned residents change clothes. After helping change clothes, she visits each person’s room and ask what to be served for

breakfast. Then she brings each person’s preferred meal. If some people have difficulty with eating themselves, Sarah helps them eat. Usually she takes care of 8 residents and it takes approximately 2 to 3 hours to get

breakfast served. During breakfast time, one of her assigned residents with dementia wants to go to

bathroom and call for help it. However Sarah is busy with helping others serve breakfast and is not responding to help. Thus, he uses bathroom himself. After going to bathroom, he forgets that he currently

lives in the facility. He starts wondering and eventually goes out of facility. As all other caregivers are busy, it takes a while to locate him. Once Sarah finds the patient, she calls for other staff to locate him. She and other staff members bring medical tools to measure his biological status. At this moment of taking care of this current falling accident, other residents are left

inattentive because of low manpower. 2.1.2 Key System Requirements

Below lists fundamental principles to consider while making a decision on the design of our system. These principles are the main criteria to deciding on whether to incorporate some functionality into the system.

1. Comfort

To collect some biological information, such as blood pressure or sound of intestines, the user of this system has to wear some devices. These devices should not cause any discomfort to the user while doing any daily activities, such as walking or eating.

2. Variations

All the residents have different physical status. As user of the system has to wear some kinds of devices to collect relevant biological data, these devices should be wearable by people with different physical status.

3. Privacy

This system will store personal information, such as contacts of notification, current biological information, and collected biological information. Thus, all private data should be accessible only by authorized person.

4. Good Visualization

This system will handle multiple users and their abundant real time data. As the main goal of this system will be the notification of the emergency situation and display of their biological status effective, clear visualization of data will be desired.

2.2 Initial Solution Concepts

2.2.1 Visionary Scenario

In the morning, Sarah is busy with helping residents change clothes and serve breakfast. Because of the nature of her patients, she has to focus on a single patient and the rest of

patients do not get full attention. During breakfast, one of her assigned residents with dementia wants to go to the

bathroom and calls help her. However, Sarah is busy with serving breakfast and is not responding to his call for help. He uses the bathroom himself and suddenly forgets that he starts wondering to go back to

his house, which does not exist anymore. As this patient has a dementia and past history of wandering, he has been attached to the

Custos that locates him continuously. As the Custos system is able to track him continuously, it sends notification to designated caregiver when he wanders in to unallowed areas.

Now, he starts wandering the facility and staff members and the caregiver do not have to search all of the building to locate wandering accident.

Moreover, as the Custos system collect biological information, such as blood pressure, nurses do not have to carry the tools to measure the basic biological status of patients.

With the help of Custossystem, it becomes more efficient to detect an accident and give help more responsively.

2.3 Conceptual Design

2.3.1 User Interaction

The HCI group works on developing the design of the web-based prototype. Originally, the HCI group focused on developing the iPhone or Android application. Based on discussion with the faculty, the HCI switched to developing a mobile web application as it will be cross platform and more realistic. The application of Custos system has two different kinds of users: user who wears devices to provide biological or locational information for caregivers, who receives status notification and provide appropriate care. For the user, who wears devices, simple interactions will be requested. For Vital Clip and Smart Orthopedics, the user will simply wear the devices. No direct interaction will be need. For Gastroenterology, there are going to be three buttons for interactions. The first button will be used to start recording, second button will be used for transmitting, and the third button will be for alert.

More interaction with the prototype system will be done at the receiver side. This interaction will occur on the mobile phone. As the receiver is the person who provides care, there will be no major challenging for them to use the system on the mobile device. However, as the mobile device has a limited display size, the HCI group has to focus on improving the readability of data on the screen. Thus, the HCI group designed the tab menus so that user of the system can not only navigate easily through the application, but also spread displaying data across several screens. In this way, the readability of the system is improved.

Finally, the procedure to use the function has to be self-explanative. Although users of functions from Vital Clips and Gastroenterology will mainly deal with viewing and listening to the stored data, users of functionalities from Smart Orthopedics have to set customized boundaries to define the instances of wandering. This process has to be simple and easy to be performed. To improve the usability of functions, the text and graphics will be used together.

2.3.2 Smart Orthopedics

Smart Orthopedic is a human location tracking and monitoring system. It is targeted to specify a virtual fence around a residence where mentally challenged people reside and move about. The system minimizes the necessity of a dedicated person to escort such a person all the time so that

he or she may not enter a particular location that is of concern or danger.

The Smart Orthopedic product aims at augmenting the Shoes with inbuilt circuitry that helps in tracking the location of the wearer. The central administration and monitoring system also allows specifying the locations of concern, on entering which, suitable warnings will be generated in real-time, thus helping the care-taker to get alerted on moments of danger, rather than he or she constantly escorting.


The objective is to produce a wearable device that is capable of recording sound from the gastrointestinal tract. In the conceptual design stage, we envisaged the device to either be an off-the-shelf solution with a microcontroller handling wired transmission of recorded data to a central data collection device (ideally a smartphone) via USB, or a custom solution that consists of a stethoscope, a microphone, an analog-to-digital converter (ADC) circuit, and a microcontroller that transmits the digital signal to a central data.

Similar products are already available off-the-shelf. For example, American Diagnostic Corporation (ADC®), 3M™ Littmann®, and other manufacturers already produce electronic stethoscopes that have a variety of functionalities, ranging from sound recording to noise cancellation to wireless transmission to a computer via Bluetooth. However, the main problem with these existing products is the packaging: the shape of the head of the stethoscope, though removable in some cases, is too large and difficult to wear for continuous monitoring.

In spite of the mounting problems, we decided to use a Thinklabs stethoscope head, since our research suggested that the Thinklabs sensor would be substantially better than the other commercially available stethoscope heads. For testing this, two sensors were built and their performance was compared.

Conceptual Design Hardware Diagram:

Fig 2.3.3.1. Conceptual design hardware diagram

The above diagram shows the initial design diagram, explained in Phase 1 report. The final hardware design has been described in section 3.3.3.4. Phase 1 report also describes the various product feature matrices prepared by the group. The report identifies the Thinklabs sensor as our primary microphone element with TLV320ADC3101as the primary choice for the ADC chip. The final design uses the Thinklabs sensor but we have used PCM2912a instead of TLV320ADC3101 as it made our design simpler and smaller.

2.3.4 Vital Clip

The visionary scenario illustrates the many different situations in which monitoring a person's physiological signals can be helpful. One piece of information that is useful from a wide variety of perspectives is heart rate. A person's heart rate can be useful in determining stress level, intensity of exercise, and health of the vascular system. The Vital Clip was designed to bring this information into the Custos system. Vital Clip is a small device that allows a person to take their pulse at the finger tip with high accuracy. Today, most devices use a pulse oximeter to obtain measurements of pulse. However, pulse oximeters suffer from a notable problem. They are sensitive to variations amongst subjects, such as callouses, skin tone, or even painted nails. To provide a more robust pulse signal, a new methodology was needed. A piezoeletric sensor was a promising new direction for pulse acquisition. This method uses a piezoelectric sensors, which detects the physical vibrations of the pulse wave form. With significant gain and filtering, useful information could be extracted from the fingertip.

Once the pulse signal was strong and clear, it needed to be passed to a supporting system that would count beats and deliver the information to the Custos servers. Initially, a Gumstix system was considered. This is a full Linux operating system, and it is currently being used by the Gastroenterology group. Since the Vital Clip does not have significant computational requirements, the Gumstix platform vastly exceeded the requirements. Instead, the Vital Clip code is run on aArduino Uno. This is the same system used by the Smart Orthopedics groups. This reduces the complexity of code development to integrate with the software architecture.


For abstraction and ease of expandability, we want all modules in the system architecture to be as isolated as possible; ideally, each module should perform a different task. Our system architecture

Microphone Element

Amplifier Analog Filter

ADC Interface Digital Filter

design has three layers: User Interface, Software, and Hardware. User Interface layer displays requested information. Software layer processes and stores data, and provides data transmission protocol between User Interface and Hardware layers. Hardware layer reads data from sensors and emits data to the Software layer.

3. System Tutorial and Usage Scenario 3.1 Summary of Integrated User Interactions

3.1.1 Smart Orthopedics 3.1.2 Gastroenterology

The goal of the device is to serve as a monitoring, diagnostic as well as research tool. In a monitoring or diagnostic setting, we can imagine the following scenario: a patient who is either unable to communicate his gastric discomforts or suffers from chronic gastric problems that are not diagnosable in a short visit to the doctor is instructed to wear this device, for an extended period of time, during which sound clips of the patient’s gastric activities as well as the patient’s alert flags are recorded and sent to the doctor. The doctor would then be able to listen through all the clips and proceed to make a more accurate diagnosis for the patient. Given that a sizeable number of diseases involving the gastrointestinal system are chronic and/or difficult to identify without invasive techniques such as camera pills and endoscopy, and that doctors currently rely on stethoscopes to make a high proportion of diagnoses and are therefore familiar with gastric sounds, this system is well-suited for this purpose.

In a research setting, a separate research team at Carnegie Mellon University under Professor George Loewenstein has proposed studying the link between gastric activity and emotional and mental states. Given that this type of study is likely to require long-term monitoring of gastric activity, for which currently there is no suitable equipment, our system is also designed with this purpose in mind.

3.1.3 Vital Clip

Vital Clip has a very simple system that interacts with the user. All a user has to do is strap the Velcro around his/her finger and everything else is automatically completed. The sensor picks up the pulse, Arduino counts the pulses and gets BPM (Beats Per Minute) and the Telit Board communicates this data to the server to be stored in a database. This data can then be retrieved by the User Interface (U.I.) built by HCI team and then visualized in three different forms:

1. Most Recent Data: In this form of visualization, the user is able to see just one set of BPM data, which is the data that was collect most recently for that user.

2. Graph of all data for a given user: In this format, the user gets a graph which is automatically plotted and has all the BPM data along with the time at which the data was collected. This gives the user a sense of overall monitoring of his/her state and servers the purpose of being the most understandable form of data.

3. All data for a given user: In this format, the user gets a table of all the BPM data collected for that particular user.

3.2 Usage Scenario (Illustrated by screen images and pictures of the equipment) 3.2.1 Smart Orthopedics


Refer section 3.1.2.

3.2.3 Vital Clip

In this section, we describe how Vital Clip can be used by a subject. As mentioned in the previous section, Vital Clip is an extremely simple system to use. The subject just has to strap the Velcro onto his/her finger-tip and wait for 30 seconds for the pulse data to be collected. The way the sensor is strapped onto the finger-tip is shown below in Figure 3.2.3.1

Figure 3.2.3.1 VitalClip sensor strapped onto subject’s finger-tip

Once the data has been collected by the system, the user can then see the data on the U.I. Figures 3.2.3.2 and 3.2.3.3 show the various forms in which the data can be visualized. To make any reading or graph, the user has to select the user id, which the user wants to monitor, and select button called Get Data to retrieve the data. Once the button called Get Data is pressed, the application will update the entire data by every 5 seconds.

Figure 3.2.3.2 VitalClip Data: Latest data of user on U.I.

Figure 3.2.3.3 Graph of all BPM’s of user on U.I.

4. Detailed Design 4.1 Human Computer Interaction (HCI)

4.1.1 Functionality

The main functionality of the mobile web application is displaying the basic biological or locational information and the notification of situations that the user of the system needs assistant. The user of this application may view notifications from all subscribed users with devices. The most urgent notification will be highlighted so that the user can immediately notice a problem. Moreover, the individual subscriber’s status and information will be displayed in the profile page. At this page, the caregiver can not only view personal data, but also set preferences for the individual subscriber, such as deciding which groups functions will be used or the setting of notifications. Unlike previously discussed page where the user can see the all the functionalities from Vital Clip, Smart Orthopedics, and Gastroenterology, there are also three pages that handle only one functionality. The settings and display of three main functions from Vital Clip, Smart Orthopedics, and Gastroenterology can also be handled at each of function’s separate page.

4.1.2 Interactions

The primary interaction of the user of this application will be viewing data, such as biological and locational information or notifications. In terms of viewing this information and notifications, no user’s input is required. However, as this system will deal with multiple users, meaning displaying a large amount of data. To effectively show this data, there are several tabs menus to navigate different functionalities, filters to retrieve relevant data, and search box. Users will interact with these tab menus, filters, and search box to retrieve desired information quickly.

In addition, there are three different main pages to Vital Clips, Smart Orthopedics, and Gastroenterology. The user can quickly move to different functions by clicking the navigation buttons at the bottom, which exist at every screen. Both Vital Clip and Gastroenterology, the user does not have to give any input to utilize these functions. User will mainly see biological information or listen to the recorded sound of the intestines. However, the user has to give inputs, such as the boundary of buildings for the tracking function of Smart Orthopedics.

To modify notification and subscribed functions, the user can go to the individual subscriber’s profile page. The user can simply type information or several numerical values. Our application can be used at both mobile phone or a web based application, the user may enter large amount of data through the website from computer so that user can have better usability.

4.1.3 Screens

Figure 4.1.3.1, the initial page of the application start with the large logo and login functions. For this application, the HCI group decided to have one single user account database instead of two separate databases for notification receiver and users of the system. If the user goes to their own profile, he or she can set their account as receiver or user of the system. Several kinds of alerting message will be displayed for notification as shown in Figure 4.1.3.2

Figure 4.1.3.1 The initial login page Figure 4.1.3.2 Displaying notification message

One primary goal of this Custos application is notification of irregular biological status and behaviors. The main page of the prototype shows the timelines of notifications of users. The mockup design of main page can be seen in Figure 4.1.3.3

Figure 4.1.3.3 The main page with timeline

This timeline feature will be used for showing important notification messages. Depending on the status, the notification will be colored so that the user will be able to easily notice changes of status and emergency situations. The filter and search box have been included to increase the usability of the system. These filter and search box make user easy to retrieve relevant information quickly. At the bottom of the screen, the navigation buttons are always shown so that user can navigate to different function pages. If the profile button has been clicked, the list of individual user will be shown as in Figure 4.1.3.4. By selecting the desired individual user, the user can navigate to individual profile page. The individual information can be view and modified at individual profile page.

Figure 4.1.3.4 The flow from timeline page to list of users

In the individual profile page, the information that the user subscribed will be shown. As there are three main functions, Smart Orthopedics, Vital Clip, and Gastroenterology, the HCI group decide to have three different tab buttons to view information from different groups so that readability of the system will be increased. The Figure 4.1.3.5 shows the current rough design of the individual pages for three different functions. These pages will be refined later.

Figure 4.1.3.5 Individual profile pages for Smart Orthopedics, Gastroenterology, Vital Clips with selected tab highlighted by red circle

Smart Orthopedics

There are two different maps for Smart Orthopedics group: one is inside the building and the other is outside of building. Thus, HCI will also have tab button to show two different maps. As it can be seen from left picture of Figure 4.1.3.6, navigating different building will be achieve by selecting filter options. The current front end design of two different map view can be seen at Figure 4.1.3.7 and Figure 4.1.3.8. Page that shows user data: In this page the caretaker has selected multiple users to show by location. We can track multiple users and get instant feedback on whether they are in specified safe or unsafe zones. If a user is in an unsafe zone then their icon marker will change from green to red to indicate this. The map updates with new markers every few seconds showing the new user location. Page that shows focal zones (circles): In this page we can set whether zones are safe or unsafe for a particular user. Circles of either red or green color can be placed at different locations and enlarged to indicate whether a zone is safe or not. If two circles overlap and a user is found within that intersection, then the zone will be considered safe or unsafe depending on the smallest circle within that intersection.

Figure4.1.3.6MapdisplayofSmartOrthopedics.Left:buildingmap.Right:outsidebuildingmap.

Figure4.1.3.7Exampleoftrackingmultipleusersbyshowingfeedbackasgreenmarker

Figure4.1.3.8Focalzoneshownonthemap

VitalClip

In this page, the user will see two main displays: the entire data and latest reading. The entire reading data of Vital Clip will be visualized as the line graph. The latest reading value will be shown as just simple highlighted text. The current front end design of the Vital Clip page can be seen in Figure 4.1.3.9 and Figure 4.1.3.10. Detail of user interaction has been explained in the previous section 3.2.1.

Figure 4.1.3.9 Front end design of Vital Clip

Figure 4.1.3.10 Front end design of Vital Clip with data visualization

In the each group’s page, which can be displayed by selecting navigation button at the bottom as in Figure 4.1.3.11, there is a list of users with check box, who has subscribed to its functionalities. This check box will be used to indicate selections for removing or showing relevant information. Smart Orthopedics wants to track multiple users. Unlike individual pages that show only individual on the map, muti-selected users can be tracked at the same time from Smart Orthopedics page. In addition, new user can subscribe for each function.

Figure4.1.3.11Listofusersubscribedtodifferentgroupswithcheckbox

Belowareprocessdatafordesigningmobilewebapplication.

Figure4.1.3.12Initialdesignofapplicationwithoutspecificprofilepage

Figure4.1.3.13Initialdesignofapplicationwithspecificprofilepage

4.1.4 Experimental Evaluation

The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.

After the HCI group has received the desired sketches of wireframings from three different groups, the main viewing pages of each sub groups, such as Smart Orthopedics, Vital Clip, and Gastroenterology, and login and register pages are designed based on the wireframing that the HCI worked before. Although the final design of front end web based application has been implemented, the HCI group have not get a chance to conduct the user testing on the recently developed front end design to improve the design of prototype.

4.1.5 Software Modules and Status

This mobile web application will receive and modify all data from HTTP Request to HTTP server implemented by software architecture group. This mobile web application will display this data on web pages. This flow can be seen from Figure 4.1.5

Figure4.1.5Flowoftheprocessingthemobilewebapplicationhighlightedwithredcircle

4.2 Smart Orthopedics

4.2.1 Functionality

The complete system overview.

This diagram represents the various components and their functions in the Smart Othopedic system. The left half illustrates the components that coordinate to achieve indoor tracking of the person wearing the Smart Orthopedic shoes. Upon he or she entering outdoor premises, the tracking mechanism switches to GSM/GPS.

Product components and functions:

1) Indoor Tracking: Indoor tracking faces a challenge of fine location granularity, which is not provided by the tracking technologies such as GPS. The major requirement of this feature is to identify the location of a person in terms of “which room?” Such information can then be used for generating warnings when the person under consideration enters an area of the residence that is hazardous, like – the balcony during snowstorm, kitchen, garage etc. Our solution makes use of the following components and the organization of the components is illustrated in the left half of the System diagram.

1. Active RFID Tags (Wavefront RFID): These tags come in different form factors and can are handy enough to embed them into the shoes or some wearable gear. The tags have an accelerometer embedded inside. When it senses movement, emits its id information over radio frequency. The tags transmit the data (id, battery and signal strength information) over serial pins. The tags do not have an RX pin, they only Transmit on the Tx pin.

2. RFID Readers (Wavefront RFID): The RFID readers can sense the above tags in the range of 10 – 15 meters. These readers are omnidirectional but have a particular angle of maximum sensitivity. The placement and mounting of the readers in the room can be tricky in order to harness the maximum angle of sensitivity. We experimented multiple locations of placement and mounting in a room and found out that mounting above the door with the front face of the RFID reader facing the ground would be the best position.

3. Networking the readers (IOLAN Serial-Ethernet Server): We used the IOLAN Serial to Ethernet server to network the RFID readers so that a single admin controller can receive the data from all the RFID readers in the facility. These Serial –Ethernet servers receive the serial data from the readers (which would generate the data on sensing a tag in their vicinity) and transport it over Ethernet to a network switch.

a. Trueport technology: The IOLAN products provide an interesting feature of COM port mirroring. The serial device (RFID reader) usually connects to a host computer using a native COM port, which will then be listened by the host program/hyper terminal. Now when we are networking the readers over IOLAN servers, this interface will be changed to a TCP port. This change in the abstraction is overcome by Trueport technology which registers a native COM port in the host’s machine which inturn communicates to IOLAN servers over EtherNet and hence still giving the same abstraction of a COM port.

2) Outdoor Tracking: The outdoor tracking of wanderers is accomplished by the apt technological solution GPS. The exit from the indoor facility marks the beginning of outdoor tracking. This switch includes activating the GPS tracking

a) Telit Boards (GPS + GSM): The Telit boards include the GPS and GSM hardware to capture the coordinates and communicate them to a central database. More details on the outdoor tracking is in the other dedicated section of the document.

3) The central database: The tracking data by the RFID readers and the GPS boards is logged into the central database. This is the database which is referred by the Apps group to take the decision on when to trigger a warning. The GPS device directly logs data into the database via the GSM hardware. For indoor tracking, the RFID readers are networked and connected to a central admin controller PC which then filters the updates and eventually posts them to the central database.

The switch from indoor to outdoor tracking is mediated by the Database and the App which signals the GSM /GPS module when does not receive any updates about the corresponding tag in 2 minutes.

Physical features:

The circuitry fits into the Shoes – below the sole. The administration and monitoring engine is hosted on a central computer in the facility.

Power:

The Shoe circuitry will have a rechargeable battery and the administration engine will need constant power supply.

Infrastructure:

The below infrastructures will be used for indoor tracking

a) Every door in the facility will have a RFID reader along the sides. Each of the readers will be connected to a central switch using Ethernet.

Tracking capabilities:

1) Indoor:

Transitions from room – to room will be tracked and logged on the central server. The granularity of locations being tracked will be a room.

2) Outdoor: The GPS location will be logged on the server

Warnings:

The administrator can specify the locations of concern and also can specify the time to alert for each location. On triggering of a warning rule, The system will alert in the specified manner – email, Text or a call.

Analytics:

The System will also log the historical locations occupied, Last recorded location etc

This diagram shows the unified view of Smart Orthopedics functionality.

4.2.2 Components and pictures

GPS/GSM

Figure 4.2.2.1 Picture of the Telit GE-864 GPS evaluation board

RFID

The smart orthopedics system is composed of the following essential components, a GPS receiver/GSM module, the RFID tags and readers, and the IOLAN server. Following are images of these components.

Figure 4.2.2.2: RFID READER Figure 4.2.2.3 RFID TAGS

Figure 4.2.2.4 IOLAN Serial-ethernet server

Below is a representation of the desired functionality of the system. The red dots represent RFID readers placed throughout a building, and the green area represents their effective range.

Figure 4.2.2.5 RFID Reader placement diagram

4.2.3 Experimental Measurements

GPS

Due to the complexity and scope of the Telit GE-864 GPS unit and the interfacing required, there was not much done in the terms of experimental measurements done. In the testing that we did a

number of data conversions were done to the GPS coordinates in order to achieve a higher precision when mapping the modules path when GPS is valid.

RFID

Below is a table of measurements taken from RFID readers. We gathered this data to determine a relationship between signal strength from the tag and distance. These measurements were taken under ideal conditions, in a long, empty hallway, and still show little correlation between the strength of the signal and how far away the tag was from the reader. Undoubtedly the signal strength will relate to distance much less when there is no line of sight from the reader to the tag and the environment causes fluctuations in the signal strength.

DISTANCE 10 feet 20 feet 30 feet 40 feet 45 feet 50 feet 55 feet

SIGNAL STRENGTH 199 211 179 171 181 183 173

202 216 179 175 167 183

197 201 194 171 181 180

185 210 194 176 186 171

196 192 194 185 178 180

195 201 206 179 190 177

201 208 195 176 184 183

199 193 182 181 181 180

201 202 188 179 169 181

196 204 191 171 172 176

198 203 202 171 185 168

203 205 193 173 179 172

202 196 191 176 176 182

193 199 197 182 180 183

195 193 190 175 176 179

199 206 185 178 185 185

196 210 187 176 182 183

200 205 192 182 181 178

197 211 193 172 184 181

AVERAGE SIGNAL STRENGTH

197.5789

203.4737

191.1579

176.2632

179.8421

179.5263 173

Signal Propagation Model One of the most difficult parts of this project was coming up with an accurate signal propagation model for the RFID tags. As seen in the plots in, the signal properties would change from room to room, presumably because of the variation in size, shape, and object interference. We believe some accuracy was lost due to the poor modeling, which we ended up settling with

81√64516

2500

Where distance is in meters and RSSI is received signal strength of the message in the range [0,255]. Although the model isn't as accurate as it could have been, we will see by the end of this paper that it can't be too far off as the trilateration results are fairly accurate.

Evaluation and Results The full system was completed and integrated in to the Rapid Prototyping of Computer Systems class project and presented in our final demo. The testing that led up to the final demo went well, but we encountered a few problems throughout the testing phase. Many of the problems were minor, and just required me to tune the values (like for the covariance matrices) to get a more

accurate result. However, one of the problems was one that is fundamental to testing, and that was determining the error of the output from the system. Since there are no other readily available methods to determine position indoors, we had no accurate way of measuring the ground truth against the computed location. The best method we could come up with was plotting the output of my program (which were in geodetic coordinates) in Google Maps and observe the distance from where we believe the location should have been. Being in the corner of Hamburg Hall and having a map of the facility aided us in determining our position and the expected position of the RFID tag. It seems as though we can determine our own position in the building to within 1.5 meters or less.

An example output of the system is shown plotted in the map below. The arrows indicate the sequential movement and corresponding samples taken from the RFID tag. The sequence of localized points is in the expected order and area of the room, however it is difficult to say how accurate each point is.

I would conclude that the system is accurate to within about 1-2 meters, but again, this is just from observing the output and not any formal measurements of error. We was surprised with the accuracy of the results given all of the uncertainties in the signal propagation modeling, trilateration error, and Kalman filter covariance matrices. But even considering those problems, it seems to work fairly well, especially for the application it was intended for, which just aimed to be accurate to within 3-5 meters.

4.2.4 Hardware Architecture

GPS architecture

Telit GPS/GSM 864 Module

The Telit GE-864 GPS module contains both the GPS and GSM module that will be used to

provide a real time tracking solution of an individual when outdoors. The on-board GPS module is directly interfaced with the GSM module and provides the capability of obtaining real time position via GPS. The GPS information is then sent to the GSM module at which point the coordinates can then be sent to the hosting database via GSM/GPRS through the means of a fully capable TCP stack. The module is also capable of receiving external information via serial communication and through the GSM/GPRS connection.

RFID

Network Layout I found that the positioning of the readers was not extremely important in terms of performance, although the ideal position for the reader to be placed is likely on the ceiling of each room, which gives it the most exposure to the room as possible. As for achieving coverage of the entire facility, we planned to place them in a grid formation, as seen in the figure below. There are multiple approaches that can be taken, but since we need at least three readers in range at any given spot in the building, it is best to place them in a grid array and close enough so that the coverage area overlaps in all areas. There are, however, "dead spots" corners of some of the rooms, but this usually is not a problem as the readers have a much larger coverage area than their specification sheet indicates.

Network Communication Just like with the detection method, many different solutions were researched for the network communication problem. This is where scalability really comes in to play, the solution needs to be simple enough to install in a 100,000 square foot facility yet also reliable enough to handle messages from potentially hundreds of assets. Finding the best combination of simplicity, reliability, and speed is not easy, but it seems as though the solution of network connecting the readers through Ethernet was my best option. These days just about every facility is wired with an Ethernet network for their computer systems in every room, making it ideal for easy installation. Even many residential homes these days are wired enough to make this application practical. The Ethernet solution is also very reliable and fast, capable of handling multiple gigabytes of data every second. Each reader only sends out a maximum of 760bps (for a single tag), which can accumulate to a large amount of data if many readers are transmitting at the same time.

In order to make the conversion from serial to Ethernet, we purchased serial to Ethernet converters, called IOLANs and pictured in Figure 4.2.2.4, that open a virtual serial port on the destination computer and acts as if it is a local device. Admittedly, this solution might be considered overkill for the small readers attached to them, so in an actual product implementation it would be best to find a smaller, cheaper device that just sends the serial data over Ethernet to a specific IP address, but nothing more. A problem we encountered with these IOLAN servers arose due to a mismatch in the voltage they supplied to the serial device and the power required by the RFID readers. This was mostly solved by creating an adapter that went between the DB9 connections on the server and the reader, and provided 9v to the reader. However, under any circumstances, it appeared as if the reader connected directly to the computer always functioned better than the networked readers, having a greater read range and updating more frequently.

4.2.5 Software Architecture

GPS/GSM

TELIT GE 864-GPS Module

The GPS/GSM module supports a very lightweight python interpreter engine built into the board that imports board supported libraries during compilation. The limitation of these libraries

depends on the Telit module itself, where the supported libraries are stored independently of each

other on the board. Each library provides the basic interface for the python interpreter and the hardware resources present on the board.

After the source file is compiled the correct libraries are linked in and execution of the script commences, however at the lowest priority task. Since python is a scripting language it can support a wide variety of functions and functionality, however many of these methods can cause undefined and unexpected behavior of the board. Thus it is imperative that only the supported module libraries and string libraries are used.

Example:

The use of the time library is acceptable and is actually presented in the documentation in addition to the time.sleep() method. The debugger and the board accept this as an acceptable method and function, however the board will sometimes sleep for far more or not at all, and sometimes crash. This is just one instance of improper behavior of a used library that the board does not support but will compile and run.

Example:

If the module is not properly configured certain libraries may or may not be properly configured or unexpected behavior may occur. There are two evident occurrences of this issue that we encountered and suspect there are far more if one is not very careful with both the documentation and the coding standard they are following.

1. The board will not support certain functionality based on the boot configuration that is set for the board for the current profile. In many instances the script just will not run, and in other instances only certain features of the board are supported. This is due to ownership of the AT command bridge resource and how it is configured in reference to certain options chosen by the user.

2. The jumper pins on the board itself enable certain features while disabling others while the module is powered own. In the case of building a separate proto-board this wouldn’t be such a big deal, but for overall board/chip supported behavior and functionality this can cause issues. In retrospect this lead to the board debugging support not being supported properly in the mode we were working in. Additionally, this also tells the board what libraries are also currently supported. The use of the SER libraries posed to be problematic and may have been due to this issue.

The overall architecture reaches beyond just eh python script interpreter, but it is important to note that this is an important and core component of the device. It provides a relative ease to bridge the software and hardware together.

Fig 4.2.5.1 Diagram that shows just where the python engine exists in relation to the hardware.

In addition to the python interpreter is the virtual serial port that actually processes the commands issued by either the user or the python engine. This provides another layer between the hardware and user interface and is the final interface between the software and hardware resources that of which we have direct interaction with. It is important to note that this last software interface that the board is composed of can be granted to another service. This means that that the AT serial port can either be internally controlled by the python engine or an externally driving AT issuing interface. This is all set by the startmodescr AT command (See the python easy script documentation to see the limitation of the startmodescr modes).

Telit GE-864 GPS Communication Channels

The software support for external communications from the board consists of issuing AT commands to create certain forms of connections. Since the device supports both GSM and GPRS, it is critical that all the necessary configurations are focused around one form of these connections.

For our use of the board we ended up using GPRS with the construction of TCP packets to a target server. Therefore we stuck to all GPRS supported commands. The sequence of these AT commands is important for it designates if a connection can be successfully established.

Example:

With an active SIM card and identification of the network and type of protocol (IP), user identification and associated password. With the use of a new SIM card it is important to identify the APN. Usually the user and password are either black or set to some default value, in our case none.

AT#ENS=1

AT+CGDCONT=1,"IP","GPRS_APN"

AT#USERID=GPRS_USER

AT#PASSW=GPRS_PASSW

AT#GPRS=1

The previous example is a basic set of AT commands that can be issued to the module to gain access to the cell network via a GPRS connection. With this connection the board is issued an IP address.

Fig4.2.5.2 Diagram showing TCP/IP stack between the device and remote device/application.

With the device being capable of creating a TCP/UDP datagrams, the board is capable of receiving and sending traffic. However, in order for transmission and receiving data can begin a

socket must be created. The example bellow provides the AT command sequence we used to transmit data via the GPRS connection.

Example

Each field of the following AT command is in respect to the socket number, and the cid (details either a GSM or a GPRS connection type). The 7070 is the port number of the rpcs server and the IP address follows. The last three fields detail connection close settings and UDP timeout settings and how data is to be sent to the socket. The data being sent out through the socket can be completed via the SSEND AT command with the socket number following. The end of the message in this form is the CTRL-Z. This informs the board that the message is complete and can be sent via the TCP socket.

AT#SD=1,0,7070,”IP ADDRESS OF SERVER”,0,0,1

AT#SSEND=1

> DATA TO BE SENT CTRL-Z

TCP SERVER

The final software component is the intermediate parsing server. This server is required in order to set all the data in the proper TCP packet format. Due to limitations of the board and the python support in regards to methods it was best to get the data off the board in a particular format and then parse it prior to sending the data to be logged by the rpcs server.

Data Format

The format of the data was set to comma separated values (CSV) to keep the python script on the board as simple as possible. Each critical piece of data obtained by the board is placed into the TCP datagram separated by an ASCII character of a ‘,’. On the server intermediate TCP server the data is parsed and then converted to the proper format that conforms to its storage in the database.

Example:

Each entry is an ASCII representation of the data. The x’s in the packet are additional information in the packet that will not be logged by the server and is essentially dropped.

ip_addr,module_id,bpm,bp_d,bp_s,utc_time,latitude,longitude,x,x,x,x,x,x,x,x

123.214.255.0,4124901100,1111,2222,3333,043344.999,6034.1234N,16959.1234E,0,0,0,0,0,0,0,0

For correct data to be detected, certain data fields of the TCP datagram must conform to a particular standard.

1. The vital clip data is presumed to be valid as long as the data fields are not zero. If zero is detected then the vital clip valid data flag is set accordingly.

2. Latitude data must have a ‘.’ In addition to either a N or S flag at the end to flag if it is north or south. If the GPS unit on the module is not correct, the GPS module will transmit no data between the commas in the TCP datagram and the GPS validation flag is set accordingly.

3. Longitude data must have a ‘.’ In addition to either a E or W flag at the end to flag if it is east or west. If the GPS unit on the module is not correct, the GPS module will transmit no data between the commas in the TCP datagram and the GPS validation flag is set accordingly.

4. All other fields are assumed to be correct if received from the module.

TCP Packet Creation

Once all the data is received and properly parsed and formatted according to the rpcs standard, the data structure containing all the information is written to a TCP socket that is connected to the rpcs TCP parsing server. As soon as the data is written, it is freed, and the connection is closed. If the rpcs server did not receive the data the server does not handle any failure conditions with regards to delivery.

RFID

Posting the RFID serial device data to the central database

The location data from the RFID readers, in our project is deposited to a central database regularly. This deposition of location tracking data in a central database opens up several possibilities:

1. Historical analysis of wandering patterns

2. Automating the boundary crossing detection and warning

3. Mapping on a geo map from applications on multiple platforms

Thus we chose to transport the RFID location data from the serial device, all the way to the database via the following channel.

After Localization of multiple RFID readers reporting the same Tag sensing, the filtered location

data is posted to the database, via TCP2Database proxy.

Steps involved in posting to the database:

1. Form the standardized packet from the filtered RFID data, with the below format:

struct packet { char header[4]; /* RPCS */ int seq; /* auto increment from 1 */ long long tag; /* tag_id or gsm number */ int ip; /* ip address of device */

int utc_t; /* time in C UTC representation */ int latitude_d; /* latitude degree */ int latitude_m; /* latitude minute */ int latitude_s; /* latitude second */ int longitude_d; /* longitude degree */ int longitude_m; /* longitude minute */ int longitude_s; /* longitude second */ int vital_bpm; /* heart beats per minute */ int vital_sys_bp; /* systolic blood pressure */ int vital_dia_bp; /* diastolic blood pressure */ int flags; /* flags for various usage */ int conf; /* location confidence value */ }

2. Save the sequence number in the ACK-Expected queue

3. Establish connection with the TCP 2 Database proxy.

4. Send the packet and wait for reply message, validate the success, and match the sequence number of the message in the Ack outstanding queue.

5. Close the connection after every packet sent and ACK received.

Problem :

The packet structure should not be broken into multiple TCP Packets. The TCP 2 Database proxy treats the messages on per TCP Packet basis and validates the packet by size. This is not a good approach as TCP is stream oriented and does not make any guarantees of delivering data as a single chunk.

Lesson learnt:

Make a blocking send call, and not non-blocking version to ensure that the entire packet data is sent in 1 chunk (high probability). Avoid size based validations, rely on custom header – data – checksum protocol to detect the reception on valid messages


GPS/GSM

The current versions of the software will work and valid data is obtainable. There are some possible corner cases for both the python script and the C code that may exist and could cause issues.

Python Script

1. Watch Dog timer should be added just in-case the board happens to bug out or stuck somewhere due to a failure of a timing in relation to closing the socket correctly, or an AT command not executing as expected/defined.

2. GPRS signal quality and connection update is unsure and undocumented. Testing would need to be done in order to see if the board is on and no coverage is present does the board automatically get a new IP address and update status accordingly.

3. The receive socket needs to be configured and tested in relation to the script as a whole. As it stands the board will not accept any in-coming data, thus should be configured for this.

4. Power modes need to be tested with the receive states and wake-up efficiency.

TCP Server

1. More corner cases in the data need to be tested, to see if the server will crash if different types of TCP datagrams are received.

2. Testing in relation to more than one board sending data to the server be done as well. 3. Ensure no memory leaks are occurring and all occurrences with regards to memory are

handled accordingly to safe programming practices.

RFID

Posting the RFID serial device data to the central database

The location data from the RFID readers, in our project is deposited to a central database regularly. This deposition of location tracking data in a central database opens up several possibilities:

1) Historical analysis of wandering patterns

2) Automating the boundary crossing detection and warning

3) Mapping on a geo map from applications on multiple platforms

Thus we chose to transport the RFID location data from the serial device, all the way to the database via the following channel.

After Localization of multiple RFID readers reporting the same Tag sensing, the filtered location data is posted to the database, via TCP2Database proxy

Steps involved in posting to the database:

1) Form the standardized packet from the filtered RFID data, with the below format:

struct packet { char header[4]; /* RPCS */ int seq; /* auto increment from 1 */ long long tag; /* tag_id or gsm number */ int ip; /* ip address of device */ int utc_t; /* time in C UTC representation */ int latitude_d; /* latitude degree */ int latitude_m; /* latitude minute */ int latitude_s; /* latitude second */ int longitude_d; /* longitude degree */ int longitude_m; /* longitude minute */ int longitude_s; /* longitude second */ int vital_bpm; /* heart beats per minute */ int vital_sys_bp; /* systolic blood pressure */ int vital_dia_bp; /* diastolic blood pressure */ int flags; /* flags for various usage */ int conf; /* location confidence value */ }

2) Save the sequence number in the ACK-Expected queue

3) Establish connection with the TCP 2 Database proxy.

4) Send the packet and wait for reply message, validate the success, and match the sequence number of the message in the Ack outstanding queue.

5) Close the connection after every packet sent and ACK received.

Problem:

The packet structure should not be broken into multiple TCP Packets. The TCP 2 Database proxy treats the messages on per TCP Packet basis and validates the packet by size. This is not a good approach as TCP is stream oriented and does not make any guarantees of delivering data as a single chunk.

Facility Map

Concept In our software architecture the localized position is first sent in to a component containing a map of the facility, and then to the Kalman filter. The idea behind using a map is to improve accuracy and help filter through much of the noise in the measured distances. With knowledge of the asset's surroundings we can better determine if the new sampled position is probable given the previous sampled positions.

For example, if we first determine that the position of the asset is in the corner of a room, denoted by the black square in the following figure, and then sample the next position as being in the adjacent room we can use search techniques to find the shortest path distance from sample 1 to sample 2. Given the previous position, velocity, and acceleration we can determine if the new sample is probable and thus weight the observation accordingly.

Shortest Path Search The search technique we used to find the shortest path is the A* search algorithm. It is possible there is a better method/variation than A* to use for this application (such as Weighted A*), but for this project we focused on using the optimal path instead of a suboptimal path that could be computed faster. We ended up finding that my search algorithm was too slow in some cases to be computed between samples. Although the absolute distance between two points might be small, that does not necessarily mean the shortest path between the points in the facility is small. This

became obvious when testing the system and the program seemed to "hang" after obtaining a sample, although it was actually trying to find the shortest path. It turns out that there were a few instances in which the trilateration algorithm determined the localized position was outside of the building, and finding this position required a lot of computation (since the path to outside meant the person had to first go through the door at the entrance of the building) even though the absolute distance was only a few meters. Since this problem only occurred a handful of times we left it alone and noted it as something to improve for future iterations of the project. Despite the problem with computation time, this actually shows that the concept works very well since it is highly unlikely that something or someone could travel from a room in the building to outside within less than one second.

Once the distance is found between the two points, it is fed in to the Kalman filter to be used as a way to determine the importance of the last sample. The Kalman Gain is used to determine how much emphasis, or weight, should be placed on each sample. The gain can be "tuned" to achieve particular performance, which is exactly what we use the distance for. Based on the previous state of the asset and the distance given, we can come up with a rough probability that the asset actually traveled that far between samples, which can then be used to influence the Kalman Gain and place a higher or lower weight on the sample.

Filter and Modeling

Concept The noise in a system like this, mostly introduced by the RSSI, can be very overwhelming and lead to highly inaccurate results. Multiple solutions exist to reduce the impact of noise, ranging from simple mathematical techniques that eliminate "outliers" to complex mathematical techniques that model the entire system itself to discern between noisy samples and accurate samples. My project focuses on the latter technique in which we attempt to model the asset's movement and expected noise of the RFID tag message signals.

Possible Solutions During the research phase of this project, multiple filtering methods were considered and the tradeoffs were compared. The two main types of filters considered were the Kalman filter and Particle filter. Many papers have been written to compare the two and discuss their strengths and weaknesses, such as “Robust Extended Kalman Filter Applied to Location Tracking and Trajectory Prediction for PCS Networks” and “A Tutorial on Particle Filters for Online Nonlinear/Non-Gaussian Bayesian Tracking”.

According to the cited papers mentioned, the particle filter requires many particles (or samples) in order to work well and eventually return an accurate state. For this project, this property of the particle filter might not be very favorable since we can only obtain samples as fast as the RFID messages come in, which is anywhere between 2 messages per second and 1 message per 30 seconds, depending on a few factors. Because of this, it is difficult to provide more samples for the filter. The Kalman filter is also much better suited to handle Gaussian noise and linear systems. It is possible to model this system as linear, however that would lead to many problems since the asset's movements are under outside control (usually by a human). Because of this, the

Extended Kalman filter is much better suited as it is capable of better linearizing nonlinear systems.

One of the most difficult aspects of using a Kalman filter (or any filter for that matter) is choosing correct covariance matrices to model the system noise and expected state variables. Through measuring the mean and standard deviation of the signal strength at different distances we were able to come up with a rough covariance for the observation matrix, which is given below.

10 1 01 10 00 0 0.1

The transition covariance matrix was found by tuning it from previous values. It is extremely difficult to provide a good mathematical approximation for how the transition might vary so it seemed as though the best way to get good results is by tuning the values by intuition after observing results. There are likely many more accurate ways to do this, and they should be explored in the next iterations of this project.

As for influencing the Kalman Gain, we attempted a very naive approach and experimented with simply multiplying the calculated probability (or confidence) of the sample with the gain, thus reducing the gain if the probability was low. If given more time we would have liked to experiment with other methods of influencing the gain and the amount of influence we have on it. The resulting gain became

|

where Ps is simply the probability of the last sample.

4.3 Gastroenterology 4.3.1 Functionality

The primary goal of this project is to produce a wearable device that is capable of recording sound from the gastrointestinal tract including the stomach, the small intestine, and the large intestine. The device should ignore the noise produced by the wearer’s interactions with the environment. This includes eliminating the wearer’s speech and movement sounds; for example, the rubbing sounds produced by the movement of the device as the user is walking or jogging. Additionally, the device should record sound for an extended period of time – at a minimum of eight hours continuously. Since the device will be worn for a long time, the belt used to fasten the device to the user should be comfortable to wear yet tight enough to keep the device in place.

Once the sound has been recorded, it should be transferred to a remote server where it will be stored based on date and time. Additionally, the user should be able to set a flag if he wants the doctor to focus on some particular part of the recording. The doctor can then access these files to diagnose the patients without needing the patient to schedule an appointment. This implies that the device should be able to transmit data and that the data must be stored in an easily accessible manner for the doctor to use.

To meet the requirements, the group plans to use three different sensors to capture sound produced in different locations in the gastrointestinal tract which are above the stomach, the small intestine, and the large intestine. A Gumstix microcontroller will record the outputs of all of the sensors. The user will be able to interact with the device by of buttons, one to set a flag to mark an area of interest for the doctor, one to start the recording and one for stopping the recording and uploading the files.

The next section briefly describes how the sensors are built in order to meet the functional requirements. The detailed hardware design is described in Section 4.3.4 Hardware Architecture.

4.3.2 Components

The group designed two different sensors, built using two different design ideologies in order to determine a sensor which gives better performance.

The first sensor, shown in the Figure 4.3.2.1, uses a standard stethoscope head with an electret microphone inserted into the stethoscope head. The motivation behind this sensor was to evaluate the performance of a sensor which can be built using off-the-shelf components. The microphone converts the movement of the diaphragm in the stethoscope into an electrical signal. However, the diaphragm and the microphone are coupled by air, which introduces noise in the signal.

Figure 4.3.2.1 Sensor built using analog stethoscope head and microphone

The second sensor was designed using the Thinklabs custom-built stethoscope sensor. The Thinklabs stethoscope combines the diaphragm of the stethoscope with the sensor for a much more compact form factor as well as providing an entirely electronic solution, which is especially desirable to minimize noise and other external signals and obviates the need for a separate microphone to measure ambient noise for cancellation in post-processing. Figure 4.2.2.2 shows the sensor built using the Thinklabs stethoscope head. The figure also shows the components required to convert the output from the Thinklabs sensor into a USB signal. This sensor has a better noise rejection ability than the sensor described previously. Because of this behavior, we decided to use this sensor design in the final device.

Figure 4.3.2.2 Final sensor design using Thinklabs’ stethoscope sensor

The device will have three such sensors connected to a USB hub, which in turn is connected to a Gumstix controller, which records the sound coming in via the USB hub. The Gumstix will then upload the sound files to the remote server when the user requests the transmission to take place. The details of this sensor design will be explored in Section 4.3.4 Hardware Architecture.


To test the performance of the sensor in real-world conditions, we recorded five minute audio clips while a volunteer (Professor George Loewenstein) performed various activities. Initially, a five minute audio clip was recorded in silent conditions to get a baseline signal. This was followed by recordings while the volunteer was talking, walking, and after he had ingested Ensure, a liquid high in fat and protein. Figure 4.3.3.1 shows the audio waveform corresponding to the baseline signal.

ThinklabsSensor

USBInterfacetoGumstix PCM2912A

Atmega

Figure 4.3.3.1 Audio waveform as seen on Audacity corresponding to the baseline signal.

Particular attention was paid to the noise produced when the volunteer was moving and talking. The sensor picked up substantial noise when the volunteer was walking. Figure 4.3.3.2 shows the audio waveform corresponding to the recording as seen on Audacity, an open-source audio-recording and editing software. The large number of spikes correspond to the volunteer walking as well as cable noise.

Figure 4.3.3.2 Waveform corresponding to the recording while the volunteer was walking.

It was observed that the sensor was picking up the volunteer’s speech but was able to ignore other people’s speech. Figure 4.3.3.3 shows the audio signal as seen on Audacity while the volunteer was talking. Several spikes corresponding to the volunteer’s speech are seen in the audio waveform.

Figure 3.3.3.3 Waveform corresponding to the recording while the volunteer was talking.

We also took some recordings with the sensor in different locations of the stomach region. However, all the signals shown above had the sensor in the same location, which was to the left side of the stomach.


4.3.4.1 Overview:

A high level overview of the architecture is shown in Figure 4.3.4.1.1

Fig. 4.3.4.1.1 Hardware overview.

Fi Fig 4.3.4.1.2. Hardware photo.

The Thinklabs sensor acts as the microphone element in the design and is used to get a preliminary signal from the gastrointestinal regions. The signal is then amplified and sent to the PCM2912a USB audio interface. Section 4.3.4.2 describes the USB interface hardware. The USB signal generated is sent to the Gumstix controller via a USB hub. The Gumstix controller will then upload the recorded data to the remote server.

Compared to the conceptual design stage of the project, there is a major difference in the chip used to convert the audio signal into a USB signal. The chip we have used, PCM 2912a from Texas Instruments (TI) was not our top choice on the product feature matrix, but had other benefits which made the design simpler. By choosing a USB audio codec that had an analog to

Microphone Element (Thinklabs sensor)

Amplifier

Convert to USB (PCM2912a)

USB

Hub

Server(RemoteStorage)

Gumstix (Storage & s/w filter)

USBpowercablesGumstixboardUSBdatacablesInterfaceboards

BatteryWiFiantennaeUSBhubStethoscopeheads

digital converter built in, we were able to minimize external components, making the PCB easier and faster to design. TI has quite a few USB codecs that have built in ADCs, however the PCM2912a also has a microphone preamplifier which allowed us to use both the Thinklabs sensor or a standard analog microphone. In addition, the PCM2912a had the highest signal to noise ratio out of all of the TI USB codecs. Hence by using the TI PCM2912a chip we are able to change the sensor (analog stethoscope head or Thinklabs stethoscope head) while maintain a high signal to noise ratio along with pre-amplification. In order to keep the hardware simple and to reduce the size of the device, we decided to use software filtering. Preliminary tests show that software filtering can give us good results. Software filtering gives the added advantage of variable frequency cut-offs without changing the hardware design. Filtering will not take care of the noise signals that are in the same frequency range as that of the stomach sounds. For removing these components, we are looking at recording an isolated noise signal and subtracting it from the recorded signal.

4.3.4.2 USB Interface Hardware:

The USB interface for the Thinklabs sensor is based around the PCM2912a USB audio codec from Texas Instruments. Although the codec is designed primarily for sound output, it also has a microphone input. It also requires very few external components, the most expensive being a 6 MHz crystal oscillator.

The Thinklabs sensor has a line level audio output which is sent through a gain stage that acts as a volume control. It is then piped into the audio input on the codec. The sensor also requires a control signal that triggers a charge pulse which is required for the sensor to function properly. It only needs the pulse for around one second every ten minutes. This pulse is triggered by an 8-bit Atmega168 processor, which will also retrigger the pulse after 10 minutes. One of the features of the codec is an output that indicates when recording has been triggered by the PC. This output is used by the Atmega to trigger the pulse every time recording is initiated. The codec also has a mute button input, which is also used by the Atmega to disable audio input during the pulse. Figure 4.3.4.2 depicts the hardware diagram.

Fig. 4.3.4.2 Hardware diagram for the input signal

4.4.3.3 Power Interface:

The power for the device is currently derived from the USB bus, which provides approximately five volts. We have designed a battery-based power supply in order to make the device mobile.

The Thinklabs sensor requires a clean five volt input, which is achieved by using a boost converter to boost the voltage up to six volts and then a low dropout five volt regulator to provide clean power. The Atmega has control over the enable on the boost regulator so that it can shut it down when the sensor is not active. The codec has an output which indicates the USB suspend state, which will be used to trigger the sensor shutting down as well as the Atmega going into a low power mode.

The circuit has been assembled on a two-layer circuit board using primarily surface mount components. All of the surface mount components were placed on one face to making mounting (as well as assembling) the interface easier.

To power our USB interface, we used a Lithium Ion battery pack that is designed as a cell phone backup battery. The battery pack provides two five volt regulated outputs in the form of USB ports. These were very easy to connect to both the USB hub which powers the interface boards as well as to the Gumstix board. The battery pack chosen had one port rated for two Amperes and one port rated for one Ampere. This is well within the needs of our system. The capacity of the battery should also be enough to last for a day of recording. The battery also charges with a standard USB connector, and it has all of the necessary charging circuitry built in. This alleviated the need for an external charger. Because the battery pack is a consumer device, it was inexpensive and very easy to work with. Another good reason to go with this type of battery pack is that it would be easy to source one that is a different shape to integrate into a different mechanical design. As far as our design, the battery will be placed onto the back of the belt using Velcro.

Figure 4.3.4.3 Hardware diagram for the power supply circuitry.


We require software support for carrying out three functions: start and stop the recording, filter the sound recorded, and upload the recorded clips to the server. The software is still in initial phase with only prototyping done. Software will be the main focus of the group for the next phase.

4.3.5.1 Recording Audio:

We have written a Perl script that is launched automatically when the Gumstix is powered up and responds to a user input via a push button to start recording. When it detects that the user has pushed the button, it will start recording three different tracks, one from each of the three sensors, each for 570 seconds, or 9.5 minutes, and pauses for half a minute before recording again. This way, we set all three tracks to be synchronized on 10-minute intervals, allowing for any buffer overruns that may happen during the recording. Preliminary experimentation has shown that 30 seconds of delay is enough to absorb the potential buffer overruns during the 570 seconds of recording.

4.3.5.2 Filtering Audio:

We have been successful in filtering out some noise using the SoX toolkit. We used a low pass filter to cut out sounds above 1000 Hz and then checked the output frequency spectrum to see the frequency range. However the filtering does not take care of noise signals which have the same frequency as the frequency range of the stomach sounds. For example, the voiced speech of a typical adult male will have a fundamental frequency from 85 to 180 Hz, and that of a typical adult female from 165 to 255 Hz; a simple low pass or band pass filter will not work for this frequency range, since this frequency overlaps with the frequency range of our required audio signal. Filtering out this noise will require a combination of hardware and software. We are looking at using an external microphone, either a throat microphone or a standard microphone placed close to the sensors, for recording the external noises. This noise signal will then be subtracted from the recording to get a clear audio output.

4.3.5.3 Recording Flags:

The aforementioned Perl script will also respond to a different button press by the user for the recording of alerts. These alerts are meant for the caregiver or the doctor of the user of the device as a way to focus in on important events from a gastrointestinal perspective, such as the ingestion of food or moments of high stress. The timestamps of these button presses are recorded on the Gumstix microcontroller and uploaded when requested.

4.3.5.4 Uploading Data:

The aforementioned Perl script will start uploading all the recorded sound clips when a user presses a button corresponding to that command. We only transmit when a user requests because, since the data will be continuously for a long period of time, the data size will be large. If we

transmit data real time, the device may run out of battery charge or be in a location without a WiFi connection. We expect the user to send the request only when the device is charging. The script will also transmit important information like the patient name, time and day the clip was taken and any flags if set by the patient. Once all clips are uploaded, the script waits for the user to start recording again.

4.3.6 User Interface

As we have already mentioned, the user of our device will be able to interact with it via the three push buttons: one to start the recording of sound clips, one to record flags, and one to end recording and start transmitting. All of the data – the sound clips and the flags – will be available for further analysis once transmitted to the remote server for central storage.

4.3.7 Future Work

We are also thinking about using extra sensors for cutting out external noise as well as noise produced by the wearer’s actions. For example, it might be possible to synchronize the wearer’s movement by using an accelerometer. This could help in filtering. Also, the wearer’s speech can be detected by an external microphone and filtered out of the recorded signal.

Subtracting the noise signal from the recorded signal can require significant computing power, which might not be available on the Gumstix controller. Therefore, this filtering may have to be done on the remote server.

4.4 Vital Clip 4.4.1 Functionality

The VitalClip is focused on reading a user's pulse on the finger tip. The circuity must be compact, low power, and able to read pulse across a wide range of skin conditions. At the heart of the VitalClip system is the SDT1-028K shield piezoelectric sensor as seen in Figure 4.4.1.1

Figure 4.4.1.1 The SDT1-028K shielded piezoelectric sensor used in VitalClip

When this sensor is paired with a 10 Mohm resistor, its lowest frequency response is reduced under 0.7 Hz, which is small enough to include a human pulse at 1Hz . This sensor is shielded, which reduces external electromagnetic noise. Given the low strength of the signal, this is

paramount. An existing product that uses a piezoelectric sensor to meter pulse at the finger tip will be used as a point of reference. This sensor, called Model 1010, was used as standard and to verify our results and to ascertain if the Model 1010 would be a better fit. Its design is entirely passive and benefits from a gel coating and attachment strap. The Model 1010 sensor is shown below in figure 4.4.1.2.

Figure 4.4.1.2 – The Model 1010 sensor stock image

The Phoenix circuit, shown in figure 4.4.1.3 provides the filtering and amplification to the signal from the SDT1-028K sensor. This circuit was based upon a research project to detect pulse at the wrist with a piezoelectric sensor. The Phoenix circuit provides +30dB to signals under 10 Hz. This range covers the entirety of human heart rate. The gain quickly attenuates down to +0dB at 50Hz

Figure 4.4.1.3 The circuit schematic for the Phoenix circuit

In order to get the output of the signal conditioning circuit in to the Custos's server system, a small microcontroller with analog to digital conversion was needed. Also, this circuitry would be responsible for simple peak detection to derive the subject's heart rate. For this purpose, and Arduino Uno, shown in figure 4.4.1.4 was selected.

Figure 4.4.1.4 The Arduino Uno microcontroller that runs VitalClip's code

Thus, VitalClip and Smart Orthopedics would use the same microcontroller which would simplify data transmission. Another benefit is that the Arduino Uno has built in analog to digital converters with ten bits of precision. For the accuracy needed for peak detection, this was more than sufficient. Once the signal exceeds a manually calibrated threshold, it is counted as a beat. The Arduino counts beats for 15 seconds, and then computes a beats per minute value.

4.4.2 Background work and Prototype

Once the circuit designs were finalized, construction began. Initially Vital Clip used a circuit mentioned in the paper ‘Piezoelectric sensor determination of arterial pulse wave velocity’ for testing the piezo sensors that were ordered. The circuit essentially was a combination of 3 different parts of signal conditioning.

1. A charge amplifier – used to amplify the output voltage of the sensor. 2. An inverting summing amplifier – used to remove the DC offset from the output of the

sensor. 3. A Chebyshev filter – used to filter out high frequency noise from the output.

The charge amplification circuit is shown below.

Figure 4.4.2.1 Charge Amplification circuit

Piezoelectric materials convert mechanical stress or strain into proportionate electrical energy, by producing a charge when subjected to mechanical stress. The charge is converted to a voltage by an operational amplifier connected as a current integrator, called a charge amplifier (Figure 4.4.2.1). The signal output of the amplifier is approximately −30 mV. It is augmented by signal amplification.

The inverting summing amplifier is shown below.

Figure 4.4.2.2: Inverting Summing amplifier

The circuit shown in Figure 4.4.2.2 serves the dual purpose of DC offset removal and also signal amplification. This is done by use of an inverting amplifier. Because a DC signal appears at the output of the charge amplifier, DC offset removal is essential and is implemented in the inverting summing amplifier shown in Figure 4.4.2.2. The next phase of the analogue circuitry is a low pass filter to remove the 50 Hz noise interference.

The circuit for Chebyshev filter is shown below.

Figure 4.4.2.3 Chebyshev filter

This low pass filter shown in Figure 4.4.2.3 is used to filter out the noise that the piezoelectric sensors pick up due to various factors like motion artifacts, power line signal etc. The filter is designed in a way that rejects all noises 50Hz and above. The frequency of the pulse of a person is ideally 1.2 Hz. With such a wide band of frequencies permitted, results from the signal were unusable from a practical standpoint as seen in Figure 4.4.2.4.

Figure 4.4.2.4 The human pulse output of the original circuit

The original circuit proved to be ineffective and was abandoned early in the project. But, the Phoenix circuit was exactly what was needed for VitalClip. This circuit currently resides on a breadboard. It consists of a series of filters and signal amplifiers. One advantage of this circuit is its power consumption. It consumes approximately 0.33 mW at maximum load. This makes it a very good candidate for a mobile application. Also, it runs at 3.3V which is one of the voltages that an Arduino can natively supply. The cost of all the components is under ten dollars. The combination of low power and low cost make the Phoenix filter a great fit for the VitalClip and Custos platform.

Figure 4.4.2.5 The instance Phoenix circuit being used to test VitalClip


The Phoenix circuit provided great gains and clarity. The Model 1010 and the Phoenix matched chronologically, but the Phoenix circuit has much higher gains as seen below in Figure. The Model 1010 has a peak of approximately 100mV. This would be far too low for our system. The Phoenix circuit has a peak of over 1000mV above its baseline noise.

Figure 4.4.3.1: Output of the Model 1010 and the VitalClip at the finger tip.

VitalClip is the lighter waveform on top, Model 1010 is the waveform below. The greatest variation in our results was due to the method used to hold the sensor against the blood vessel. Poor technique would result in no signal or bring the entire output to the highest value, while proper form yields extremely clear results.

Figure 4.4.3.2: Initial readings using the VitalClip sensor with Model 1010 as a reference

To achieve the clearest signal at the finger tip, significant pressure had to be applied. Also, the joint needs to be used to cut off blood flow with the piezoelectric sensor between the finger joints. This gave a consistently viable signal. In addition to the peculiarities of holding the device, the piezoelectric sensors are sensitive to vibrations, including those created by movement of the subject hand. Since the filter design is low pass, most physical vibrations can show up in the signal.

From that signal, the beats per minute are derived on the Arduino. A simple peak detection is used with a hard coded threshold value. This threshold value is hand calibrated and any changes to the circuit or pulse location require changes to the value. Once the value was calibrated for the current configuration, the Arduino was returning beats per minute via serial communication with the connected computer. Once the technique was sufficiently good, the Arduino setup was returning consistent measurements in the range of 60 to 70 beats per minute in laboratory conditions. For comparison, there are not more precise methods available to us to determine heart rate. Our results are in line with the average heart rate for a human adult and have shown correlation with physical activity.


Our system fits into the hardware architecture as one of the vitals sensors. Once a pulse reading is available, we wirelessly connect to the main system using Smart Orthopedics team’s GSM Module. We are using an Arduino Board as the data acquisition system. Using a USB based data acquisition system, we convert the analog signal of the sensor into a digital signal which is then

converted into a packet and send to the data base using a TCP connection. The GSM Module is also used by Smart Orthopedics team to send the GPS information of a subject. Figure 4.4.4.1 shows the conceptual mapping of VitalClip onto the system hardware architecture.

Figure 4.4.4.1 Mapping of VitalClip onto Hardware Architecture

The final hardware setup for Vital Clip is shown below in figure 4.4.4.2

Figure 4.4.4.2 Hardware Setup of Vital Clip

4.4.5 Mock-ups and physical prototypes

Most of the hardware setup has been described and shown above. In this section we show a user using the hardware setup and describe some addition components added to the sensor to ensure a stable and consistent output. The physical prototype of our system being used by a user is shown below in figure 4.4.5.1

Figure 4.4.5.1 Hardware Prototype of Vital Clip

As noticeable from the figure above, we added a Velcro Strap to the sensor along with a gel between the finger tip of the user and the sensor. We also added an additional capacitor to the original circuit described in section This was done to stabilize the output and to produce consistent results when using the sensor. The reasoning for using these is given below.

1. Velcro Strap: The Velcro strap is used for two reasons. a. Reduce motion artifacts by ensuring the sensor does not move during

measurement. b. Ensure that the position of the sensor is done is a specific way. This is

required because the sensor produces different results based on the way it is held. For more explanation see the figure 4.4.5.2 below.

Figure 4.4.5.2 Effect of sensor positioning on output

One should remember that the results of the above figure are based on the sensor being used at the wrist and not at the finger tip. We noticed that if the fingers were placed together when holding the sensor, then it gave positive peaks corresponding to the pulse. But when he finger were placed apart to hold the sensor, then the sensor produced negative peaks corresponding to the pulse. Hence, to avoid this discrepancy, we used a Velcro strap to have a singular way of using the sensor.

2. Gel: We used a gel as an intermediate medium between the skin at the finger-tip and the sensor to reduce noise due to motion artifacts. We noticed that the noise in the output without the sensor was high and that Model 1010 sensor was using a gel medium to transmit that pulse motion at the finger-tip to its underlying circuitry. We thus figured that using a gel might improve the output and wanted to test out theory. We used a toe separator of thickness of 3 mm and found that the results were much more consistent.

3. Additional Capacitor: The additional capacitor was added simply to stabilize the input to the signal conditioning circuit and nullify any voltage surges.

4.4.6 Vital Clip Data Communication

Now that we had a mechanism for ascertaining the heart rate on the Arduino board, we needed a way to get it to the backend server. We decided that the most efficient way to do this was to piggyback upon SmartOrthodic’s Telit GSM module. We would count beats over 30 seconds and then transmit twice that number as the beats per minute. We decided on 30 seconds because we felt it would be accurate enough and allow us to make consistent, timely updates.

We made several different attempts to get the communication between the two boards to work. First, we tried to setup the Serial interface between the two boards, however, after many hours of trying, we were unable to get the Arduino board to read replies from the Telit, possibly due to

differences in voltage levels. At this point, since we knew we could only send from the Arduino to the Telit via the Serial line, we looked into sending AT commands from the Arduino to the Telit board to do the data communication. This, however, was also ill-fated, because the Telit board’s Python script would lose the ability to send its own AT commands once an outside source started sending them. That left us with only one option.

We were forced to our last option, using the Telit boards General Purpose Input/Output (GPIO) pins to communicate with the digital input/output pins on the Arduino. We wanted to avoid this method because it meant developing our own protocol to ensure that our data was transmitted successfully between the boards. We also knew we were limited in the number of GPIO pins available on the Telit board because some of them were multiplexed for other purposes. After a thorough accounting of the pins, and some trial and error, we were able to find six usable GPIO pins. We developed our own two-bit handshake protocol, one signal driven by each board, plus four data transmission signal bits, all of which were driven by the Arduino. The two-bit handshake protocol allowed the two boards to essentially get a lock on the other, so that we knew they were ready to send and receive data at the same time. To start a data transmission, the Arduino would raise its signal high, indicating that it had something to send. The Telit board would see this and acknowledge it by raising its own signal high. Once the Arduino saw the acknowledgement it would write the four data bits and drop its handshake signal low. At this point, the Telit board would read the drop in the signal and get the data from the lines. Once this had happened, the Telit board would drop its signal low and both boards would move on to other things.

Since we only had four data bits to communicate data between the two boards, we had to make multiple handshake transactions to fully communicate between the two boards. We built in the ability to transmit three full bytes, or six handshake transactions, between the two boards. The first byte was used for the heart rate, the second was used for diastolic blood pressure and the third for the systolic blood pressure. This allows the system’s functionality to be expanded in the future.

Once we had identified the correct GPIO pins to use, this protocol actually worked very well assuming that the boards were mutually grounded. We ran into some problems when designing the system due to ghost pulses on the Arduino board, which has very sensitive digital input/output pins. Once we transmitted the data to the Telit board it was packaged into its data packet and sent to the backend server.

4.4.7 List of Components

Component Manufacturer Purpose Cost

Piezo‐ElectricSensor(Sen‐10293)

MeasurementSpecialties(SDTSeries)

Primarysensor Lessthan$5

CustommadePCB N/A Signal

Processing $50

ArduinoUno Arduino A/DConversion $20

Table 4.4.7.1 Table of Components for Vital Clip

4.5 Software Infrastructure


A modular architecture is designed to incorporate multiple hardware units, application processing elements, and user interfaces. The system architecture is divided into discrete layers - User Interface, Software, and Hardware. (i) The User Interface layer defines and implements modules that are specific to application contexts, such as an application specific user interface that displays information to users. (ii) The Hardware layer is responsible for the implementation of all hardware functionalities and for transmitting sensor data to the Software layer. The hardware layer can comprise discrete sensors - Smart Orthopedics, Gastroenterology, Vital Clip - each trying to pass sensor information to the processing layers above. (iii) The Software layer is responsible for processing data, storing data, and providing a communication protocol between the User Interface layer and the Hardware layer. And, for ease of expandability, the software architecture layer is further divided into sub-modules. Each sub-module is responsible to handle a specific defined functionality. The various sub-modules of the software architecture layer are - a HTTP server, a Data Processing Unit (DPU), a database, and a TCP to HTTP proxy server.

The overall system architecture is as shown in Fig 4.5.1.

Fig 4.5.1.1 System Architecture

4.5.2 Functionality

The backend Software layer is the core component of the Custos system architecture. It is responsible for a number of important tasks, including most data processing, providing a communication mechanism between the hardware layer and the User Interface layer, and storing data. The backend software is essentially a web server, and it has three main components: HTTP server, TCP-to-HTTP proxy, and database.

4.5.2.1 HTTP Server The HTTP server acts as the central hub of the software backend. It is responsible for processing all requests from the User Interface layer programs and data from the Hardware layer. Given that a client provides a script in advance, applications can invoke the server with an HTTP request to invoke the Data Processing Unit (DPU) within the server to run scripts to do custom data processing remotely on the server.

4.5.2.2 TCP-to-HTTP Proxy

The TCP-to-HTTP proxy is responsible for converting TCP messages into HTTP requests. Some hardware devices, such as the VitalClip device and the Smart Orthopedics device, only support TCP communication, and the HTTP server can only handle HTTP requests. The TCP-to-HTTP proxy acts as the middleware that translates data from hardware devices in the form that the HTTP server understands.

4.5.2.3 MySQL Database

The database is responsible for storing all data, such as client profile and sensor data. It is completely isolated from all modules except for the HTTP server; that is to say all other modules must communicate with the server in order to access any information in the database.

4.5.2.4 Data Processing Unit (DPU) Multiple applications running in the UI layer might require the same kind of data processing to be done on the sensor information logged into the database. To avoid duplication of effort in the UI layer, a Data Processing Unit is included in the Software Layer. The UI layer can specify the functional parameters required for processing - e.g. Location boundaries (in case of Smart Orthopedics), Frequency sampling rate (for any audio sample recorded in the database), and so on. The DPU is then responsible for processing the raw sensor information (in the server itself) and logging only relevant information into the database. The UI layer can request this information from the database directly. Thus, having a separate DPU saves different applications doing the same kind of data processing.

4.5.2.4 Runtime Overview

The runtime diagram (Fig 4.5.2.1) visually represents the overall operation of the system that was described in Section 4.5.1.

Gastroenterology devices upload data to the server via HTTP POST requests. The device may also post ‘alerts’ to the database when the user presses a button on the device. The front-end can list and play the available audio files through separate HTTP requests.

Smart Orthopedics and Vital Clip devices must request the TCP-to-HTTP proxy to forward their data packets to the HTTP server while the front-end will retrieve data directly from the server using HTTP requests. Every time Smart Orthopedics uploads new data, the Data Processing Unit (DPU) does any necessary data processing before storing it to the database.

Fig 4.5.2.1: Runtime Diagram

4.5.3 Testing

4.5.3.1 Front-End

To test front-end functionality, we created a user interface where we simulated data input and monitored the database changes that were incurred. This test was configured to support general possible user functionalities for a web application. We tested correctness by verifying the database status and return values after using functions such as, register_user, / (log_in), register_device, follow_user, get_patients, and forgot_password.

The Smart Orthopedics front-end was tested by tracking the user on the Google Map API and displaying focal zones set by administrators for certain users. This test was configured to track the user wearing a certain device ID in real-time. We tested correctness by carrying the device to different locations and verifying that the locations were updated on the web application that correspond to the wearer.

The Vital Clip front-end was tested by monitoring user’s vital data through a graph representation. This test was configured to retrieve and view vital readings for the logged-in user. We tested correctness by determining the current user and verifying that the graph representations reflect the most recent heart rate and blood pressure data for that user.

The Gastroenterology front-end was tested by playing a recording of a sound clip generated by the device. This test was configured to retrieve and view sound recordings for the logged-in user. We tested correctness by determining the current user and verifying that the sound generated reflect the most recent audio file that was uploaded for that user.

4.5.3.2 Back-End

To test back-end functionality, we used programs which simulated data coming from an actual hardware sensor.

The Smart Orthopedics and Vital Clip back-end was tested with packet_test. This program constructed a packet of random (but valid) data and transmitted it to the TCP-to-HTTP proxy. It would then wait for an ACK from the proxy. The test could be configured to send a variable number of packets to the server. We tested correctness by using this program to send packets and then querying the database to verify that the data was entered correctly.

We used upload_test to test the Gastroenterology back-end. This test simply sent a request to our server to upload a file to a specified Gastroenterology device ID. The test was also modified to test ‘alerts’ which simulate the user pressing the button on the device. As with packet_test above, we checked correctness by first running the test and then verifying that the data had successfully reached the database.


Both the TCP-to-HTTP proxy and the HTTP server have the desired functionality. The TCP-to-HTTP proxy can successfully receive packets from the hardware sensor and forward the data to the HTTP server in the form of an HTTP request. It will additionally ACK the sensor upon success. The HTTP server implements the back and front-end APIs for the Smart Orthopedics, Vital Clip, and Gastroenterology described above. User management and sessions are supported, but secure connections (presumably via SSL) have not been implemented. Given our current system, this should be an easy upgrade. Despite some stability issues (which became apparent on demo day), our system was reasonably stable during our test workloads and previous demos. It is possible that the issues encountered during the demo were due to ‘too many’ concurrent connections or resource exhaustion on the local filesystem. In any case, further testing and development would need to be done in order to improve the robustness of the system.

4.6 Conclusions 4.6.1 Requirement Feature Table

DesiredFeatures Status

Audio recording from three locations in the gastrointestinal area Completed

User interaction via buttons for alert flags Completed

Remote storage of sound clips for future analysis Completed

Alert message IncompletedAccessibility of front end design CompletedAddition of users CompletedMeasurements of pulse rate CompletedIndoor and outdoor tracking CompletedTCP/HTTP request transformation occurs for incoming sensor data

Completed

Session-based user system CompletedDatabase isolation from non-server code

Completed

All data-processing happens at HTTP server

Completed

All communications use one protocol (HTTP)

Completed

All data transactions go through HTTP server

Completed

Complete integration between front-end and back-end

Completed

Smoke tests passed CompletedBlack-box testing passed CompletedWhite-box testing passed Achieved

4.6.2 Summary of Key Design Issues

4.6.2.1 HCI

The current front end design of Vital Clip page has a problem that if different user logged into the system, the user won’t able to see other users’ information as the user id has been hardcoded at the login API.

4.6.2.2 Smart Orthopedics

No design issue was reported.

4.6.2.3 Gastroenterology

On the hardware front, the main issues were in designing the USB interface. The first was how to power the device. We decided to go with using the USB port to provide power. This would allow the device to only have two connections, a USB port and the connector for the sensor. This would also make it very easy to connect multiple sensors to a computer using a USB hub. The second problem to be solved was the type of USB audio interface that would work the best. Our best solution was to use an of an off the shelf USB audio class codec. This IC, the PCM2912a, has support for the USB audio class, which means that it can run under Linux, Windows or Mac OS without any extra drivers. This decision was made to make the interface easy to use, as well as portable. This IC was also chosen because it has an output, which is intended for an LED, that indicates that a recording is in process. By using this signal from the codec, we use a microcontroller to trigger the charge pulse for our ThinkLabs stethoscope sensor. Without that LED output, we would have to find a way to manually trigger the pulse. Another problem was that the ThinkLabs sensor that we chose requires a very clean power source. To provide clean power to the ThinkLabs sensor, a boost converter is used to step the five volt USB power up to six volts A low dropout linear regulator is then used to step the voltage back down to the five volts that is needed by the sensor. The circuit is designed using surface mount components, because size is a major constraint for mounting in the belt. All of the components are placed on one side so that there is a good mounting surface on the back. This also makes it easier to assemble.

On the software front, the main issue we encountered was the difficulty of using existing software and dealing with software library dependencies. Though much open source software was available for our purpose, they are often either unavailable for the Gumstix platform from the central Angstrom repository (a software repository used for the platform), or recompiling would require numerous levels of software dependencies that sometimes would not be available for our platform. We eventually settled on some built-in Linux functions that were rudimentary but were able to complete the task for us.

4.6.2.4 Vital Clip

No design issue was reported.

4.6.2.5 Software Infrastructure

There are three major design issues we considered in designing the overall software architecture. Our goal was to design a system that exhibits both efficient performance levels and flexible extensibility. In order to achieve such goals, our system needed to be based on a common framework with modularity and abstraction to fulfill the purpose of routing all data through a single powerful server and creating layers for database abstraction. As a result, the Flask web framework, which is a lightweight web application framework written in Python, was chosen. Although Flask has its cons (unable to process code in the background), these did not affect our application which is event-triggered. The pros that greatly outweighed the cons for our purposes were that it allows for great extensibility and provides a development server and debugger.

4.6.2.1 Modularity

Modularity in design was represented in how all data transactions go through the HTTP server. The TCP-to-HTTP proxy acts as a middleware that translates data from hardware devices in the form that the HTTP server accepts but all communications essentially use one protocol. Once all the data is converted into HTTP format, all data processing along with HTTP requests and database requests happen at the HTTP server.

4.6.2.2 Abstraction

Abstraction in design was represented in how the database is securely isolated from every module except for HTTP server. In client-based web applications, the database is responsible for storing all data, such as client profile and sensor data. In order to ensure security, we prohibit direct access to the database such that all other modules must communicate with the server in order to access any information in the database.

4.6.2.3 Flask Web Server The HTTP server is implemented in Python using the Flask micro-framework. The Flask framework is a developmental framework for web developers, and it was chosen because it allows easy creation of robust web servers. Flask routes requests for certain URIs to handlers that we define. It also supports parsing of form and query-string data for our functions that require GET and POST requests. This functionality proved to be useful in our final implementation when we added event-triggered data processing and functions that required more complex queries. The Flask framework also has a SQLAlchemy library that works as the database abstraction layer with MySQL which is used for our database communications. We chose to use MySQL for the database since it is well-supported and has several libraries which allow us to communicate easily using Python.

4.6.3 Lessons Learned

Standard software solutions may be a challenge to implement on the Gumstix controller, due to various dependency issues.

For keeping the device small and power efficient, it is necessary to carry out the filtering on the software side of the design.

Additional hardware will be required for robust filtering.

Communication. Close contact between all groups from the start would have helped us avoid several issues. The groups were initially rather isolated, so the groups did not have a clear idea of what each other group was doing. This led to issues during the early parts of phase three when we started integration. Once we started communicating more and working together in larger groups integration went much more smoothly.

Integration. While parts of the system may have worked well by themselves, certain problems were not uncovered until the full system was actually integrated. Integration of the system can be difficult and should be done as soon as it’s possible.

Version Control. Since the code base was shared among five people, a revision control system (in our case, git) was critical in managing the project.

Make a blocking send call, and not non-blocking version to ensure that the entire packet data is sent in 1 chunk (high probability).

Avoid size based validations, rely on custom header – data – checksum protocol to detect the reception on valid messages.

There were a couple of lessons that I experienced while working on this project was that it is sometimes best to go ahead and order full hardware evaluation kits. I believe this can greatly increase the productivity and reduce possible errors in relation to the hardware performance. Although this will not eliminate all the associated errors that we particularly experienced, it would have saved quite a bit of debugging time and would have given us a greater deal of confidence in an actual working board. The next lesson that I encountered is that people need to be told exactly what to do when they are in an unfamiliar area of work. There were multiple instances of people not actually doing the correct work in relation do what was being discussed due to the lack of information and perspective for the individual. This led to some chaotic moments where details and features fell between the cracks of the overall design of the project.

5. Project Management 5.1 Implementation and Integration phase results

5.1.1 Task Dependency Chart 5.1.1.1 HCI

The overall front end design of the web based mobile application implemented by the HCI group is dependent heavily on the software infrastructure group. The HCI group uses the database and HTTP request api implemented by the software group. The stored data in the database of server is coming and stored by the each sub groups, such as Smart Orthopedics, Gastroenterology, and Vital Clip.

Factor Dependency

Login and Registration pages Software Infrastructure group

Smart Orthopedics page Software Infrastructure group and Smart Orthopedics

Gastroenterology page Software Infrastructure group and Gastroenterology

Vital Clip page Software Infrastructure group and Vital Clip

Table5.1.1.2DependencyChartforHCI

5.1.1.2 Vital Clip

The progress of Vital Clip depended mainly on internal factors and was not affected by the work of other teams. The only phase of the project in which we depended on another team’s progress was the communication link of Vital Clip. As mentioned in section 4.4.8, our communication to

the database was based on the GSM Module of the Smart Orthopedics team. We have listed our dependencies throughout the project in table 5.1.1.2

Factor Type Phase

DesignofDataAcquisitionSystem

Internal Phase1

Procurementofsecondarysensors

Internal Phase1

ProcurementofShieldedPiezoElectricSensor

Internal Phase2

ProcurementofPCB Internal Phase3

ProcurementofGelforsensor Internal Phase3

DesignandImplementationofCommunicationSystem

Internal Phase3

Table5.1.1.2DependencyChartforVitalClip

5.1.2 Summary of Work Log Hours for Phase 3 5.1.2.1 HCI

A–Admin,B–UserInterfaceDesign,C–Class,D–GroupMeeting,E–Research,F–Leaders/StaffMeeting,G–WritingReports/Presentations,H–WebsiteDesign,I‐Coding

Name A B C D E F G H I Total Hours

Carlos Gil

Min Hun Lee 0 1 12 6 2 0 13.5 20 0 54.5

Vishal Agrawal

Total Percentage % % % % % % % % %


Name A B C D E F G H I J Total Hours

Andrew Konecki 14 3.75 4 65.5 61.75 149

Scott Robinson 2 17.5 9 19 11.5 19.25 103.75 182

Mike Ralph 3 15 6.75 4 49.75 10 88.5

Ram Shankar 2 6 2.5 3.25 7 4 24.75

Keith Williams 3 2.5 3 22 30.5

Kartik Kulkarni 11.5 4 2 2.5 11.5 16 47.5

Total 7 67 28.5 19 621.2

5 156 22 195.5 522.25

Percentage

1.30%

12.80%

5.40%

3.60%

1.10% 4%

29.80%

4.20%

37.50%


A-Admin,B-User Interface Design, C-Class, D- Group Meeting, E-Research, F- Leaders/Staff Meeting, G –Writing Reports/Presentations, H – Field Testing,I – Design Engineering, J -Coding

Name A B C D E F G H I J Total

Hours

Curtis Layton

0 0 8.5 3 1 1 2 0 17.5 0 33

Ameya Ambardekar

0 0 10.3 2 2 2 7.5 0 9.75 7 40.6

Lei Fan 0 0 16.3 0 0 1 0 0 0 11.5 28.8

Total 0 0 35.1 5 3 4 9.5 0 27.25 18.5 102.4

Percentage (%)

0.0 0.0 34.3 4.9 2.9 3.9 9.3 0.0 26.6 18.1

5.1.2.4 Vital Clip

A – Admin, B – Design Engineering, C – Class, D – Group Meeting, E – Research, F – Leaders/Staff Meeting, G – Writing Reports/Presentations, H – Field Testing/User Testing, I-Coding


Michael Bucher

1.25 9.5 7.5 7 3 4 6 4 3 45.25

Sai Nanduri 1.25 10 7.5 7 3 0 7 5 4 44.75

Brian Pfiffner

1.25 0 1.5 8 1 0 3 5 0 19.75

Joe Berman 3.5 0 13.5 5.25 1 0 0 2 30.5 55.75

Total 7.25 19.5 30 27.25 8 4 16 16 37.5 165.5

Percentage 4.38% 11.78% 18.13% 16.47% 4.83% 2.42% 9.66% 9.66% 22.66% 100%


A–Admin,B–ArchitectureDesign,C–Class,D–Coding,E–DesignEngineering,F–FieldTesting,G–GroupMeetings,H–PreparingSpecs,I‐Research,J‐Staff/LeadersMeeting,K‐UIDesign,L‐UserTesting,M‐WritingReports,N–DataMigration

Name A B C D E F G H I J K L M N Total

Hours

Andrew Brestic

ker

0 0 16 12.5 0 0 9 0 0 0 0 0 1 0 38.5

Hong Jai Cho

0 0 10.5 19.5 0 0 6 0 0 0 0 0 3 0 39

Jon Francis

4 2 11.7 44 7 0 0 0 3 0 4 11 13 3.66

103.36

Akshay Katti

0 0 14 5 9 10 2 1 0 4.5 0 2 5.5 0 53

Seoyeon Yang

0 2 9 27 0 0 10 0 0 0 3 6 1 0 58

Total 4 4 61.2 108 16 10 27 1 3 4.5 7 19 23.5

3.66

291.86

Percentage

1.4%

1.4%

20.9%

37% 5.5%

3.4%

9.2%

0.3%

1% 1.5%

2.4%

6.5%

8% 1.2%

5.1.3 Summary by Group of Individual Student Contribution

5.1.3.1 HCI

Carlos Gil

Presenter for phase 1, 2, 3

Demo script

Front end design for Smart Orthopedics

Min Hun Lee

Editor for phase 1, 2, 3

Demo script

Front end design for Vital Clip

Vishal Agrawal

Leader for phase 1, 2, 3

Demo script

Front end design for Gastroenterology

Demo master


Andrew Konecki

Worked on GPS/GSM module

Mike Ralph

Worked on GPS/GSM module

Kartik Kulkarni

Worked on sending RFID data to the database

Scott Robinson

Localization using RFID signal strength

Keith Williams

Networking RFID readers

Ram Shankar

Database


Frederick Curtis Layton:

Phase 1 presenter, phase 2 leader, phase 3 presenter Architect and main hardware developer.

Liaison with Hardware Architecture Group. Ameya Ambardekar:

Phase 1 leader, phase 2 editor, phase 3 leader Software developer and researcher. Liaison with Thinklabs.

Lei Fan

Phase 1 editor, phase 2 presenter, phase 3 editor Software developer and researcher. Liaison with the rest of the team of researchers at CMU and UPMC.

5.1.3.4 Vital Clip

Michael Bucher

Leader – Responsible for attending all Leaders’ meetings and acting as the interface between Vital Clip and other teams.

Team meetings – Suggested a week-by-week plan to split work based on envisioning of various technical difficulties the team might face.

Field Testing – Constructed the Pheonix Circuit and helped test it in lab along with Sai Nanduri

Coding – Wrote a Python Script that helped store the BPM data from Arduino onto a text file on a PC.

Sai Nanduri

Editor – Responsible for assigning writing work to team members, and editing the consolidated report of Vital Clip for Phase 2.

Research – Conducted literature survey on improving the output sensitivity of a piezo-electric transducer.

Hardware – Helped solder components onto the PCB ordered by Brian Pfiffner. Team meetings – Shared with Mark, scientist from VitalClip, the insights from field

testing of Vital Clip hardware. Noticed that the thickness of gel matters when using it with the sensor. Informed Mark the same.

Brian Pfiffner

Research – Conducted research on how to stabilize the input to a piezo-electric transducer.

Administrative Tasks – Prepared the order for PCB of Vital Clip and got it manufactured.

Hardware – Soldered the components of Vital Clip Signal Conditioning Circuit onto PCB. Also added an extra capacitor in the circuit to improve stability of input voltage to sensor based on research done.

Joe Berman

Presenter - Responsible for creating and editing the Phase 3 presentation. Communication Link – Interfaced with the Smart Orthopedics group to setup the

communication link for Vital Clip. This was the most difficult part of phase 3. Wrote the arduino code that uses a serial port to push out BPM data onto Telit board.


Andrew Bresticker Leader, Phase 2; Editor, Phase 3

Initial HTTP server implementation

Testing tools for Smart Orthopedics and Gastroenterology Gastroenterology API design and implementation Full-system integration

Hong Jai Cho

Presenter, Phase 1; Editor, Phase 2 TCP-to-HTTP proxy design and implementation

Apps script integration with HTTP server Integration and field testing with Smart Orthopedics and Vital Clip groups Database design and implementation

Jon Francis

Smart Ortho API design and implementation

Vital Clip API design and implementation AJAX testing tools for Smart Orthopedics, Vital Clip, and various admin functions

Integration with the web front-end

HCI team liaison

Full UI design

Database structure design and moderation

Focalzones API design and implementation

Akshay Katti Editor, Phase 1; Leader, Phase 3 Smart Orthopedics and Apps team liaison Integration of data processing functionality Error handling and robustness

Database testing

Seoyeon Yang Leader, Phase 1; Presenter, Phase 2 & 3 User Management API design and implementation server side Vital Clip integration with the web front-end

Gastroenterology integration with the web front-end

Database modification and structure design

HTML template implementation to follow Jinja2 format

5.2 Summary of Entire Project 5.2.1 Task Dependency Chart

5.2.3.1 HCI

Factor Dependency Phase

VisionaryScenario Entire groups Phase 1 Logo and name Entire groups Phase 1 Wireframings of prototypes Entire groups Phase 2 Login and Registration pages Software Infrastructure group Phase 3

Smart Orthopedics page Software Infrastructure group and Smart Orthopedics

Phase 3

Gastroenterology page Software Infrastructure group and Gastroenterology

Phase 3

Vital Clip page Software Infrastructure group and Vital Clip

Phase 3

Table5.1.1.2DependencyChartforHCI

5.2.3.2 Smart Orthopedics 5.2.3.3 Gastroenterology

Gumstixmicrocontroller

UploadingScript

FlagsScriptRecordingScript

RemoteStorage

5.2.3.4 Vital Clip

Factor Type Phase

DesignofDataAcquisitionSystem Internal Phase1

Procurementofsecondarysensors Internal Phase1

ProcurementofShieldedPiezoElectricSensor

Internal Phase2

ProcurementofPCB Internal Phase3

ProcurementofGelforsensor Internal Phase3

DesignandImplementationofCommunicationSystem

Internal Phase3

Table5.2.3.4DependencyChartforVitalClip


5.2.2 Ranked Issue List 5.2.3.1 HCI

No issue was reported.





5.2.3.4 Vital Clip




5.2.3 Summary of Work Log Hours For All Three Phase For Entire Class 5.2.3.1 HCI

A–Admin,B–UserInterfaceDesign,C–Class,D–GroupMeeting,E–Research,F–Leaders/StaffMeeting,G–WritingReports/Presentations,H–WebsiteDesign,I‐Coding


Carlos Gil

Min Hun Lee 0 23 37 33.5 17 1 53.5 35 0 200

Vishal Agrawal

Total Percentage % % % % % % % % %

5.2.3.2 Smart Orthopedics 5.2.3.3 Gastroenterology

A-Admin,B-User Interface Design, C-Class, D- Group Meeting, E-Research, F- Leaders/Staff Meeting, G –Writing Reports/Presentations, H – Field Testing,I – Design Engineering, J -Coding

Name A B C D E F G H I J Total

Hours

Curtis Layton

1.5 0 25 20.5 21.5 4 7 1 39.5 0 120

Ameya Ambardekar

0 0 28.97 14.33 11.17 6 13 0 11.75 27.25 112.47

Lei Fan 0 0 41.67 8.75 8 1 12 1 14 11.5 97.92

Total 1.5 0 95.64 43.58 40.67 11 32 2 65.25 38.75 330.39

Percentage (%)

0.5 0.0 28.9 13.2 12.3 3.3 9.7 0.6 19.7 11.7

5.2.3.4 Vital Clip

A – Admin, B – Architecture Design, C – Class, D – Group Meeting, E – Research, F – Leaders/Staff Meeting, G – Writing Reports/Presentations, H – Preparing Specs, I-Field Testing, J-Coding

Name A B C D E F G H I J Total Hours

Michael Bucher

3.75 9.5 28.5 22 9 4 20.6 4 10 10 63.10

Sai Nanduri 3.75 10 28.5 22 17 6 21 4 10 6 66.10

Brian Pfiffner

6.25 0 22.5 21 7 4 9 6 9 0 61

Total 13.75 19.5 79.5 65 33 14 50.6 14 29 16 334.35

Percentage 4.11% 5.83% 23.77% 19.44% 9.87% 4.19% 15.13% 4.19% 8.68% 4.79% 100%


A – Admin, B – Architecture Design, C – Class, D – Coding, E – Design Engineering, F – Field Testing, G – Group Meetings, H – Preparing Specs, I-Research, J - Staff/Leaders Meeting, K - UI Design, L - User Testing, M - Writing Reports, N – Data Migration

Name A B C D E F G H I J K L M N Total

Hours

Andrew Brestic

ker

0 2 38 19 0 1 27 0.5 3.5 3 0 0 3 0 97

Hong Jai Cho

0 2.5 37.5 26 0 0 27 0 9.5 0 0 0 15.5

0 118

Jon Francis

21.5

22.83

45.416

44 7 0 5.83 0 20.416

5 5.5 11 16.5

3.66

208.652

Akshay Katti

0 1.5 46 7.5 14 10 18.25

1 9 4.5 0 2 12.6

0 126.35

Seoyeon Yang

0 6.5 25 29 2 0 32 0 9.5 1 3 6 4 0 118

Total 21.5

35.33

191.916

125.5

23 11 110.08

1.5 51.916

13.5

8.5 19 51.6

3.66

668.02

Percentage

3.2%

5.3%

28.7%

18.8%

3.4%

1.6%

16.4%

0.2%

7.7%

2% 1.3%

2.8%

7.7%

0.5%

5.2.4 Reflections on Work Log Hours and Distribution 5.2.4.1 HCI

The HCI group spent most of time for attending classes, having meeting with other groups for notifying our decisions or designs, such as visionary scenarios, demo script, front end design. At

the phase 3, most of time was spent on implementing and coding the front end web based application.



The gastroenterology group spent the majority of its time in classes, which, when not in lectures, was usually spent in the lab designing or coding, or in group meetings. Early on we had more group meetings to decide on an overall architecture, but as we split into a software group (Ameya and Lei) and a hardware group (Curtis), we worked mainly on our own parts; hence, in the later

stages, the two subgroups spent a lot of time on coding and design engineering, respectively. 5.2.4.4 Vital Clip

As evident from the percentage distribution of the work logs, about a fourth of the teams time was spent in class and we used this time to hold fruitful group meetings. We did not have any dependency on any kind of external factor for the first two phases and as a result, our meetings involved no kind of conflicts, either in terms of the technology used, approach taken to solve a problem or in terms of the timings to setup inter-group meetings etc. This resulted in fairly smooth working in the first two phases. In the third phase, we only had to interface with one external team, i.e., Smart Orthopedics team which was taken care of by the hardware liaison for Vital Clip, Joe Berman.

The remaining time we spent was evenly distributed amongst research, preparing specs, architecture design, field testing and coding. Our research and consequent preparing of specifications for the project was mostly carried out in the first phase. The second and third phase involved field testing and coding. The third phase also involved a bit of architecture design. This time was spent on two aspects.

i. Deciding a way to improve the stability of the input to the sensor. We ended up adding an extra capacitor in the circuit to serve the purpose.

ii. Deciding a form factor for the sensor to be held in place while measuring a subjects pulse rate. We used Velcro in conjunction with a gel to have a fixed way of using the sensor.


5.3 Suggestions for Improving Class

We thought that it would perhaps be better to have a more unified project; for much of the semester the individual groups worked on their own systems, and that made the unification of all the services much more difficult in the last phase and was perhaps the cause of much of the trouble the groups had with the software architecture and server setup.

We also thought it would perhaps be better to quiz people about their skills and interests at the beginning of the semester to form more balanced groups; the gastro group was very fortunate to have found skills in analog, digital and software and it worked out well for us, but it could have worked out very differently otherwise.

Documents

Rapid Prototyping of Computer Systems Spring 2012 Carnegie ... · required design objectives (real time, minimal power consumption, and so forth.) 1.2 Background 1.2.1 Human Computer