[ECG ADAPTIVE FILTERING]

Transcription

1 UCF Senior Design Brandon Autrey Edward Jezisek Edward Nowlin Renato Ortega Group 2 Sponsored By: [ECG ADAPTIVE FILTERING]

2 1 Table of Contents 1 Table of Contents... i 2 Table of Figures...iv 3 Executive Summary Project Description Project Motivation and Goals Objectives Hardware Software Project Requirements and Specifications Software Requirements and Specifications Hardware Evaluation Plan Research Overview of Adaptive Filters System Identification Inverse System Identification Noise Cancellation Prediction Analog Filters Research Related to Project Definition Existing Similar Products GE Medical INVIVO BIONET WELCH ALLYN Medical Hardware Medical Hardware Restrictions MRI Machine ECG Electrodes and Lead Cable ECG Machine/monitor Digital Filters Butterworth Filter i

3 6.3.2 Savitsky-Golay Filter Non-linear Diffusion Filtering Least Mean Squares Filter ECG Noise Contributions Project Hardware and Software Design Details ECG Filtering Software MATLAB Simulink Model-Based Design Processor-in-the-Loop Toolboxes Potential Coding Problems MEX Licensing MATLAB and Simulink Initial Design Architectures and Related Diagrams ECG Filtering Hardware Printed Circuit Board Analog Front End Analog to Digital Converter Microcontroller Digital to Analog Converter ECG Filtering Software Design Summary of Hardware and Software Software High Level Software Design CMSIS Microprocessor Implementation Publish/Subscribe Serial Synchronous Interface MATLAB Implementation Graphical User Interface Detailed Software Design Hardware Project Prototype Construction and Coding ii

4 9.1 Parts Acquisition Raspberry PI Hercules Launch Pad Tiva Launch Pad AFE AFE AFE PCB Vendor and Assembly Making of the Board Final Coding Plan Version Control Build and Prototype Plan Software Project Prototype Testing Hardware Test Environment Interference Lighting Temperature and Ventilation Power Requirements Hardware and MRI Specific Testing ECG Adaptive Filter Power Source Software Test Environment Software Specific Testing PCB Testing Results Personnel and Bibliography of Related Work Edward Jezisek Brandon Autrey Edward Nowlin Renato Ortega Sponsor/Consultant Administrative Content Milestone Discussion iii

5 15.2 Budget and Finance Discussion Bibliography... I 17 Permissions... V 2 Table of Figures Figure 1: Overall System Diagram... 4 Figure 2: Project Block Diagram... 5 Figure 3: Cortex M4 Processor... 7 Figure 4: Invivo Precess... 9 Figure 5: Adaptive Filtering to Identify Unknown Systems (Permission from MathWorks) Figure 6: Using Adaptive Filter for Determining Inverse Response to an Unknown System (Permission from MathWorks) Figure 7: Using Adaptive Filters to remove noise from an unknown system (Permission from MathWorks) Figure 8: Using Adaptive Filters to Predict Noise from an Unknown System (Permission from MathWorks) Figure 9: Image of the MAC Figure 10: ECG Display, MAC Figure 11: MAC Figure 12: MAC Figure 13: Precess Display Figure 14: ECG Figure 15: CARDIO Figure 16: Welch Allyn CardioPerfect Pro Figure 17: Welch Allyn CP Figure 18: An image of the Quadtrode Electrode Figure 19: Philips Invivo Quadtrode Lead Cable Figure 20: Invivo Patient Monitoring System Figure 21: Wireless Transmitter for Patient Monitoring System Figure 22: Philips System with Integrated Adaptive Filter Figure 23: LMS MATLAB Example Figure 24: Definition of Plant Model (Permission from MathWorks) Figure 25: Processor in the Loop Diagram Figure 26: Price Quote of MATLAB software Figure 27: Filter Class Diagram Figure 28: Diagram for hardware functionality Figure 29: PCB Schematic of adaptive ECG Filter Figure 30: Bode Diagram of First Order Butterworth Filter Figure 31: Frequency Response of Sallen Key Filter Figure 32: Flash Analog to Digital Signal Figure 33: Delta Sigma Architecture iv

6 Figure 34: SAR Architecture Figure 35: Texas Instruments ADS Figure 36: Cortex A Figure 37: Cortex R Figure 38: Cortex M Figure 39: AD56XX Series Write Sequence Figure 40: AD5640 Register Contents Figure 41: Publish/Subscribe Class Diagram Figure 42: Publish/Subscribe Use Case Diagram Figure 43: Class Diagram for Publish/Subscribe Figure 44: Texas Instruments SSI Timing Diagram Figure 45: Invivo Expression MRI Monitor (Permission from Philips) Figure 46: GUI Prototype Figure 47: Class Diagram of Software Design Figure 48: Pert Chart Displaying Design Plan Figure 49: Raspberry Pi Board Figure 50: Raspberry PI LED Diagram Figure 51: Media connections of Raspberry Pi Figure 52: Hercules Functional Block Diagram Figure 53: Level Input Figure 54: Level Output Figure 55: Clock Domains Figure 56: Cortex M4 System Bus Interface Figure 57: Tiva Launch Pad LED Diagram Figure 58: AFE Figure 59: AFE Figure 60: PCB creation Process Figure 61: PERT chart for Coding Plan Figure 62: Pert Chart for Project Completion Figure 63: Printed Circuit Board Figure 64: JTAG Programmer Figure 65: Synchronous Serial Interface Oscilloscope Readout Figure 66: DAC output from sine wave Figure 67: ECG Generator Figure 68: Connecting generator to PCB to wireless module Figure 69: ECG output without filtering Figure 70: ECG output with filtering Figure 71: Task List for Project and Group Identification Document Figure 72: Final Document Deadlines Figure 73: Senior Design II Project Deadlines v

7 3 Executive Summary After receiving the project description from Philips, our group decided to create an Adaptive ECG filtering system. The Adaptive ECG (Electrocardiography) filter receives signals from an MRI machine. These signals are sent to an Analog front end to provide safety to the patient. Then, the Analog to digital converter comes into play. The Analog to Digital converter converts the Analog signals to digital. These digital signals are filtered digitally using software created with the CMSIS library. The Adaptive ECG filter uses the Least Mean Square algorithm to filter the results. The results from this filter are initially poor due to how the filter works. Over time, the filter fine tunes it s coefficients and delivers more accurate results that symbolize an ECG signal. This filtration is done to remove a lot of the noise present. Some of the most common examples of noise that the ECG filter will remove in order to provide useful results include Power Line Interference, Electrode contact noise, Motion Artifacts, Muscle Contraction, and Baseline Drift. This noise needs to be filtered to measure the appropriate results on the (Magnetic Resonance Imaging) MRI machine. This filter is used as a microcontroller on an ARM Cortex M4 and is essentially a device used for converting the signal. MATLAB is able to create this software using Simulink but, unfortunately due to the cost of Simulink, the decision was made to use the CMSIS libraries for the ARM Cortex processor. The future goals for this project include helping MRI operators make fewer mistakes by making some of the choices for them. Unfortunately with the large number of MRI machines it is almost impossible to teach everyone how to use each of them. This requires a system to be created that works for each user regardless of their experience level. The complexity of operating an MRI machine is greater than it should be. This project simplifies this operation by automatically filtering the data using an adaptive filter. Since the filter is adaptive it can also in theory provide better results than a linear filter. Future iterations of this project will be made to give better results. The end goal for future iterations of this project is to provide an easier to use system with a better accuracy rate in regards to the use of the MRI machines. 1

8 4 Project Description The Adaptive ECG (Electrocardiogram) Filter is designed to reduce noise caused by MRI (Magnetic Resonance Imaging) machines to produce a diagnostic quality ECG signal. The ECG is a non-invasive system that provides critical data of a patient s heart activity. While a patient is undergoing a MRI scan, the MRI machine radiates electromagnetic energy that interferes with the electronic ECG signal received from the patient. This electromagnetic radiated energy causes some of the ECG data received during a MRI to be corrupted and therefore useless. Currently, Philips uses a system that requires medical professionals to manually choose filters based on what they believe the particular interference will be. This system is unreliable because technicians are not necessarily trained to operate the filter their specific model of MRI machine. The filtering system on a Philips MRI machine will be different to the filtration on a General Electric or a Siemens MRI machine. Our adaptive filter removes the need to manually select a filter and allows the medical professional to better concentrate on the patient and less on the equipment. An MRI machine works by aligning the hydrogen atoms in a person s body with a homogenous magnetic field. Like all atoms, hydrogen atoms naturally resonate at a precise frequency. The MRI machine has a RF transmitter coil that transmits an electromagnetic signal at a precise frequency to disturb the selected hydrogen atoms. The machine then records the decay of hydrogen atoms returning to the homogeneous magnetic field to produce an image of the inside of a body. The electromagnetic frequency transmitted into the hydrogen atoms is intermittent and changes depending on type of MRI machine and type of MRI being performed. The signal transmitted by the RF coil also interferes with the electric signals monitored by an ECG. The adaptive ECG filter recognizes the frequency of the electromagnetic interference and eliminates it from the ECG signal. The filter system is a unit that attaches to the ECG monitor and is connected inline between the ECG sensors and the ECG monitor. The filter also has an optional connection to a tablet computer via a USB port. The box has three input ports from the ECG sensors, three filtered output connections (1 for each electrode), and a Digital to Analog Converter for displaying the data on a Patient Monitor. This project showcases the results on Philips patient monitor; the Invivo Precess. The internal part of the unit consists of an analog front end with an amplifier and filter, an analog to digital converter, microprocessor, and a digital to analog converter. All of these components are soldered to a printed circuit board manufactured exclusively for the adaptive filter. This design allows the unit to be attached without any modification to existing ECG monitoring equipment. Since there is no modification to the monitoring equipment, the device will be universal to all monitoring equipment manufacturers. 2

9 The analog front end provides patient protection, amplifies ECG electrode signals, and filters the ECG electrode signals. The front end consists of a configuration of operational amplifiers that work as a low pass filter and have a gain of 5. ECG signals are transmitted with a voltage of +/- 5mV and a frequency of Hz. The gain of 5 is used to amplify the electrode voltage to a level that is optimal for the analog to digital converter. The low pass filter has a cut off frequency of 150 Hz to reduce interference that does not overlap the cecg signal. Overlapping interference will be eliminated in the microprocessor. The front end is also designed with diodes integrated into the circuit. The integrated diodes are designed in such a way that if any current were to be applied to a patient from the equipment the diode will short the circuit to protect the patient The analog front end is then connected to the analog to digital converter. The analog to digital converter takes the signals received from the electrodes and makes the signals usable for the microprocessor. This is done to allow the Microprocessor to filter the data. The signals received from the electrodes are analog and therefore they are not recognized by the processor that only has digital inputs. The converter takes the analog values and converts them to binary so that the microprocessor can understand them. The analog to digital converter used in the adaptive ECG filter is built into the ARM Cortex M4. After the signal from the electrodes is converted into a digital format it goes to the microprocessor. The microprocessor used in the adaptive ECG filter is an ARM Cortex M4. The ARM Cortex M4 uses a 32 bit RISC operating system that operates 168 MHz with one megabyte of flash ram. The speed and memory of the processor make it ideal for performing the filtering algorithms that eliminate the gradient interference. Displayed below in Figure 1 is the overall diagram of the system from patient to monitor, which is meant to distinguish how our project (Adaptive ECG Filtering) fits in with the overall system. 3

10 Figure 1: Overall System Diagram The system starts at the patient on the far right, who is receiving an MRI scan within an MRI machine. The patient has 4 electrodes connected to his body in order to read the patients ECG signal. The patient and the electrodes are directly within the field of the magnetic field which is the cause for the noise contributions. The cord is the bundled up wires from the electrodes that inputs into the adaptive filtering module. The cord must not be coiled up because a loop in a wire with a changing magnetic field can induce a current, which can cause the wire to heat up drastically and possibly hurt the patient. The cord then connects to an analog to digital converter. This A-to-D converter and adaptive filtering module is our Adaptive ECG Filtering project. The output of our project feeds into an ECG module which is responsible for transmitting the ECG signal wirelessly to an external monitor. The monitor can either be inside the room or outside the room. The room is within the magnetic field caused by the MRI machine because the room is surrounded by a Faraday cage, this cage is an enclosure made of a conducting material in a mesh format. The enclosure blocks varying magnetic fields caused by the MRI machine. Therefore, a Faraday cage is used to block the magnetic fields generated by the MRI from exiting the room, which would disrupt other vital equipment. The doctors can then monitor the patient by looking at their ECG and other personal signals. Figure 2 displays details our parts of the project 4

11 5 Figure 2: Project Block Diagram

12 The signal filtering performed by the ARM Cortex M4 microprocessor is written in the embedded C++ programming language. The algorithms used in the Processor were retrieved from the CMSIS library. These algorithms filter out the data from the signal. The filtration method chosen was the Least Mean Squares Filter but it is easy to add different filtration methods to the current design. One of the clients for this project requested that feature in case it is necessary to use some other type of filtration than the Least Mean Squares Filter. The continuous sampling method records as many data points as possible. These data points are then processed with an algorithm such as the least mean squares algorithm that discounts erroneous data points leaving only the accurate data to produce the output graph. After the processor performs these algorithms the digital output is then transmitted to a Digital to Analog Converter. Initially it was planned to send the data by USB to MATLAB for plotting, but due to problems with the device the USB was not working and it was decided to display everything on the Invivo Precess. The Invivo Precess takes the data in from a Digital to Analog converter and displays it to its monitor. The digital to analog converter takes the digital output from the microprocessor and converts it to a corresponding analog value for the output. The conversion to analog is important because it allows the filter to operate without requiring a redesign of the MRI monitoring equipment. The digital to analog converter used is an AD5640. The AD5640 is a 16 bit converter that produces an output of up to +/- 2.7V. Three Digital to Analog Converters are used to display the signal from each inputted signal. The ARM Cortex M4 provides a lot of different functionality. It filters the data from the Analog To Digital Converter and outputs said data to the Digital to Analog Converter. One of the hardest problems was configuring the pins to work correctly with the device. Another issue that was fixed was the speed at which the device was inputting and outputting data. To do this multiple things were required by the processor. Figure 3 displays the Cortex M4 Processor 6

13 Figure 3: Cortex M4 Processor 4.1 Project Motivation and Goals The original idea of the Adaptive ECG filter was first proposed to us by Philips. The idea would be useful in the real world and has potential application that Philips is in the process of researching. This project required some background in Computer Engineering and Electrical Engineering and will hopefully make a difference in the future. As such, this project was undertaken to improve current medical devices and to obtain real world experience on a potential Philips product. When working on a healthcare related project, it is important to understand that the final product will primarily be used by medical professionals and the standards of quality need to be higher than many other fields. If something goes wrong in a medical device, it can easily be the difference between life and death. Filters are currently used to clean up frequencies and Linear Filters do a great job at this. However, better quality is always important and thus our project was born! The cleaner the frequencies that come from the ECG the easier the person or program reading the data will have in determining the patient s condition. We hope our project goes on to improve Philips current devices and improves the quality of their devices. The filters Philips currently uses do not deliver the quality that is desired. Better quality is always important. Our project hopes to deliver a cost effective solution that delivers high quality results and improves the ease of use for the medical professional. 7

14 4.2 Objectives Hardware The main objective of our project is to design and build a prototype system that lessens the contributing factors of MRI-induced noise on an ECG signal. Our input will be real-time analog noisy ECG signals that come directly from sensors on a patient undergoing an MRI scan. Our output will be real-time analog noise-reduced ECG signals, clear enough so the medical professionals can utilize the results. The basic components of this project will consist of a patient protection system, amplifier, and analog to digital converter, digital signal processing, and digital to analog filter. These components must be in our project in order to accomplish our main objective. What distinguishes our project from competitors is that it will take advantage of adaptive filters for the digital signal processing. Adaptive filters filter based on the signal inputted and the gradient signal. Therefore the type of signal is identified by the device and the medical professional does not need to specify which scan is being done. This also can allow different types of scans that may become necessary as medical advancements are made. Our goals for filtering is to identity the type of noise being received, apply the Least Mean Squares adaptive filter. The longer the filtering runs, the better the system should become at filtering out the noise received on the ECG signal. The display of this project was also of utmost importance. To provide the best display for what we created, it was necessary to utilize Philips Invivo Precess. Philips graciously allowed us to use this in the presentation of our project. It showed our project on an actual Patient Monitoring system. Figure 4 displays the Invivo Precess Machine. 8

15 Figure 4: Invivo Precess The Invivo Precess machine is able to display the results of our project; however it has many other features that make it useful. It is able to filter out data on it s own using Linear Filters that are built in. It also measures the heart rate of the patient based on the ECG signal. In testing our project was able to filter some of the data to make it more readable than no filter and the heart rate was preserved. However, the linear filters provided better results than our project currently does; so more work is needed to filter the data Software The objectives of our project were to: Design and build a prototype system that lessens contributing factors of MRI-induced noise on an ECG signal. Estimate noise on ECG signal. Apply adaptive filter methods that correspond to the noise. Determine the feasibility of using adaptive filtering methods. Stay within our budget of $9,500. The basic components of the prototype consist of a patient protection system, differential amplifier, analog-to-digital converter, digital signal processing system, and digital-to-analog converter. These components must be in our project (Adaptive ECG Filtering) in order to accomplish our objectives. Our input will be real-time analog noisy ECG signals that come directly from sensors on a patient 9

16 undergoing an MRI scan. Our output is real-time analog noise-reduced ECG signals. What distinguishes our project from the current filtration methods is that it will take advantage of adaptive filters for the digital signal processing. Adaptive filters correct themselves when filtering a signal and therefore need less initial information on the type of scan being performed and the type of noise it will encounter. Our goals for filtering were to apply the Least Mean Squares filter and obtain a fairly accurate response. The longer the filtering runs, the better the system is at filtering out the noise received on the ECG signal. 4.3 Project Requirements and Specifications Software Requirements and Specifications The software we produced is an Adaptive ECG Filter. The adaptive ECG Filter receives a digital signal that has been affected by noise. This noise is removed using an Adaptive Filter. The software is a generic program to allow multiple types of filters to be tested with the ECG model. This is done by utilizing an Interface called IFilter and abstracting the code away from the main implementation. This utilizes the Strategy Design pattern for the filtration of the data. The program runs quickly enough to filter incoming digital data. As this will be used on a living patient, we must display the filtered data that we receive in real time. This system we chose runs on an embedded device with 15 pins that connect to Philips devices. The embedded device is a 32-bit system that stores and adapts coefficients from the filter. The system has at least 16 KB of RAM. The program will allow the user to choose the type of filter they want to use for the filtration. Currently, the only filter being used is the Least Mean Squares filter, however due to the utilization of the Strategy Design pattern it is easy to change the type of filter being used by the system. The system can further be configured to have a configuration file that chooses the algorithm that will be used. This file if implemented will choose between several different adaptive filters. The filter the user has selected is applied to any and all incoming data. The program will then save the inputted data and will also save the outputted data for future use. The stakeholders for this project include Philips, Dr. Richie, the Medical Professionals who will use this project and our senior design group. Philips is funding this project to help create an adaptive filter. Dr. Richie is allowing this project to be done for a grade in the UCF Senior Design curricula. Our Senior Design group is receiving a grade for the overall function of this project. The Medical Professionals will use this product to receive better results from the ECG signals and to simplify their lives. Our program responds to a multitude of different events. Whenever it receives digital data, it sends it through the filter specified within the configuration file. The 10

17 main stimuli with regards to this event include the ECG itself, however; it also utilizes an external configuration file that can be configured by the user. We also incorporated the main functionality within a library, so that if the user wishes to create their own filter that implements IFilter they can. This will allow the program to be updated by third parties for research purposes or to improve upon the existing digital filter. This also abstracts a lot of the program away and makes it easier to modify for future changes. The program can be developed further to take in an input as to whether it is comparing the results with the actual data. Some of the inputted data could have the exact data to compare the results with. This will help to find out how well the filter removes artificial noise and the program will obtain a score stating how similar it is to the actual results. This above feature could be available to users in a future iteration and would possibly be accompanied with a guide explaining how to input the data to allow the program to compare the different values that were inputted. The program could include its own artificial noise creator, but the noisy data can be inputted directly to allow more flexibility within the program. The program could have a few types of noise. Initially it will just give random values added to the numbers between (- n and n); in future iterations it could attempt to create artificial noise that more closely relates to that of an ECG Functional Requirements The first functional requirement is that the software program must filter out noise from the digital signal. The signal must be filtered using a variety of different filters that will be created and input into the program. This was necessary to allow the users to obtain relevant data with regards to the information sent to the application Physical Environment Requirements The first environment requirement is that the program must be run on an embedded device that allows Embedded C++. This is to allow an object oriented/modular approach to the design of this application. This requirement was evaluated through ensuring that any embedded device we buy allows C++ within the embedded device s specifications. The second environment requirement is that the embedded device must contain at least 128KB of RAM. This allowed us to use an ARM Cortex M4. This choice helped to filter the results due to other libraries and functionality Documentation Requirements The documentation requirements ensure that our project will be documented properly. The documentation was done in the coding itself and the naming conventions used. The strategy design pattern was used to help the code to be self-documenting and to showcase everything that needed to be changed. 11

18 Quality Assurance Requirements Our code was tested to ensure that the results match expected values for a large number of different inputs. This was initially tested with MATLAB and later tested with artificial ECG noise from one of Philips devices. One thing we will do is to run a large amount of different inputs and our program will look for any outliers that may exist. Of course, we will also try to input obscure data to ensure our program continues even if something unexpected happens. Therefore, the Quality Assurance ensured that our program passes all tests that we have created. It was also tested with a large amount of data to ensure that odd values don t affect the outcome. Doing this test helped identify some errors. At one point in time, we were sending data to MATLAB and the data started looking really strange and approaching the maximum values for the float. This was not expected. The reason for it was that the UARTprint command converted a newline (ASCII code 13) as a line break as well. This caused the program to send more than one byte sometimes. We also checked to see what happens when values that are not correct are inputted. For example, if a number makes a large leap from 0 to Max or something similar, our program must be prepared for that. This showed some weird results with the adaptive filter when certain results were changed. When the signal changed and the gradient was zero, the coefficients would mess up and garbage value would be outputted. Another case that our program considered is integer overflow. An integer overflow is when the values increase so much that the value loops and goes back to zero. This is obviously not good for our program and we ensured such extreme circumstances will not happen in our project. Another measure of Quality Assurance that we provided is based on our developmental approach. As errors are cheaper to fix early on in the developmental cycle a zero-defect policy was enforced. This was largely because a small error will often turn into a much larger error later on in the program. This is of particular concern if any threads are used within any part of the program because it is difficult to ensure that no data is ever being used when it shouldn t be. We also ensured that no memory leaks happen to the program upon exit. Memory leaks can signify a number of errors and if they become severe enough they can eventually cause a crash within the program. There are multiple programs that we could have used but, for this project we were initially going to be using Visual Leak Detector. Visual Leak Detector would show the complete call-stack for the program to help identify and fix any memory leaks that are inside of the application. It is also open-source and while useful will hopefully not need to be used. However, since our project did not use any dynamic memory; memory issues were not a concern. 12

19 4.3.2 Hardware The Adaptive ECG Filter has certain hardware requirements that were achieved. These requirements were classified as basic, necessary, and optional. The basic requirements are requirements that must be met so that the equipment does not cause damage and negatively affect the operation of existing equipment. Necessary requirement are requirements that that must be met for the Adaptive ECG Filter to serve a purpose. The last category of requirements is optional, optional requirements are additional features the filter can have to make it more marketable. The two basic requirements that the Adaptive ECG Filter must meet are that it provides patient protection and that it is battery operated. Patient protection is necessary for all electronic devices that operate in a medical environment. Patient protection consists of a circuit design that prevents current from flowing into a patient and causing an electrical shock. Patient protection can be achieved through a circuit design with operational amplifiers, diodes, and fuses. The filter is designed to operate with equipment that has wireless capability which makes it important to keep the Adaptive ECG battery powered. The filter was designed to be connected in line with existing equipment and having a power cable will negate the progress made in keeping the ECG system wireless. The necessary hardware requirements we have established are that the filter performs the desired operation on the ECG signal and that the filter is compatible with existing equipment. The requirement that the filter works is achieved through software but it is vital that all of the internal components work together. If the battery doesn t sufficiently power the components or the components do not properly work the filter will fail as a whole. The requirement that the filter work with existing equipment is important to make the filter useful. A redesign of an existing ECG system to accommodate the filter will make it unappealing and undesirable in the industry. The compatibility is achieved by converting the signals back to analog so that the filter is virtually invisible to any ECG machine that it may be connected to. The optional requirements for this system are that it has USB connectivity and a tablet computer for ECG processing. Neither of these optional requirements was completed. The Adaptive ECG Filter could have had an USB adapter that transmits the digital data to a tablet computer. There is existing software could have been used that will process an ECG signal on a computer. Some of this software was used in the testing of our device. However, we would have preferred to create our own software that is capable of receiving, monitoring, and recording an ECG signal on a tablet computer. The software could have been user friendly and have allowed the ECG image to be transmitted via Wi-Fi or Bluetooth with the push of a button. Many televisions support Wi-Fi and Bluetooth which would have allowed the computer to display an image to an audience in a presentation environment. The software if completed in 13

20 this form would have be able to analyze a given ECG signal to recognize characteristics that are indicative of a medical condition such as an irregular heartbeat or a recent heart attack. We would also have liked the computer to recognize incorrectly attached electrodes based on the ECG output. All of the listed functions would require the tablet PC to have a wireless network card, Bluetooth adapter, and a large amount of processing power. Almost all tablet computers on the market have enough processing power, USB port and a network card. However due to the reach of our project; a tablet computer was not seen as desirable and this idea was removed Evaluation Plan We ensured that our project meets all requirements inside this document. These requirements are largely detailed within the testing plan. As such, we ensured our project ran and delivered filtered results from the Artificial ECG Signal. We checked our filter with the previous filters Philips uses and unfortunately obtained worse results. One of the main ways we evaluated this project is by looking at the results from the filter. To do this, we ensured that the results from the filter look correct. Another factor that we will need to consider is the amount of data outputted by our adaptive filter. The results must not remove needed data from the signal. Some of the most important information for the doctors will be on varying wavelengths, and if our filter filters these wavelengths out, there can be major inaccuracies within our project. Another test that was used to evaluate our project was counting how quickly it sent data. This allowed us to ensure that our device received and processed data at the required speeds for the inputted data. The following questions were used as a guide to ensure our project meets specifications. Does the project meet or exceed the requirements? Does the project filter out noise from the ECG signal? Is the project safe to use? Is the project easy to use? Can the project be used by Philips? What did we learn by doing this project? Did each team member adequately fulfill their role in the project and did we work together efficiently as a team? The reasoning behind each of these questions will be summarized in the following paragraphs. We feel the questions are very important to ask and to follow, since this will ensure that we adequately perform with regards to each of these individual areas. 14

21 The first question we will discuss is whether or not the project meets the requirements. This question is important because, quite simply if our project did not meet the requirements then it s not adequate for the given task. Our group will continuously check the requirements listed and will ensure that either Philips is notified or Dr. Richie is notified if one of the requirements cannot be completed. We will obviously be putting our due effort in to ensure this project works and will keep documentation regarding each step along the way. The second question to be discussed is whether or not the project adequately filters out noise from the ECG signal. As such, we checked to make sure our filter delivers results better than not using a filter. This was confirmed by visualizing the data and checking to ensure that our data was in fact filtered. The third question relates to the project being safe to use. Obviously, as Philips is attempting to sell this project, it needs to meet health standards and may not cause harm to the user of said item. Therefore, we made sure the project does not in some way interfere with the MRI machine and cause some unfortunate effect. This is required largely due to the strong magnetic forces that are within the MRI machine. As such we will be testing our products so that no harm comes about because of them. This was ensured using the Analog Front End to prevent any harm that would come to the patient. Another question references the usability of the project, especially how easy the project is to use. Unfortunately, there are some great works of engineering that are rather difficult to use. Therefore, our project aims to improve the usability and to improve results (this is a future goal as our results were not better than linear filters at this point in time) as well. Our main goal was to deliver better results, but our secondary goal is to improve the usability of the product. As such, we ensured that our created device required minimal input to be used. We also paid close attention to the difficulty of use of our product. The following question is in regards to the design of the project. Essentially, does it look nice? A lot of projects are created that have a shoddy look and are not entirely professional; this is often a detriment to the project s success. We did the best we could to ensure our project was a success by ensuring that it worked with the Invivo Precess Machine. The next question is whether this project can be used by Philips. This question helped focus our efforts toward meeting the goals Philips has for this project and helping them out overall. As Philips is funding us, this project is largely built to fit their needs. Therefore, we need to ensure that the project serves some purpose with regards to what they want. We also ensured a lot of modularity to allow them to test out other filters they created. After we have finished answering the previous questions, we will also have the satisfaction of gaining the knowledge from the abundance of material covered 15

22 while completing the project. As this project was used to showcase our abilities as students, learning new things is vitally important. Each of us will have different tasks, yet we worked together as a team. We attempted to learn as much as possible about the inner workings of the project itself and our respective parts. We planned to have some measure with regards to how much we learned however this never came about. These documents would have helped as a refresher for future interviews and as a way to recall exactly what we contributed to the overall project. The final question is whether or not each team member adequately completed their role in the project and did we successfully work together as a team. Our group values learning. And while it is important to assign and follow through with tasks and jobs, we also needed to learn to work together as a team. Most of us have worked individually throughout college so forming a group of two computer engineering students and two electrical engineering students was a much different environment than what we typically experience. Learning each other s strengths and weaknesses is important to efficiently function together as a team. By doing so, we believe we provided a professionally done project that showcases our talents. 5 Research 5.1 Overview of Adaptive Filters Adaptive filtering is a filter that self-adjusts its transfer function according to an optimization algorithm. The self-adjustment is done by calculating the error signal which feeds back into the transfer function. In contrast, a non-adaptive filter has a static transfer function. This means that it will do the specific filtering without adjusting. The advantage to using adaptive filters is that they self-learn. Adaptive filters contain parameters (coefficients) that over time, adapts to the changing signal characteristics. The longer the filter continues, the more the coefficients adjust themselves to achieve the desired results. The application in which adaptive filters are useful are when some parameters of the desired operation or of the system are not known in advance or the parameters of the system might change in real time. Therefore using adaptive filtering can learn to match the changing parameters. The four main types of adaptive filters include System Identification, Inverse System Identification, Noise Cancellation, and Prediction. 16

23 Each type has its own purpose and characterizations. Specifications to consider when choosing a filter are consistency, performance, and DSP requirements. In the diagrams of the following sections, the greyed area contains the adaptive filter system System Identification This approach uses adaptive filters to identify an unknown system. The unknown system is placed in parallel with the adaptive filter. The input signal is the same for the unknown system and the adaptive filter. When the difference of the outputs of the unknown system and the adaptive filter approach 0, the adaptive filter will almost mirror the unknown system because the input and output for both systems will be the same. This is useful because it gives you a mathematical description of a dynamic behavior of a system or process. MathWorks has an excellent example of Adaptive Filtering to Identify Unknown Systems, as displayed in figure 5. Figure 5: Adaptive Filtering to Identify Unknown Systems (Permission from MathWorks) Inverse System Identification The Inverse System Identification approach uses an adaptive filter that becomes the inverse of the unknown system. This happens when the unknown system is placed in series with the adaptive filter. As the error, e(k) becomes very small, the filter adapts to basically cancel the signal outputted by the unknown system. A delay is added to the system so that the summation is kept synchronized. This technique has applications in deconvolution, adaptive and blind equalization. Figure 6 below shows inverse response with adaptive filters. 17

24 Figure 6: Using Adaptive Filter for Determining Inverse Response to an Unknown System (Permission from MathWorks) Noise Cancellation This Noise Cancellation method uses adaptive filters to remove noise from a signal in real time. The d(k) is the input signal that contains s(k), the clean desired signal, and n(k), the noise contributions. The output of the system, e(k), will converge onto the input data signal s(k). To remove the noise, feed a signal n (k) into the adaptive filter that is correlated to the noise in the signal. When n(k) n (k), then d(k) n (k) = e(k) s(k). As long as the input noise remains correlated to the unwanted noise, the adaptive filter adjust its coefficients to reduce the value difference between d(k) and y(k). MathWorks shows how adaptive filters can remove noise from unknown systems as displayed in figure 7 below. Figure 7: Using Adaptive Filters to remove noise from an unknown system (Permission from MathWorks) Prediction The Prediction approach uses the adaptive filter to predict the future values of the desired signal based on past values. The requirements for this filter design are that the signal must be steady or slowly varying in time, and periodic over time. By 18

25 having these conditions, it makes it possible to guess future values. If the signal varied widely over time, then obviously predicting is not going to work well. When s(k) is periodic and the filter is long enough to remember previous values, prediction can be performed. Applications using this technique are spectrum analysis, signal detection, and linear predictive coding. Figure 8 below illustrates how adaptive filters can predict noise. Figure 8: Using Adaptive Filters to Predict Noise from an Unknown System (Permission from MathWorks) These four techniques make up the characteristics of the different type of adaptive filtering. An adaptive filtering system can be composed of multiple adaptive filtering types which can be mixed and matched or all the same. So it is important for our project to know how adaptive filtering can be configured to achieve different kinds of results. The noise cancelling filter type will be the basis for adaptively filtering out MRI interference noise. The predictive filter type probably won t be very useful because our system is very dynamic and the signal can change widely. This doesn t meet the requirements for the predictive type. The system identification and inverse system identification could possibly be incorporated into our final system filter design. 5.2 Analog Filters An analog filter is any filter, which operates on a continuous-time signal implemented in analogue circuitry. An Analogue signal describes the proportional relationship between a signal and a voltage that represents the signal. The signal can take any value from a given range, and each value represents different information. Analogue filters perform the best at high speeds when low power consumption, small integrated circuit area, and moderate linearity are required. The two main approaches to the adaptation of analogue filters are the least-meansquare (LMS) and heuristic algorithms. For these algorithms, they are similar in that they are relatively simple, both conceptually and in their hardware implementation, each is tailored to a specific application and filter structure, and they are limited to situations involving adapting one or two parameters. Designing adaptive analogue filters can be challenging. One instance is that it must be possible to change the filters coefficients via some control signals. Since 19

26 an analogue filter is implemented in hardware, it is subjected to process and temperature variations. The adaptive filter is able to adapt to these changing conditions. In fact, adaptive techniques are employed to improve the accuracy of fixed analog filters. In our adaptive ECG project, we have an input which is continuous. Therefore, the fundamental building block for analogue continuoustime filters is the integrator. Currently most adaptive filters are done digitally, but there is a niche where adaptive analogue filters are used. Applications in which analogue filters is used are antenna systems, digital magnetic storage, and wired digital communication. Adaptive analog filters are great in these high speed applications because they require less circuit area and power consumption than its digital equivalent. If a digital filter is used, then an A/D converter is needed to do the filtering in the digital domain. When an analog filter is used, there is no need for an A/D converter, which results in the advantages stated above. There is a point at which an A/D converter cannot be used because of the high-speed bandwidth of the application. An example of this is Baseband communication which can reach speeds up to 2.5Gbit/s. For many applications, an all-digital or all-analog filter is impossible because both analogue and digital characteristics are required to achieve the desired result. For our adaptive ECG filtering project we will consider having an adaptive analog filter built into the hardware to do pre-filtering of the ECG signal. This filtering might filter out the ranges of the signal which an ECG cannot possibly have. Then the digital part could do the filtering at which the noise and the ECG values overlap. 6 Research Related to Project Definition 6.1 Existing Similar Products GE Medical MAC 800 The MAC 800 weighs only 3kg with the battery, its lithium ion battery provide the user with two hours of operation. It s easy to use keypad simplifies and speeds ECG operations with a mobile phone keypad design and quick-access function keys. Below in figures 9 & 10 is an image of the MAC 800 and the ECG display accompanying the MAC

27 Figure 9: Image of the MAC 800 Figure 10: ECG Display, MAC 800 The MAC 800 comes with the Marquette 12SL which empowers you with comprehensive computer-interpreted analysis of adult and pediatric populations for fast, accurate ECG readings. The acute cardiac ischemia time-intensive predictive instrument which is included with the Marquette 12SL program, enhances diagnostic accuracy by predicting the probability of cardiac ischemia, while also factoring in gender-specific criteria to help physicians more readily diagnose heart abnormalities in women MAC 1200 The MAC lead electrocardiograph system supplies advanced algorithm capabilities, and Cardio Soft Cardiology Information Systems. Its digitally stored and formatted data protects against data loss that can occur while in analog format. Its power supply runs at a frequency of 49 to 64 Hz, while its processor runs at hz. This device features a variety of different stress test procedures and creation of individual parameters. Figure 11 displays an image of a MAC

28 Figure 11: MAC MAC 3500 The GE MAC 3500 is a 12 lead ECG recorder with ECG analysis, it has an integrated ECG acquisition module. On its monitor it displays pacer spike and has pacemaker detection. It MAC 3500 provides an instantaneous 10 seconds of ECG acquisitions as well as a frequency response of 150Hz.it has a 10MΩ@10 Hz. As displayed in figure 12 is the MAC Figure 12: MAC

29 6.1.2 INVIVO Precess The INVIVO Precess is a MRI ECG patient monitoring system, it combines wireless communication, radio frequency shielding, and digital signal processing to face the challenges associated with patient monitoring in a MRI room. The Precess contains a wireless ECG, SpO, and battery charger module. The Precess s ECG amplifier has the ability to protect against defibrillator and electro surgery potentials, it also contains standard lead configurations I, II, II, AVR, AVL, AVF. The Precess has a sensitivity of greater than 200µV for an adult patient, the bandwidth ranges from.5-40hz. Figure 13 below is a picture of the INVIVO Precess and its accompanying display. Figure 13: Precess Display The accuracy is impressive with a pulse rate within 2 percent, the pressure span accuracy is ±2 mmhg and the pressure transducer ranges from 0-307mmHg. The Precess itself displays dual channel waveform scales, the heart rate is user selectable derived from invasive blood pressure. The integral cart display and the control room display the monitored vital signs and parameters. The front panel is capable of the controlling and has access for complete patient monitoring BIONET ECG 2000 The ECG2000 is a 12 lead simultaneous ECG and acquisition, that has a 3,6,12 and 1 recording channel. With a sensitivity of (5, 10, 20), it has sampling rate of 500 samples/sec. the filters it contains are AC (50/60Hz, -.20dB), the muscle is (25~35Hz, -3dB), the base line drift is (.1Hz, -3dB), and the low pass filter is (off, 40Hz, 100Hz, 150Hz). The electrical aspect of the ECG2000 is that it has an internal noise of 20 p-p, its input circuit is a floating input isolated and defibrillated to keep it protected. With a input impedance of 10M and a voltage range of 5V, Its DC offset voltage is 300V, and a frequency response of.05~150hz. As shown in figure 14 below is the ECG

30 Figure 14: ECG CARDIO 7 The CARDIO 7 is a 12 lead acquired simultaneously and continuously, that has a 3,6,12 and 10 seconds of recording and beat report including 1 channel with 60 seconds of recording. With a sensitivity of (2.5, 5, 10, 20), the filters it contains are AC (50/60, -.20dB), the muscle is (25~35-3dB), the base line drift is (.1Hz -3dB), and the low pass filter is (off, 40Hz, 100Hz, 150Hz). The electrical aspect of the CARDIO 7 is that it has an internal noise of 20 p-. With an input impedance of 10MΩ and a voltage range of 5V, its DC offset voltage is 300V, and a frequency response of.05~150hz. Below in figure 15 is the Cardio WELCH ALLYN 24 Figure 15: CARDIO Welch Allyn PC-Based Resting ECG The Welch Allyn CardioPerfect Pro Cardiograph is specifically intended for the recording of standard 12- lead electrocardiograms of patients. It turns any PC into a full-featured ECG and manages data for quick, easy retrieval of test information. The only obstacle for this device would be the user s computer or tablet; it requires a CPU with a least Pentium 4, a hard disk with 20GB and 5GB of free space, and a RAM of 512MB or 1GB. The display of the computer is important as well as you

31 will need a resolution of 1024 x 768 True Color, and monitor of at least 15. The guidelines ask for an operating system of Windows XP SP2 with 32 bits or higher. Below in figure 16 is the Welch Allyn CardioPerfect Pro. Figure 16: Welch Allyn CardioPerfect Pro Welch Allyn CP 150 Electrocardiograph The Welch Allyn CP 150 is the first in the line of resting ECG devices that Welch Allyn has to offer. It consists of auto ECG s and rhythm ECG s both of (2.5, 5, 10, 20mm/mV). It is capable of storing 100 ECG tests with a frequency range of.3 to 150Hz, and a sampling rate of 1000 samples / second per channel. The CP 150 contains three filter the high performance baseline is.5hz, the muscle tremor is 35Hz and the AC interference is between 50Hz and 60Hz. Figure 17 displays the CP Medical Hardware 25 Figure 17: Welch Allyn CP 150 The adaptive ECG Filter will be used in a medical environment and is designed to work with related medical equipment. Related medical equipment that the filter will interact with is MRI machines, ECG sensors, and ECG monitors. Medical

32 equipment is unique to most other types of equipment in that as well as being accurate, the equipment must not pose a safety hazard to vulnerable patients. Because of this unique requirement, The FDA (Food and Drug Administration) regulates the labeling, designing, manufacturing, and usage of all medical equipment. The CDC (Center for Disease Control) regulates the use of all medical equipment with sterilization and usage procedures that must be followed to prevent the spread of infections such as MRSA (Methicillin Resistant Staphylococcus Aureus), HIV (Human Immunodeficiency Virus), and even the common flu Medical Hardware Restrictions The FDA (Food and Drug Administration) regulates the manufacturing, usage, packaging, labeling, and distribution of medical devices. All medical devices produced must be registered with the FDA in accordance with regulation 21CFR Part 807. Medical devices are classified by the FDA to fit into 1 of 3 classifications. Class 1 devices are items like tongue depressors that are simple to produce and provide negligible potential harm to patients. Class 2 devices are items like patient monitors, x-ray machines, or analyzers that can potentially cause harm to a patient. Class 3 devices are item such as artificial heart valves that can potentially cause great harm to a patient. The FDA has different regulation standards for each class of device. Class 1 devices are least likely to cause harm therefore they are regulated the least. Class 1 devices must be registered with the FDA and follow FDA guidelines for good manufacturing practices. Most class 1 devices do not need a premarket notification before the product is distributed. Class 2 devices can cause harm to patients therefore they are more heavily regulated than class 1 devices. Class 2 devices must be registered with the FDA and follow FDA guidelines for good manufacturing practices. They must also have a premarket notification. A premarket notification is a form submitted to the FDA that requests approval to distribute a device. If the FDA deems the device to be safe, they will reply with a letter authorizing the distribution of the device. Class 3 devices have the most potential to cause harm to patients therefore they are the most heavily regulated. Class 3 devices must register with the FDA, follow good manufacturing guidelines, have a premarket notification, and have a premarket approval. A premarket approval is more intensive than a premarket notification and requires experimental and trial data to support safety of the device. The Adaptive ECG Filter will be classified as a class 2 device because there is a small potential to cause harm to patients. If the Adaptive ECG Filter were to be manufactured under normal conditions, it would require a premarket notification and approval from the FDA before use in a medical environment. The adaptive ECG filter would also be subject to following the FDA good manufacturing practices. FDA good manufacturing guidelines require that manufacturers comply with certain requirements in the manufacturing process such a quality control 26

33 testing and procedures. The FDA good manufacturing guidelines are divided into ten sections which have their own requirements. The sections are general, design and development planning, design input, design output, design review, design verification, design validation, design transfer, design changes, and design history file. The general requirements section says that manufacturers that manufacture any class 2 or 3 device must maintain procedures to control the design to ensure that the stated design requirements are met. The design and development planning section states that manufacturers must maintain design plans that reference the design and define responsibilities for design implementation. This section requires that the design plans are updated and approved as the design evolves. The design input section requires that the manufacturer establish procedures to ensure that the design requirements are appropriate for the needs of the device and that the needs of the patient are met. The procedures must be reviewed and approved regularly and have a plan for addressing conflicting or incomplete requirements. The design output section states that procedures must be established for documenting design output and the procedures must refer to an acceptable criterion for ensuring the device functions properly. The design review process section states that procedures must be established for reviewing the process at appropriate stages in the design process. The design review process must ensure that there are representatives from each aspect of the devices operations participate in the review. The design verification process section says that manufacturers must establish procedures to verify the design meets the device requirements. The results of the process have to be documented with the dates and names of the participants that participated in the verification. The next section is the design validation section and it says that procedures must be established for validating the device. The procedures must ensure that devices are tested under simulated and actual use conditions. When operating under actual use conditions they must be tested under normal conditions to identify any design problems. The guidelines also state that the results of the validation process are documented with the date, names, and equipment that was used in the process. The design transfer section only states the procedures must be established to ensure that the design is correctly interpreted in the manufacture process to ensure that is does not get unintentionally modified. The design change section states that manufactures must have procedures in place to documenting, validating, and approving design changes in the manufacturing process. The final section of the FDA good manufacturing guidelines requires that a design history file is maintained. The design history file must contain documentation from all of the previous sections in the guidelines and may be reviewed by the FDA. The design history file is arguably the most important document from the design process. The design history file documents every aspect of the design process and can be used as a reference in the future. The FDA Good Manufacturing Guidelines refer to a scenario when the design history file was not maintained and it adversely affected the equipment manufacturer. In the scenario, a device started to develop a problem in middle to its lifecycle while it was in use at doctors offices. 27

34 The problem was investigated and it was determined that the issue resided in some the devices microcontroller software. During the design and manufacturing process the programming was subcontracted to a vendor that provided the preloaded microcontrollers to the device manufacturer. Over a period of time the subcontractor stopped making the microcontrollers and did not keep a record of the programming. The manufacturer also neglected to accurately maintain the file and the program was not saved. Because the manufacturer did not have the original data they were forced to redesign the complete system and had to recall and destroy the original equipment at a great cost. The FDA Good Manufacturing Guidelines go on to say that this was an extreme scenario that demonstrates the potential value to the manufacturer by properly maintaining the file. Along with the guidelines to put a device on the market, the FDA continues to monitor medical devices when they are in use. The FDA requires that incidents caused by medical devices be reported to them in accordance with regulation 21 CFR Part 803. The data used in the reporting is used to identify and correct problems that may occur with a medical device. If an unacceptable amount of problems arise a recall will be issued and the device will be taken off the market MRI Machine The MRI (Magnetic Resonance Imaging) Machine is a large machine with a tube located in the center that patients are placed into. While in the tube, the machine uses powerful magnets and RF (Radio Frequency) transmitters to manipulate the hydrogen atoms in the human body to develop an image of different tissues inside the human body. MRI machines are used to diagnose tumors, cancer, and other diseased found in soft tissue organs such as the heart, lungs, or brain. The MRI Machine works by using the technique of nuclear magnetic resonance imaging to create detailed images of the inside of the human body. This technique involves subjecting an individual to a strong homogeneous magnetic field. The Magnetic field causes the nuclei of hydrogen atoms to align with the magnetic field. Then the machine introduces a RF pulse (known as a gradient) on the atoms in a specific area to cause the nuclei to rotate either 90 or 180 degree away from the homogenous magnetic field. When the pulse is turned off, the nuclei rotate to realign with the magnetic field. During this realignment the protons in the nuclei release energy. Based on the released energy, the machine is able to generate an image of the internal tissues in a body. This process is repeated multiple times from different angles to create a 3 dimensional image of the internal body tissue. All MRI machines operate on the same principals but there are different types of models and designs. The most important feature to look at when comparing MRI machines is the homogeneous magnetic field strength. Magnetic field strength in MRI machines can range from.5 T to 3T. The machines with a higher magnetic field strength produce a better image because they have a better resolution. The only negative aspect of the 3T MRI machines is that they produce a stronger magnetic field therefore they are more restrictive on what patients can use them. 28

35 A patient with a piece of metal in there leg from a surgery may be able to use a 1.5T MRI machine but not a 3T MRI machine. Another difference amongst MRI machines is their physical shape. MRI machines have either a circular or a rectangular area that a patient is placed in. The most common MRI machines have a circular tube but newer machines use a rectangular area. The use of a MRI machine necessitates that specific safety precautions are followed. An MRI machine can produce up to a 3 tesla magnetic field. This magnetic field can cause metallic objects both inside and outside a human body to become projectiles. Patients with certain metals located inside of their bodies can suffer fatal consequences if they were to be subjected to an MRI scan. Because of this, certain patients may not be candidates for MRI scans. Operators must also be careful in a MRI environment. If an operator were to have a metallic pen in their pocket, the magnetic field can cause that pin to be a missile that can hit and possibly kill a person. The ECRI (Emergency Care Research Institute) published an article titled Patient Death Illustrates the Importance of Adhering to Safety Precautions in Magnetic Resonance Environments in August 2006 that outlines some of the safety practices that should be observed. The article was written in response to an incident in New York that caused the death of a 6 year old because basic safety precautions were not followed. A basic non-exclusive outline of the essential operating guidelines is as follows: 1) Always assume the magnetic field is always on. 2) Identify the area around the MRI system where the magnetic field exceeds 5 Gauss and make it as a restricted area. 3) Never allow equipment containing magnetic components in the 5G magnetic field. 4) Never assume devices are MRI safe. 5) Screen all patients to ensure they do not have metal inside their bodies. 6) Have patients wear hospital gowns to ensure there is no metal on their clothes ECG Electrodes and Lead Cable The heart works like a pump and operates in 2 cycles that have 2 phases. During the first cycle the diastole phase pumps blood into the heart (specifically the right atrium) and the systole phase pumps blood into the lungs to be oxygenated. During the second cycle the diastole phase pumps blood into the left atrium of the heart and the systole phase pumps the oxygenated blood into the rest of the body. This heart rhythm is standard for a healthy heart and irregularities in the rhythm are indicators of life threatening medical conditions. 29

36 ECG electrodes are placed at different points on a patient s body depending what ECG monitoring system is being used. There are configurations that consist of twelve leads, five leads, or three leads depending on the equipment being used. The Adaptive ECG Filter is designed to work with the three lead system. The leads in the three lead systems are labeled according to where they are normally placed. The names of the leads in the three lead system are RL (Right Leg), LL (Left Leg), RA (Right Arm), and LA (Left Arm). The three lead systems have four electrodes but only use the LL, RA, and LA electrodes. The RL electrode is normally left of the body and used as a ground for reference. Using the RL as a ground electrode helps to prevent any electrical interference that may be in the system. The leads measure the electrical differences between the electrodes so that V1= LA-RA, V2=LL-RA, and V3=LL-LA. These lead values are what is processed and displayed on an ECG monitor. The electrode consists of a contact area that picks up the electrical signal from the heart and a contact that attaches to a cable. Because electrodes are made to pick up an electrical signal they often contain Ferris metals that are not compatible with MRI machines. There are also different types of electrodes such as disposable, reusable, prewired, wireless, etc. Electrodes come in different sizes with different features such as clear plastic or pull tabs to make them easier to remove. The adaptive filter will work with many of these types but it is specifically designed to work with Philips Invivo MRI compatible Quadtrode electrode. Philips Quadtrode electrodes are the ideal electrodes to use in a MRI environment. MRI machines radiate a strong electromagnetic field and cause metals to heat. The heat from these metals can burn a patient and cause great discomfort. Philips Quadtrode electrodes overcome the heating problem by reducing the amount of non-ferris metal in the electrode by creating an electrode contact made with a thermoplastic compound. The Invivo Quadtrode electrode has a large surface area to increase conductivity and uses a proprietary gel to prevent burns. In figure 18 below it demonstrates where the Invivo Quadtrode electrodes are placed on a patient s body. 30

37 Figure 18: An image of the Quadtrode Electrode The ECG lead cable is just as important as the electrode. The cable must be designed to generate as little heat and interference as possible because it is also used in a MRI environment. The main design consideration in the manufacture of ECG cables is minimizing the amount of conductive material used. Conductive material is necessary for transmission of the ECG signal but it also generates heat and interferes with the MRI image. Having a thick cable or a thin cable that is coiled causes the ECG cable to generate more heat from the MRI machine. The heated cable has been known to cause painful burns on a patient s skin. Thick or coiled cables also obstruct the image that the MRI machine is trying to produce which can possibly result in a wrong or missed diagnosis. A standard ECG cable consists of 4 leads that attach to the electrodes on one end and an adapter on the other end that attach to the MRI machine or the Adaptive ECG filter. The 4 leads have a circular clip on them for attaching to electrodes and can be observed on the right side of the image below. The plug that connects into the MRI machine or Adaptive ECG filter is industry specific and can be observed on the left side of the image below. The cable the Adaptive ECG filter is designed to work with is the Philips Invivo Quadtrode Lead Cable. The Philips Invivo Quadtrode Lead Cable is the primary ECG cable in the Philips Invivo product line and is designed to be ECG compatible. An image of the Philips Invivo Quadtrode Lead Cable can be observed in figure 19 below. 31

38 Figure 19: Philips Invivo Quadtrode Lead Cable ECG Machine/monitor The ECG (Electrocardiograph) Machine receives, processes, and displays a patient s heart activity for a medical professional to review. The machine takes the data it receives from electrodes and displays the strength, pattern, and frequency of a heartbeat in the time domain. The information obtained from an ECG machine is used to diagnose medical conditions such as irregular heartbeats, heart attacks, heart murmurs, and seizures. The waveform displayed on an ECG machine is what is used to diagnose medical conditions. When a heart beats there is a weak electronic signal, strong electronic signal, and then another small electronic signal. The presence, amplitude, and spacing of these heartbeats can be changed due to a number of medical conditions and are used for diagnosis. The first spike in the ECG waveform is known as the P wave, the second spike is known as the R wave, and the last spike is known as the T wave. The two downward notches are known as the Q wave (located between P wave and R wave) and the S wave (located between the R wave and T wave). The space between the P wave and the T wave is known as the PR segment and the space between the R wave and T wave is known as the ST segment. The space between the PR segment and ST segment is known as the QRS complex. The interval of an ECG signal is normally measured on a grid in increments of.04 seconds on the X-axis and.1mv on the Y-axis. The ECG waveform can be interpreted to determine activity of the heart. From looking at the QRS complex the instantaneous heart rate (in beats per minute) of a patient can be determined. To measure the instantaneous heart rate you have 32

39 to measure the time between the QRS complexes which will give a value of X seconds per beat. Then divide the number 60 by X and you will get the instantaneous heart rate of a patient in beats per second. By looking at the P wave its can be determined if a patient has a regular sinusoidal rhythm. If a P wave is missing and the QRS wave is irregular a patient has an atrial fibrillation which is common for patients with chest pain, fainting, or congestive heart failure. If the P waves form a saw tooth pattern a patient has an atrial flutter which is commonly associated with heart failure. When a patient goes to the hospital after believing they had a heart attack they are connected to an ECG and the doctor examines the patients Q wave. A wide and deep Q wave is indicative of a recent myocardial infraction which is also known as a heart attack. A large R wave is indicative of a ventricle hypotrophy which means that the walls of the heart are hardening. The T wave can be examined to determine if a patient has conditions such as a myocardial ischemia or a hypothyroid. If the T wave is flat or inverter a patient may have a myocardial ischemia and if the wave is flat with a notch a patient may have a hypothyroid. These are just some of the many common conditions an ECG used to diagnose. The Adaptive ECG filter is universal but designed specifically to work with the Philips Invivo Patient Monitoring System. The Philips Invivo Patient Monitoring System is capable of monitoring more than just ECG data and consists of a computer containing an ECG machine, ECG monitor, wireless electrode system, and battery pack. The monitoring system is contained on a cart and has a detachable monitor that be separated from the main system for remote monitoring. The front of the machine has an adapter that receives the ECG plug as well as a wireless system that can receive the ECG data remotely. The advantage of the wireless ECG system is that the wireless adapter can be placed close to the patient with a shorter cable therefore reducing attenuation and heat generation on the cable. An image of the Philips Invivo Patient Monitoring System can be observed below in figure 20, while figure 21 also below shows the handle held control monitoring controller 33

40 Figure 20: Invivo Patient Monitoring System Figure 21: Wireless Transmitter for Patient Monitoring System 34

41 Below in figure 22 is a functional block diagram that displays how the Adaptive ECG Filter is going to interact with the Philips Invivo ECG equipment shown above. It should be noted that the Adaptive ECG Filter requires the use of an additional ECG cable and the ECG Filter combined with the cable is displayed in the dashed block on the diagram. As you can see the Adaptive ECG Filter is connected inline between the ECG electrode cable and the wireless adapter. The only downfall of the Adaptive ECG Filter is that it adds to the amount of equipment that is being used. In the future, wireless technology may be added to the Adaptive ECG Filter but it is not being added in the scope of this project. Also, the diagram below is used only to demonstrate connectivity with the Philips system and does not include the tablet computer feature that may be integrated into the Adaptive ECG Filters functionality. 35

42 Patient Miscellaneous monitors (such as SpO2 and Resperation ) ECG Electrodes ECG Lead Cable Adaptive ECG filter Wireless Adapter ECG Lead cable Wireless Electrode Adapter Patient Monitoring System (includes computer with ECG machine, SpO2 machine, and other patient monitoring equipment) Display (Displays ECG data along with any other data required) Figure 22: Philips System with Integrated Adaptive Filter 36

43 6.3 Digital Filters The software in this product is utilized to improve the quality of the MRI. There are many different types of frequencies and we must take utmost care to ensure that we do not use frequencies that are needed to diagnose certain things in patients. There are a variety of different filters that will be tested to deliver the best results. The filters discussed in this section will include the Butterworth Filter, the Savitsky- Golay filter, Adaptive Smoothing and a variety of other filters. These filters will also be compared afterwards discussing their strengths and weaknesses in an effort to decide on one global filter to use for all, or most cases Butterworth Filter The Butterworth filter is also referred to as a maximally flat magnitude filter. This is because the Butterworth filter attempts to have as flat of a frequency response as it can possibly have, where the frequency response is measured in the passband. This filter was first described inside a paper by none other than Stephen Butterworth. Butterworth, in regards to this filter was quoted as saying: An ideal electrical filter should not only completely reject the unwanted frequencies but should also have uniform sensitivity for the wanted frequencies". As such the Butterworth filter will be particularly useful for applications where a specified range of frequencies is needed Savitsky-Golay Filter The Savitsky-Golay filter for smoothing differentiation is a filter that smooth s the curves by utilizing the solutions to the least-squares equations. The Savitsky- Golay filter is very good at smoothing the filter out and making it appear a lot less noisy. The Savitsky-Golay is able to reduce smoothing on the peak values. However, the Savitsky-Golay, when applied to an area that isn t as varied has a lot less effectiveness and can be equivalent to an average filter. A different type of filter entirely is adaptive smoothing. Professor Ke Chen produced an article called A Feature-Preserving Adaptive Smoothing Method for Early Vision, in this article Professor Chen from Peking University discusses the strengths of adaptive smoothing. Adaptive smoothing is used to avoid many of the shortcomings found in linear smoothing. Adaptive Smoothing is a non-linear smoothing algorithm. Adaptive smoothing essentially finds the relative differences among the pixels. After finding the differences, adaptive smoothing then applies a filter over the image to smooth it and to enhance the edges. In doing this Adaptive Filtering removes a lot of the extra data and keeps the important information. One of the biggest issues in regards to adaptive smoothing is the necessity to update the strength a pixel has with an average of the strength of its neighboring pixels. This algorithm is in general better than the Butterworth Filter and the Savitsky-Golay filter. 37

44 Another advantage to the adaptive smoothing algorithm is that over a large number of iterations, the image quality does not change a lot. Most other algorithms move towards an image with a unified strength. In the adaptive filter simulations, they apply the Sobel edge detector to get the edge detection. The article further states that said edge detection technique is fairly efficient and retrieves a lot of the noise from images. Also, the articles states that their results are better than the best result from the optimal infinite impulse response filters. These values were obtained using multiple variable combinations and hysteresis thresh holding Non-linear Diffusion Filtering Another non-linear filter is Nonlinear Diffusion Filtering. This utilizes the standard Gaussian smoothing technique and attempts to fix many of the issues associated with it. The standard Gaussian filter has poor edge preservation and in an effort to retain some of the edge preservation while utilizing the smoothing technique of the Gaussian, the smoothing is performed only on areas that are homogenous. That is, they have no interaction with regions touching or regions that have a common border. This allows the Nonlinear Diffusion Filtering to retain rather sharp edges and remove a lot of the extraneous data that is delivered to the MRI machine. Another method to enhance upon the Gaussian is the Anisotropic Gaussian Smoothing method. This method calculates a greyscale gradient vector and attempts to smooth along the edge as opposed to across it. This method is largely affected by the strength and number of iterations. The smoothing is also decreased around strong edges but, when an image has fewer strong edges it is more useful. Each of these methods is able to filter an image and produce at least fairly decent results. When we perform analysis on these, we will pay particularly close attention to the non-linear methods and see what ranges we need to keep and what ranges we can remove. We will also check to see what happens when more than one filter is placed on the same image. To implement these methods a very strong choice for us is to use MATLAB, which is known as the language of technical computing, where one can analyze data, develop algorithms, and create models and applications. The reasoning for this is because a lot of the filters are included in a library and we would not have to code the features ourselves. Of course, we will be trying to implement the MATLAB features on a microcontroller and this may not be possible due to some of the limitations MATLAB has in regards to converting their code to C. If this problem arises we will come to a point of deciding whether to use a C/C++ library, build the code ourselves or to just use an entire computer as the interfacing device. We think that the project itself would be more energy efficient and a much 38

45 cleaner implementation if we were to use a microcontroller of some sort for this task. We are also considering using a Raspberry PI or some other cheap low powered device that will allow us to deliver the necessary results for the ECG system Least Mean Squares Filter The Least Mean Squares Filter is an adaptive filter itself. It attempts to recreate a signal without noise. In test runs, the LMS algorithm was very successful. The Least Mean Square algorithm was able to filter out a lot of noise and could recreate a signal in many cases when it would not be feasible manually. Below in figure 23 is a picture of the Least Mean Square Algorithm from MATLAB with filters in place to make a Sine wave look fuzzy. Figure 23: LMS MATLAB Example Per these excellent results with this filter; we certainly plan on using the LMS adaptive filter to ensure accuracy within our results. In the next few pages, we will discuss the benefits/downfalls to other filters. But, the LMS is a common filter that is currently used in a lot of ECG, MRI equipment and we certainly plan on testing it out more when we have the chance to use the actual equipment. 6.4 ECG Noise Contributions Knowing how noise is introduced into an ECG signal is very important for us, because that is what we want to be able to filter out. We must identify the type of noise in the ECG signal and then choose a filtering algorithm suitable for dealing with it. Noise can come in multiple different forms. Such examples are: 39

46 Electrical interference from power lines add 50 or 60 Hz power-line frequency. Muscle contraction and muscle activity can generate high frequency electromyography (EMG) noise. Motion artifacts such as movement of the electrode over the skin surface. Impedance changes at the skin/electrode interface due to temporary loss of contact or loose electrodes. Baseline drifts due to respiration. Noise introduced due to instrumentation or electronic devices. 7 Project Hardware and Software Design Details 7.1 ECG Filtering Software The software used to do the ECG filtering will need to be run on a small embedded processor capable of doing real-time Digital Signal Processing (DSP) calculations. The DSP system will have 4 inputs from each of the electrodes on the patient and 4 outputs, each a digital signal. Each electrode will collect samples of the ECG signal at a very fast rate, approximately 50 khz at about 500 SPS (samples per second). Since there are 4 electrodes, the data processing requirements to do real time DSP will be demanding. The plan for developing this project was to use MATLAB and Simulink to do the design of the filtering software and then use MATLAB s code generation toolboxes to generate the code specifically for our chosen architecture. MATLAB would also be used to compare and analyze the efficiency of various filtering algorithms available within the DSP System Toolbox library. If this idea did not work then we devised a backup plan where we would do the coding ourselves using C++ directly onto the embedded processor. Problems arose because the price of MATLAB with the necessary toolboxes would cost $2,900 in licensing for just one person. This is way too expensive for our project. Also we decided the comparing of filtering algorithms to be too time consuming. To be efficient in working on the project we would need two copies of this licenses. One for each of the two Computer Engineers that do the software. Technically our budget could have covered this cost, but we felt that it wasn t worth the price and we did not know at that time exactly how much the hardware part of the project would cost. We choose to use Code Composer Studio as the development environment for writing the filtering program that runs on the ARM Cortex M4 microprocessor. This environment required us to use Embedded C++ instead of regular C++ because 40

47 regular C++ was not supported. We used MATLAB as a side program to read the output data from our PCB board and to display the results of the filtering. The sections below describe our original idea and the components supported in it. This are still important because our project could still have been done this way if we had more funds MATLAB MATLAB, which stands for MATrix LABoratory, is a high level language and an interactive environment that lets you focus on the problem at hand rather than worrying about the details in programming. It contains many numerical libraries and prebuilt functions that make writing programs faster than in a low level language like C++. There are no declaring of variables, allocating memory, or pointers, so programming in MATLAB is much less error prone. Therefore, you are able to spend more time developing algorithms to solve your problem than worrying about the low level details. MATLAB is built for technical computing. Thousands of engineering and mathematical functions are available, eliminating the need for you to code them yourself and test them. For this project we are not completely sure which adaptive filtering algorithm will prove to perform best or not. If we were to code up each adaptive filtering algorithm ourselves, it would be extremely time consuming and redundant work. Knowing which filter to use, how to apply it, and how to test that it works, is what we expect to be the hardest part. Therefore, MATLAB will be used as a testing platform for these filtering algorithms. Once we know something works, it will be coded in C++ for use on the embedded processor. The base installation provides all the basic libraries for you to do general computing. However you can add-on functionality through MATLAB toolboxes, which are purchased separately. These toolboxes support just about everything you could possible do in the realm of computing. For MATLAB the toolboxes that are of interest to our project are the DSP System Toolbox and the Signal Processing Toolbox Simulink Simulink is another product family of MathWorks which is designed to work with MATLAB. Simulink is a block diagram environment for simulation and Model- Based Design (MBD). It supports linear and nonlinear systems, modelling in continuous time, sampled time, automatic code generation, and continuous test and verification. It can integrate with MATLAB, enabling us to incorporate algorithms and export simulation results to analyze. One such toolbox that can be integrated is the DSP System toolbox from MATLAB. We can have a block in our model that uses the different filtering algorithms from the DSP toolbox. Simulink also provides toolboxes for generating code from its models such as the Embedded Coder and Simulink Coder. 41

48 Simulink provides support for prototyping, testing, and running models on low cost hardware. Supported hardware are Arduino, Raspberry Pi, and as of release 2013b ARM Cortex-M series. You can connect your Simulink model directly to the hardware for rapid prototyping and deployment, which is done through processor in the loop (PIL) design paradigm. This would allow us to quickly verify the algorithms work on the hardware. If we were to build our system using one of these platforms, PIL would allow us to quickly model and test our code on a real embedded system. Speeding up the coding development time is valuable to our team and for our project. We will investigate the viability of using MBD to directly deploy our algorithms onto the hardware Model-Based Design Model-based design (MBD) is an efficient way to develop software especially for embedded devices. MBD is significantly different than traditional design methodology. The traditional methodology is where you build complex structure and extensive algorithms using a low level language like C or C++. The advantages of MDB compared to the traditional approach are: MDB provides a common design environment, which helps in communication, analysis, and verification between team members. Errors can be located early in the system design and then corrected. This can minimize the time impact of the system as it is harder to correct the errors the further into development you go. Design reuse, upgrades and expanded capabilities are easily able to add. The traditional approach can cause human errors during the coding process, which lengthens the development time. In MBD, models are defined with advanced functional characteristics using continuous and discrete-time building blocks. By using these blocks the data structures and algorithms are already coded for you. You can focus on things such as the logic of putting these blocks together, testing, verification, and deployment. The graphical modelling environment in Simulink allows the user to conceptualize the entire system. MBD can be used throughout the entire development process, going through requirements, design, implementation, and testing. The model can be continuously refined as you go through these stages of the development process. By using Model-Based Design it will allow us to improve efficiency by linking the model design to our requirements, integration testing with the model design to identify and correct errors, refine algorithms through simulation, generate code for embedded devices, develop test suites to verify results are accurate, and to automatically generate documentation. The main steps of Model-Based Design are: 42

49 Design a plant model. A plant model is the system, process, or device you intend to control. It defines the mathematical relationship between the plant inputs and outputs. The mathematical relationship can include algebraic equations, logical equations, differential equations (for continuous systems), and difference equations (for discrete systems). An example of a plant model is shown below in figure 24. Figure 24: Definition of Plant Model (Permission from MathWorks) Controller analysis and synthesis. The controller is the algorithm which controls how the plant model works. This step is used to identify the dynamic characteristics of the plant model. Real-time simulation with the plant and controller. Simulation allows for requirement and modelling errors to be found immediately. Real-time simulation can be done by generating code for the controller and deployed real time into the prototype computer. Deployment. This is also done by automatically generating code from the controller and load onto the actual system. This will use real input and output but can still be monitored by Simulink for debugging purposes. Implementing model-based design into our development workflow will be essential to completing this project in a timely manner. MBD is a design process going from requirements all the way to deployment on the system. A limitation of using this approach is that you are relying on the code generation of the software. If you use a platform that the code generation does not support, then it probably won t be very viable to use code generation because the code might not work, or will not perform well. If the platform you use is supported, then we must verify that the code does indeed perform as needed. 43

50 7.1.4 Processor-in-the-Loop Processor-in-the-Loop (PIL) is when the control system no longer runs in simulation but rather deploys it to a microcontroller. Deploying consists of compiling the controller and download onto an embedded processor which communicates directly with the plant model. The code running on the microcontroller is connected, not through the I/O pins, but through some high speed bus. This is used to expose errors when running the model on the embedded environment. This needs to be done because what if the execution for filtering one data point does not complete execution in time to process the next input point. Then the execution cycle time needs to be reduced. You might not notice something like this initially because on the simulation on your computer, the computer can handle the intense calculations, but the embedded system might not. Below in figure 25 is a diagram for how the plant and controller model integrates using the embedded target to run the code. 44 Figure 25: Processor in the Loop Diagram The controller model generates code to be run on the embedded system while the plant model continually monitors the system Toolboxes Toolboxes are available from either the MATLAB product family or the Simulink product family. Toolboxes of possible interest to our project are the DSP System Toolbox, Signal Processing Toolbox, Simulink Coder, MATLAB Coder, and Embedded Coder. The DSP System Toolbox provides algorithms for designing and simulating various signal processing systems. All algorithms in this toolbox is implemented as

51 MATLAB functions, MATLAB System objects, or Simulink blocks, allowing you to use them in either of these. For adaptive filters, this toolbox has techniques to design many types of adaptive filters. It can analyze these filters by tracking the coefficients, learning curves, and convergence, which can be visualized through graphs. The adaptive filter techniques available are LMS-based, RLS-based, affine projection, frequency-domain, and lattice-domain. The Simulink Coder toolbox generates and executes C and C++ code from Simulink diagrams, Stateflow Charts, and MATLAB functions. It can also customize the generated code to be optimized to run in a real-time environment and provides a complete framework for enabling this. It includes tons of configuration options about how the code should be generated. The advantages of using this toolbox is that we can use Simulink s advanced modelling suite to model and test our system before we start to deploy it. The MATLAB coder generates standalone C and C++ code from a subset of the MATLAB language. The generated code is portable and readable. The limited set of functions which it exports from does include the DSP System Toolbox. The Embedded Coder generates readable, compact, and fast C and C++ code for use on embedded processors. It includes the MATLAB Coder and Simulink Coder configuration options which enables it to fine-grain the generation of code toward the target platform and improves code efficiency. Some features are processorspecific code optimization, code verification, and integration into popular embedded development environments such as Texas Instruments Code Composer Studio. For MATLAB configuration you can output the code to, either a MEX-file, C/C++ static library, or C/C++ executable. For the Simulink configuration files, you can generate C, C++, and encapsulated C++ code with floating-point and fixed-point data for efficient real-time execution on virtually any production processor. These configuration options and advanced optimizations fine-grain the control of the generated code s functions, files, and data. The generated code can be executed on processors to verify behavioral performance and to gather resource metrics through processor-in-the-loop (PIL) techniques. As of release 2013b, embedded coder has support for code generation for the ARM Cortex-M series of processors. We are considering a Cortex M4 processor for our project and this might alleviate the potential problems listed below Potential Coding Problems If we are using the coder toolboxes to export the working simulations into code to be run on an embedded processor, there are many problems that can happen. The generated code in C++ might become difficult to interface with the C++ framework. As your program grows in complexity, so does how you re going to interface with it, either monitoring the code performance or adding functionality to existing generated code. By using the coder toolboxes, you are limited to using a subset of the MATLAB language and so some functions you used in the simulation 45

52 might not be available for use in the conversion, therefore you might have to code these segments yourself. By coding some sections yourself and then using parts of the generated code, interfacing with the program might become conflicting. Also the code generated from the coder toolboxes might not always be the best performing versus handwritten C++ code. A reason why the generated code might not be the best performing is because of the complexity of the coder toolboxes. They have many settings to tweak and the users, us, might not know what would be best for the code. Therefore, the time spent learning the toolboxes could be better used to code the algorithms ourselves using C++. A solution to overcome the coder toolbox problems, is to use the MATLAB/Simulink software as a more test-assisted approach. This means that we code and simulate the algorithms in that software until we have a working solution. Then we recode the algorithms in C++ in a way that makes it easy to modify and add functionality. This would eliminate the potential problem of interfacing with generated code. Then we can make a Mex file that interfaces with the C++ code which would enable us to test our C++ code in MATLAB against our known working MATLAB code. This could be a much more efficient way to get the project working. If we use the above solution, the main bottleneck would most likely be ourselves in coding the model in C++. The adaptive filter algorithms are not easy to understand nor are they to code. By coding them ourselves it will increase development time by human errors and understanding how to code these adaptive filters. Our biggest restraint on this project is time and so this solution might not be feasible when we get to that stage in development. A solution to this would have to be that the embedded coder toolbox works fantastically so its generated code runs fast and efficient on the embedded processor MEX MEX stands for MATLAB Executable. MEX-files are used to call your own C, C++ subroutines from within the MATLAB environment as if it was built into it. The MEX-files are able to dynamically link the subroutines that the MATLAB interpreter loads and executes. This is useful because once we code the filtering algorithms in C++ we need a way to compare them to the working MATLAB equivalent version. Therefore, the MEX-files can be used to run our C++ code within MATLAB to pass the same input and then compare results. If our C++ code has the same results as the MATLAB code, it would be safe to call them equivalent. In order to use C++ within MATLAB, you must build the C++ code using the MEX commands in MATLAB. These sequence of commands must be called: mex setup mex option1 optionn filenames 46

53 The first command goes through a setup process of selecting the compiler configuration by searching for installed compilers on your computer. If no compiler is found on your computer, then it gives you a link to download the supported compilers. The compiler that we need to install is the Microsoft Windows SDK 7.1. The second command compiles and links one or more C, C++ source files into a shared library. The option1 optionn supplement or override the build arguments. Once the file is built, it can then be called by using the filename it was built with. You can pass parameters and the program will spit out the output into MATLAB Licensing MATLAB and Simulink Originally we thought that the student version of MATLAB and Simulink would fit our needs for the project. However after taking a closer on the required toolboxes, some of them are not available as student versions as they have the professional versions. We could not mix student and professional versions of toolboxes and MATLAB versions. Therefore everything had to be the full price of the professional version. Figure 26 shows the price breakdown for this software. Product Price MATLAB 2013b $500 Simulink $500 DSP System Toolbox $200 Embedded Coder $500 MATLAB Coder $500 Simulink Coder $500 Signal Processing Toolbox $200 Grand Total: $2,900 Figure 26: Price Quote of MATLAB software 7.2 Initial Design Architectures and Related Diagrams One of the primary filters we will be investigating in this project is the Least Mean Square Filter. As this filter has been incorporated into many different uses in the past, a considerable amount of documentation references it. Creating a diagram showing the basics of the Least Mean Squares Filter is beneficial to the project. 47

54 The Least Mean Squares Filter will be created in the Microprocessor. Whenever the Microprocessor receives data, it instantly updates its weights, obtains the filtered data and sends the signals. These signals are then displayed on the screen. The Analog Front End will continuously send data so the filter will happen repeatedly and will be inside of a loop. The Least Mean Squares Filter is an adaptive filter, so a non-adaptive filter would be a little simpler. Instead of changing the weights, the signal would just be applied to the inputted data. When created, the Sequence diagram is simpler for a filter that is non-adaptive. One such filter is the Butterworth filter. This filter is used inside of a loop that takes in various different Analog signals. Since the Analog Front End is continuously sending it data, it must update immediately to the Screen. This is faster than the Adaptive filters because it doesn t need to update anything or revise how data is displayed. The data just passes through the filter and the results are given to the screen. This filter can be created as an Analog or a Digital Filter. In this project we will be creating the filter as a digital filter. MATLAB already has this filter built into it, but, we must make sure the output from MATLAB is correct and we tested the filter with data we have and with a filter created using the CMSIS libraries. One of the main reasons we implemented it as a digital filter, is because we would prefer to change a few lines of code to change filters as opposed to using entirely different hardware. Of course, there will also be Analog filters to remove some signals prior to the use of the Digital Filters. For example, the Analog filters are able to remove high frequencies from the results. As such, the signal retrieved by the Microprocessor is already partially filtered. This filtration will be analyzed against the filtering of the Microprocessor to ensure a certain level of enhancement is done on the signal. Another instance that we checked on is whether or not our system is better than the current system in place. We checked the results on multiple different inputs and determine which result is the most valuable for the end user. We also checked to see if an Adaptive filter is always better than a non-adaptive filter and in which circumstances our program should choose to use the Non-Adaptive filter. Our data filtered with the Least Mean Squares Filter was not as accurate as the data filtered using the Linear Filters that Philips currently has. This result means that changes will need to be made in future iterations of our project to ensure that the results are better. Obviously, the best way to filter out the data is to know exactly where the noise is and remove it from the data. Unfortunately, knowing an exact number is not possible to do and requires an approximation. Since the program will be utilizing a large variety of filters, we need to create a program that takes a filter in as input, performs an analysis based on the filter and then outputs said data. This program will be built dynamically to allow this to happen. To allow the program to be dynamic, there will be an interface called 48

55 IFilter which will essentially be used to call the filters methods. Each filter will have to override the methods required inside IFilter and have default values set for each of the values required by the specific algorithm. As IFilter will not have access to the individual variables it is necessary for them to be predefined, or to be defined inside a configuration file which is specified inside the algorithm itself. For the interface to work properly each of the objects has to implement a specified set of methods. The interface itself does not contain any data. It is an abstract class that has access to the methods inside it. The methods that the interface uses are implemented by other classes. When one wants to use something that uses the interface they would define the interface and set it equal to the object that they want to access. After doing so, the programmers would be able to use any method inside the interface, but none of the methods directly associated with the object itself. This is advantageous to allow multiple variables to be used in one program based on them inheriting the values inside of the previously defined interface. Below in figure 27 is a UML class diagram showing how the classes will be implemented with regards to the interface. Figure 27: Filter Class Diagram As displayed previously, we enabled the IFilter interface for use with multiple different filters. These filters include the Butterworth Filter, the Savitsky-Golay Filter, the Least Mean Squares Filter and the Adaptive Smoothing Algorithm. Using these various filters will in future iterations of this project provide an easy way to compare different filters and select the best filter. It also allows for expandability in case other filters are discovered or problems with any given filter 49

56 are found. The code can be updated and everything should in theory work. We plan to use this interface on more classes that we create and will be testing on. A configuration file to store the data for the objects is perhaps the best choice. Using a configuration file is a good idea so that changes can be saved and autoupdated. It s as simple as changing the configuration file we are using. This will allow quicker testing and remove inaccuracies because we could accidentally mistype something when switching the values around. Therefore, we will be utilizing a configuration file with the program to prevent the hard coding of variable values and to make the future user s work easier. To receive the data for the filters, we developed a Publish/Subscribe system. The publisher will notify the subscriber whenever it receives data from the MRI machine. After receiving data each subscriber will perform their specified action. The subscribers function will be added to the topic which the Publisher will notify the Event Manager of. The configuration file if created would have been done in XML format, and would specify exactly which values are which. The name of each value would have been enclosed in brackets (< and >) and the value would have been set after the definition. After the value was defined an end bracket would have been placed. This will allow for a lot of readability with regards to the file and will be easier to change. It would have also allowed modularity with regards to other programming languages, because XML is a standard data format for reading and parsing data. The configuration file was however deemed unnecessary for our project due to only implementing one filter. To create and read the configuration files, we would have used TinyXML. The primary reasons we previously chose TinyXML is because it works with the language we want to use, it s free, has great reviews, and is easy to use. As such, we feel that TinyXML is one of the best choice in regards to XML parsing and writing. Some of the reasons it is easy to use is because of the large number of users. The more users you have, the easier it is to find tutorials. This is true for TinyXML, which is also made for C++. The program has an average of 4.8 stars with around 300 reviews. However, due to us using Embedded C++ as opposed to C++ this was not possible. After we coded the algorithms, we would have needed to create a program that analyses the quality of the results versus other results. To compare the results we would have subtracted the values from each other, square them and add them together to find the difference between them. The smaller the value, the closer the two comparisons are. We would have done this for multiple different scenarios. We would also record the outcome of each scenario as the number it is currently displaying and as the type of filter being used. However, since we only implemented one filter a comparison of different algorithms was deemed unnecessary. 50

57 Another option for comparing the results is to use a correlation coefficient. This is more likely a better option than the aforementioned idea. Using a correlational coefficient is generally a better idea for the project as it is easier to understand than the previous idea for comparing the data sets. The Correlational coefficient is also easy to solve using a program created in C++. This program would have been tested and would have been created to ensure that multiple data sets and different algorithms can be pushed through it. There would have been a list comparing the top Correlational Coefficients with regards to the data sets. After creating the list, we would have chosen a couple algorithms as the best fit algorithms for our project. If we implemented the previous functionality we would have chosen a couple algorithms as the best fit, we would have tested them with actual ECG data and compared the results from each of them. We would have ensured that our algorithm does not distort potentially useful information. It also needs to be the best fit for the ECG signal, so we would have compared each of the results to find the best one. We would have also compared it using multiple different ECG signals. Since this is an adaptive filter we want to make sure the filter works regardless of the type of ECG. However, since we did not make more than one filter this feature was unnecessary. If the filter we used is the best for certain types, but not others, we would have attempted to programmatically figure out which filter works the best for each type and select it during run-time. However, instead of doing this, we used a well-known filter that has been used in the past to deliver good results. This filter is the Least Mean Squares Filter. One other important component with regards to the filters; is that the filter needs to be able to run in real-time with regards to the inputted data. We could have a great algorithm, but; if it is unable to run in time to be useful, we will need to use a different filter. It is vitally important to test the filters at run-time and we plan on testing most of them prior to the analysis. We will, in real-time measure the filters against the inputted data and view the results. This will hopefully decrease errors with regards to our filter and allow us to have very useful data. One of the alternatives in regards to a filter not running fast enough is to improve the hardware that we used. Right now we believe our data to be processed fast enough but future needs may require more speed. One way to improve the hardware, but would require some change in the software as well is to have multiple processors running in parallel. Unfortunately this will either cost more or be impossible due to the current design. Another alternative is to improve the speed of the algorithm we are using. If we find a method to improve the speed of the algorithm we can often do more processing with less power. This is probably the best approach and will most likely give us the results we are hoping for. However, since we are using the CMSIS LMS algorithm this would be rather difficult to do. As such, this may be impossible and if it is, we only have one 51

58 alternative. That alternative is to use a different algorithm as the current algorithm does not work given our time constraints. As such the project will utilize a variety of methods to ensure accurate and meaningful results. We coded the tests and project in Embedded C++ and MATLAB as a way to lower the risk with regards to the project. Doing so took more time upfront but, ensured that we were able to finish the project regardless of whether or not we could use MATLAB. Unfortunately, MATLAB is a little more specific with regards to what Microprocessors we can use and may not allow us to customize things as much as we would like to on this project. Luckily we took more time upfront and since we were unable to use MATLAB; this design decision was really smart. After we have filtered the results, we will need to output the data to a file. And we will be creating a class with regards to saving the files. These classes will manage all of the files we need to write. 7.3 ECG Filtering Hardware The Adaptive ECG Filter is constructed on a PCB (Printed Circuit Board) that consists of combination of multiple hardware components. The flow of data within the adaptive ECG filter begins with the analog front end that amplifies the electrode input and provides patient protection with a combination of operational amplifiers, resistors, diodes, and capacitors. The microprocessor performs the analog to digital conversion, runs adaptive filtering, and outputs a digital signal to both a USB port and a digital to analog converter. The USB port outputs a digital signal to a computer that has software for measuring, displaying, and recording an ECG signal. The digital to analog converter converts the signal to analog so that any ECG machine can connect to the filter. This design allows the adaptive ECG filter to operate with a computer that has specially designed software or with any existing ECG equipment. Below in figure 28 is a example of the functionality. 52

59 Figure 28: Diagram for hardware functionality Printed Circuit Board The PCB (Printed Circuit Board) serves as the foundation of the Adaptive ECG filter. A printed circuit board consists of sheets of copper that are etched to provide electrically conductive paths. The sheets of copper are then laminated to a nonconductive material and may be laminated in multiple layers to provide additional conductive paths. The process of manufacturing PCBs can either be performed at home for simple PCBs or ordered from a manufacturer for more complicated PCBs. Once a PCB is manufactured electrical components are connected to pads which are connected to the conductive paths through a process known as soldering. Once the PCB is built it will have electrical components attached to it using a method known as soldering. Soldering is the process of connecting two components to each other using a metal that has a lower melting point then the components. The two primary types of soldering are through hole and surface mount. The circuit board for the filter uses pads, therefore it is surface mount and the components are attached using a method known as reflow soldering. The tools required to reflow solder are solder paste and a reflow oven. The reflow soldering processor consists of attaching solder paste to a component and then attaching it to the pad on the PCB. After all the components are attached to the board it is placed in a reflow oven and the solder paste is melted. Once the paste has melted the board is cooled off and ready to be used PCB Design The Adaptive ECG Hardware consists of a 6 layer PCB (Printed Circuit Board). The board contains 417 components and measures 3.7 x 5.4 inches. The device is powered by a 5V external battery. The Circuit was designed using Cadence OrCAD and was went through a Quality Assurance review at Philips. The Quality Assurance review consisted of 2 electrical engineers reviewing the design for incorrectly connected components, ensuring that correct component values were used, and reviewing datasheets to ensure correct components were selected. After the design was approved it was transferred onto a PCB using Cadence Allegro. Once the board layout was completed the Gerber file was sent to a PCB manufacturer that printed the circuit board with a 5 day turnaround. Once the PCB arrived components were cataloged and send with the PCB to a PCB assembly house that populated the board for us. Figure 29 is a schematic of the PCB. 53

60 54 Figure 29: PCB Schematic of adaptive ECG Filter The Device has 4 inputs that come from the ECG Electrodes attached to a patient s body and 6 inputs that come from a gradient antenna. The 6 inputs are then reduced to three signals using a differential amplifier. The device then filters, amplifies, and biases these signals while providing ESD/Defibrillation protection for the patient and the board. After the front end signal processing is completed the signals are received by the ARM Cortex M4 processor that converts the signals to digital and performs the digital filtering process. The processor then transmits the results of the filtering to an attached computer via a USB port PCB Isolation Isolation is required on the PCB to prevent the high frequency noise caused by the digital input from coupling with the analog ECG input and corrupting the ECG signal. Isolation is achieved by separating the analog and digital power supplies and ground planes with a capacitor-input filter commonly referred to as a CLC pi filter. The filter works by shunting noise to the digital ground before the power reaches the analog ground Power Distribution The PCB consists of components that need both analog and digital power sources of different values. This requirement is achieved through the use of linear voltage regulators and a voltage reference. The PCB is powered by a battery that provides

61 5VDC. The 5VDC is connected to the CLC pi filter which provides a 5VA output. Both the 5VDC and 5VA are connected to linear voltage regulators to step down their voltages to accommodate the needs of various components. A voltage reference is also connected to the 3.3VA supply to prevent any variation in supply voltage to the analog to digital converter Analog Front End The analog front end takes the data received from the electrodes and provides patient protection while simultaneously amplifying and filtering the signal. The patient protection aspect of the filter is important from both a safety and regulatory viewpoint. In order for the filter operate in a medical environment the filter must meet the requirements established by the FDA that requires that all electronic devices provide patient protection. The analog front end provides patient protection by design. The method of construction for an analog front we would like to attempt uses a combination of resistors, operational amplifiers, diodes, and capacitors. The front end is designed with diodes and possibly fuses integrated into the circuit to prevent the flow of current toward the patient. The amplification and filtering of the signal will be performed with a Butterworth filter ESD/Defibrillation Protection The adaptive ECG Filter is designed to be used on a person in a clinical environment and because of this, it must be able to withstand an electrical impulse from an Automated External Defibrillator. The device satisfies this requirement by providing ESD/Deliberation protection with a combination of diodes and glass discharge tubes. Clamping diodes are connected after the ECG input and before the first OPAMP to short any currents outside the range of ±3.3V to provide basic protection. There is also a Littelfuse glass discharge tube connected after each ECG input to short the current in the event that an Automated External Defibrillator is used Analog Filtering The device performs front end filtering to eliminate as much noise as possible before the analog signal is converted into a digital signal. The Butterworth filter was chosen to be part of the front end design because of the characteristics of its transfer function. Butterworth filters are known as maximally flat because they have a consistent gain until they reach their cutoff frequency. Another defining characteristic of Butterworth filters are their ability to decrease the width of the transition phase which is also known as roll-off. The transition phase is the range of frequencies between the pass-band and stop-band that can transmit through the filter with a decreasing gain. A smaller transition band will give a sharper transition from pass-band to stop-band. The sharp transition is obtained by increasing the order of the filter. With each order the filter increases, the slope of the gain in the transition band is changed by 20dB/decade or 8dB/octave. For example, a first order Butterworth filter will have a slope of -20dB/decade in the 55

62 transition band while a second order filter will have a slope of -40dB/decade. An example of both the frequency response and magnitude response of a first order Butterworth filter can be observed below. It should be noted that the points on the magnitude response are labeled to show a change of -20dB over the period of one decade. The first point is located at the frequency of 10^5 radians per second with a magnitude of -14.2dB. The second point is located at the frequency of 10^6 radians per second with a magnitude of about -34.2dB. By subtracting from we see that the change is -20 db and the period of this change was over one decade. Figure 30: Bode Diagram of First Order Butterworth Filter The final design of the analog front end filtering is performed using a 3rd order unity gain Sallen-Key filter, a type of Butterworth Filter, with a cutoff frequency of approximately 55,000 rad/s or 9kHz. 9kHz was the chosen cutoff frequency because all signals above that frequency are unwanted noise and it falls within the Nyquist rate of 250ksps. The frequency response of the Sallen-Key filter can be observed in the figure

63 57 Figure 31: Frequency Response of Sallen Key Filter Op-Amp Biasing and Amplification In order for the analog to digital converter to work properly, the Op-Amp going into the processor is biased. The biasing is achieved by applying a 5V source and using a voltage divider with 2 resistors to step down the voltage to 1.2V. The same voltage divider process is used to reduce the input signal from the ECG from ±3.3V to ±0.55V. These two signals are added together and go into the Op-Amp with a value between 0.65V and 1.75V. The Op-Amp is configured to have a gain of 1.5 which amplifies the signal values to be between 0.975V and 2.625V. The signal with a range between 0.975V and 2.625V is then transmitted to the processor for analog to digital conversion Analog to Digital Converter An analog to digital converter converts analog signals to digital signals. Analog signals are continuous time varying signals normally generated by natural phenomena. Analog signals have an infinite number of values and are much more difficult to process than a digital. When analog signals are transmitted, they contain noise that distorts the signal and the signal progressively gets worse over

64 time. This noise poses a problem because after the noise is introduced into a signal, the original signal cannot be recovered. Digital signals are discrete time invariant signals that have finite values. Digital signals are much easier to process than analog signals because the signals are much less to susceptible to interference and because they have finite values. Digital signals are transmitted with 2 voltage levels representing 1 (on) and 0 (off). Using binary, the 1s and 0s can be used to represent any number. An analog signal that has a value of 2345 volts at a certain time can be represented with a digital signal in binary by The three primary types of analog to digital converters are Flash, Delta-Sigma and SAR (successive approximation register). Each type of converter has an advantage and disadvantage over the other. A Flash analog to digital converter is a high speed converter with a lower accuracy. A Delta-Sigma analog to digital converter is best for medium speed and medium accuracy. A SAR analog to digital converter is best for high accuracy but slower than the other two types. The speed and accuracy variations amongst analog to digital converter are caused by their differences in design. A Flash analog to digital convert uses a high number of comparators to measure an analog value and convert it. When it receives an analog signal the flash converter compares the signal against a preset number of comparators with defined values that are turned on when the values are matched. This system uses a very high number of comparators because it requires 2 n 1 comparators for a resolution of n-bits. For example a ten bit analog to digital converter requires 1023 comparators. A block diagram of the flash architecture can be observed below in figure Figure 32: Flash Analog to Digital Signal

65 A Delta-Sigma analog to digital converter works completely differently than a Flash converter. A Delta-Sigma converter utilizes a one bit digital to analog converter, a comparator, and an integrator. The Delta-Sigma converter receives an analog signal, and subtracts the existing value from the single bit digital to analog converter. The new value produced is then integrated and converted into a digital value in the comparator. The output of the comparator is used to calculate the next input value as well as sent to the decimator. The decimator then takes the values it receives and produces an output that will go to the signal processor. A block diagram of the Delta Sigma architecture can be observed below in figure 33. Figure 33: Delta Sigma Architecture The SAR (successive approximation register) is slower than the two other types of converters but is much more accurate. The SAR based method works by setting the most significant bit on its internal register system to 1 and then comparing that value to the analog value. If the analog value is greater the comparator then sets the next register to 1 and compares again. If the analog value is less, the comparator sets the most significant bit to 0 and sets the next bit to 1 and compares again. The Comparator performs this operation until the register value matches the analog value. Once the values are matched the converter sends the digital signal out to be processed. A block diagram of the SAR architecture can be observed below in figure

66 Texas Instruments ADS8568 Figure 34: SAR Architecture One option for the analog to digital converter is a Texas Instruments ADS8568. The ADS8568 is a 16 bit SAR based analog to digital converter that has a maximum data rate of 510kSPS/ch (samples per second per channel). The ADS8568 also supports a sleep mode which is important because the Adaptive ECG Filter is designed to work on battery power. Having 16 bits will give 65,536 different values and allow for a high resolution signal. A block diagram of the Texas Instruments ADS8568 can be observed below in figure Figure 35: Texas Instruments ADS8568

67 Texas Instruments ADS 1274 An alternative analog to digital converter we are considering is the Texas Instruments ADS1274. The ADS1274 is a 24 bit analog to digital converter that supports simultaneous sampling on four separate channels. The ADS1274 has a bandwidth of 70 khz, 111dB signal-noise-ratio, and uses only 35mW to operate. The ADS1274 has an advantage over the ADS8568 because it supports sampling on four difference channels. Having 4 simultaneous sampling channels would allow the converter to take up less space on the circuit board and use less power. The ADS8569 is faster than the ADS1274. The ADS8568 has a sampling rate of 510kSPS/ch while the ADS1274 can only sample at 144kSPS/ch ARM Cortex M4 ADC The ARM Cortex M4 processor has an integrated delta-sigma analog to digital converter. The processor contains two identical converter modules that share the same 24 analog input channels. Each ADC module operates independently, supports up to 1MSPS sampling rate with 12 bit precision, and operates on a 16 MHz clock rate. The main advantage of this converter is that it operates using a delta-sigma encoding method. The delta-sigma method is preferred because it balances speed with precision. Other conversion methods such as SAR (successive approximation register) or Flash tend to favor either speed or precision over the other. The ADC collects sample data by using a programmable sequence based approach. A sample sequence is a series of consecutive samples that allows the ADC to sample multiple times at once. There are 4 different types of sequencers. Sequence 3 allows for 1 sample and a FIFO size of 1. Sequence 2 and 1 allows for 4 samples and a FIFO size of 4. Sequence 0 allows for 8 samples and a FIFO size of 8. The sequencers can be applied on multiple pins or on the same pin. Once the sample has been collected the result is stored in a FIFO. The FIFO are simple circular buffers and each FIFO entry is a 32 bit word, with the lower 12 bits containing the data. When a sequence completes the resulting data can be retrieved from the FIFO and then transferred into main program memory. The data retrieved from the ADC depends on how many bits of resolution the ADC has, described by Equation 1. The ADC has 12 bits of resolution so the value retrieved will be an integer from 0 to Converting this ADC code into the voltage value it represents is done through Equation 2. V REFP is the positive reference voltage and V REFN is the negative reference voltage. In our case we are using the internal reference voltage of 3.3V and ground for the negative reference voltage. Analog input voltages above 3.3V saturate at 4096 while those below 0V saturate at bits of resolution 0 ADC code 2 Equation 1: Range of ADC code

68 V ADC = V REFP V REFN 4096 ADC code Equation 2: Convert ADC code to voltage The device has 3 inputs for ECG signals and 3 inputs for gradient signals which gives a total of 6 different signals to run through the ADC. The sample sequence 0 is able to convert these 6 signals all at once into a digital value with no speed reduction. To achieve enough resolution on the ECG signals, each signal must be sampled at least 500 MSPS. For a 50 khz input signal that is 10 samples per period. Each sequence sample is triggered by a processor interrupt, waits for conversion to complete, copies data from FIFO into main memory, and then repeats continuously. This analog to digital converter was chosen for our project because it was already integrated onto the Integrated Circuit of the microprocessor and met the requirements to sample the input signal. This makes is much easier to use than the previous two external analog to digital converters. In order to use the previous two, a communication protocol like SPI (serial peripheral interface) would have to be programmed in order to communicate with them. By going with the integrated ADC, it speeds up our development time into getting a solution to work Microcontroller The heart of the Adaptive ECG filter is the embedded microprocessor. The microprocessor performs an arithmetical operation on the input received from the ECG electrodes and outputs the result of the operation. Microprocessors are small low power devices used in electronics such as cellular phones, computers, tablet computers, and digital cameras. The microprocessor we choose must be able to handle the operations it is required to perform. Some averaging algorithms such as the Least Mean Square algorithm require the processor to store data in groups in order to analyze the largest sample possible. The higher processing power is also required for the Least Mean Square algorithm. The Least Mean Square algorithm requires the processor to process a large amount of data in order to be maximally effective. If the processor were to be too slow the processor would lag and cause memory problems as well as not output real time data ARM Cortex A Series The ARM Cortex A series is one of the more powerful series of microprocessors that ARM produces. The ARM Cortex A series is designed to execute operating systems and operate with applications such as televisions, smartphones, table computers, and satellite receivers. The Cortex A series includes the Cortex-A57, Cortex-A53, Cortex-A15, Cortex-A12, Cortex-A9, Cortex-A8, AND Cortex-A7. The ARM Cortex-A57 is the most powerful processor of the series and can be found in 62

69 devices such as smartphones that require a lot of processing power. The A57 can support up to 64 bit instructions and uses the ARMv8-A architecture. The Cortex- A5 is the least powerful processor in the series and it is still capable of supplying internet to devices. The Cortex A5 is capable of operating at above 700 MHz and is the smallest and most power efficient of the A series of processor. The Cortex- A5 uses the ARMv7-A architecture and is also capable of supporting 64 bit instructions. During this stage in the development process we believe that of the ARM processors, the A series of processor should be our third choice. We believe that the A series offers much more power than we will require and a less expensive processor will better serve our purpose. The processor in the Cortex A series that we will use if we have no other viable options is the Cortex-A5. The Cortex-A5 appears to be the best option because it is the most power efficient and still is extremely powerful. An image of the Cortex A5 Processor can be observed below in figure ARM Cortex R Series 63 Figure 36: Cortex A5 The ARM Cortex R series is a high performance processor series that is more cost effective than the A series. The ARM Cortex R series is designed to provide functionality to embedded systems where price is an important factor. The Cortex R series is designed to work with and can be found in cellular phones, printers, Blue-Ray players, and automotive system such as airbags and dashboards. The Cortex R series includes the Cortex-R7, Cortex-R5, and Cortex-R4. The Cortex- R7 is the most powerful of the series with a clock frequency above 1GHz. The Cortex-R7 uses the ARMv7-R architecture and is also capable of supporting 32 bit instructions. The least powerful microprocessor of the series is the ARM Cortex- R4. The Cortex-R4 is often used for devices such as wireless controllers and electronic control units in vehicles. The Cortex-R4 has a maximum clock

70 frequency above 600MHz and also uses the ARMv7-R architecture that supports 32bit instructions. The ARM Cortex R4 is the backup microprocessor we plan on using if we have problems with the Cortex M4. We choose the Cortex-R4 to be out alternate because we believe it has enough processing power to perform the signal processing required while also being the most power efficient processor in the ARM Cortex R series. An image of the ARM Cortex-R4 can be observed below in figure ARM Cortex M Series Figure 37: Cortex R4 The microprocessor we plan on using in the Adaptive ECG filter is the ARM Cortex- M4. The M4 is the most powerful member of the M series of processors which consists of the M4, M3, M1, M0+, and M0. The M series of ARM processors is designed to have low power consumption and a sleep mode to reduce power consumption during times when power is not needed. The ARM M series is also supported by the Embedded Coder function in MATLAB. The Embedded Coder allows the M-series of processors to be programmed from a C+ code that is generated from a MATLAB program. The processors support 8 bit processing on the lower end Cortex M0 and up to 32 bit processing on the Cortex M4.The Cortex M0 is the first in the line of processors and is recommended for simplistic operations while the Cortex M4 is the last in the line and is recommended for operations such as digital signal control. The ARM Cortex M4 is the least energy efficient of the M series of processors but is also the most powerful. The focus of the Adaptive ECG Filter at this point in time is to perform complex filtering operations therefore power consumption is not the primary focus and the Cortex M4 is the microprocessor for the system. 64

71 The ARM Cortex M4 uses RISC (Reduced Instruction Set Computing) Architecture. The RISC architecture works by using simple instructions that take only one clock to execute. Because the RISC architecture requires many simple instructions it takes more space it memory for the program it is running. The memory disadvantage of the RISC architecture is offset by the pipelining advantage it provides by performing one operation for each clock cycle The ARM Cortex M4 also supports Embedded C++ which allowed an object oriented approach to the problem and the ability to change things quickly. In standard C a more procedural approach is required and as such that would have severely complicated the project.. An image of the ARM Cortex-M4 can be observed below in figure 38. Figure 38: Cortex M4 There are multiple different versions of the ARM Cortex M4 MCU available. The one we choose is the TM4C123GH6PGE by Texas Instruments. We choose the Tiva C Series Development Board as the testing which contains this MCU. The important specifications are listed below. Specifications of TM4C123GH6PGE 80 MHz CPU clock 105 GPIO pins 256 KB Flash memory size Two ADC modules Four SSI modules 65

72 Single-precision Floating Point Unit (FPU) Digital to Analog Converter A digital to analog converter takes a digital signal and converts it into an analog signal. We choose to use the Analog Devices AD5640 digital to analog converter in our final design. The AD56XX series are low power single channel DAC. They use a 3-wire serial interface that operates at clock rates up to 30 MHz and is compatible with SPI, QSPI, and MICROWIRE. Initially we chose the AD5660 for our DAC. But when we were integrating the hardware with the software, we realized that it would not work very easily because the AD5660 requires a 24-bit input register in order to trigger a conversion. We choose to send data to the DAC using the SPI communication protocol using the SSI modules on the ARM Cortex M4. By default SSI on the microcontroller can send a max of 16-bits at once. This cannot fill up the input register of the AD5660. We then changed the design to be the AD5640. This works with the SSI module on the ARM Cortex M4 because it matches the specs match. A comparison of the difference of specs is listed in the table below. AD5660 AD5640 AD5620 Conversion Resolution 16-bit 14-bit 12-bit Input Shift Register 24-bit 16-bit 16-bit Figure 39 shows the proper write sequence for the DAC in order to trigger of conversion. The 3 wires shown are labeled SCLK, SYNC, and DIN. SCLK is the clock rate. SYNC determines the start and stop of a conversion. When SYNC is high, no conversion is done. When SYNC goes to low, a conversion happens. DIN are the digital data that gets passed to the DAC. This data must start sending when SYNC is low in order for them to be read correctly and stop sending when SYNC goes high. The correct write sequence is shown on the right side of Figure 39. Figure 39: AD56XX Series Write Sequence 66

73 Figure 40 shows how the data read in fits into the Input Shift Register. The data sent to the AD5640 should be 14-bits long, but the last two most significant bits designate the operating mode. These bits should be set to 0 and 0, indicating normal operating mode. 7.4 ECG Filtering Software Figure 40: AD5640 Register Contents As we will be receiving data from an Analog to Digital Converter, we needed to have an OnReceive function. This function will receive the data and will notify the filter to process it. This required a Receiver class which will take a filter as a variable so it can process the information. We utilized an publish and subscribe system that published data to any listeners and this allowed functions to be notified whenever we receive new data. Essentially whenever the OnReceive function is called, the OnReceive function would have published data to the topic manager. The topic manager would have then updated all subscribers to the specified topic. The topics would have been created as strings and would have been notified on receipt of data. The topic would also have contained a variable representing the type of object to be sent and received. A subscriber can only receive specific data types and in an effort to make the program more generic and include error checking we will be checking what type is defined inside of the problem. Essentially, when the Publisher creates a topic to publish to, and the object sent is different than what is expect an error will be thrown. This will help remove some hard to find errors and will make error checking simpler. However, due to the requirements of the embedded device we chose and the simplicity of our project; this feature caused a ton of errors and while we had a working version in Visual Studio it did not correlate to a working version on our embedded device which had limited memory. As such, instead of utilizing a topic manager, the publishers knew who the subscribers were and directly published to them. The subscribers also knew who the publishers were and obtained data directly from the necessary components. One such example of a Subscriber was the Analog to Digital Converter that received data from the individual pins on the Microprocessor. 67

74 The Topic Manager below would have been a singleton that could have been accessed at any part of the program. This would have been ensured to be thread safe by putting in Mutex s around any data that could be modified at the same time by multiple threads. This would have helped us make sure our program has less errors and that it is running correctly. Other things that the publisher/subscribe system would allow us to do is receive networking events in the case that we need to have a network set up. The publish/subscribe system simply makes certain tasks easier and will help our project immensely. Below in figure 41 is displayed a class diagram of the publish/subscribe system. However due to changes in the design we implemented a much simpler approach that removed the need for a topic an topic manager altogether. 68 Figure 41: Publish/Subscribe Class Diagram Inside of the Publish/Subscribe system, we would have a topic that would have been labeled as ECG.OnReceive, this would have been the topic that is called whenever OnReceive occurs. We would have received a lot of data from the adaptive filter and this would have been necessary. As the publisher subscribe system needs to be updated as soon as it receives data, this program would have been running in an asynchronous format. Whenever something changes, the necessary parameters get updated. This differs from a Synchronous connection because; in a Synchronous connection the processes will occur at intervals that are predefined in the program as opposed to when it receives data. However, due to the program requirements a synchronous system made more sense. We receive the data, then immediately process it. As we are constantly sent data and need to do things immediately, waiting to receive data didn t make

75 sense. As such, the system was not written in an Asynchronous manner and did not require the complexities of the Publish/Subscribe system that was presented previously. As there will likely be multiple sensors that we are utilizing thought about running each of the separate sensors on a different thread. We thought doing so would allow all of the graphs to update at the same time, and the graphs will be updated by an invalidate command that our program calls whenever the graphs are changed. Each graph will not rely upon other graphs, so threading issues will not be present at this segment of the program. However, running it in multiple threads did not make sense as we could receive all six data points from the sensors at the same time. Therefore, it was simpler and more efficient to run the application as a single-threaded process. As an effort to make the publish/subscribe system easier to use, below in figure 42 is displayed a use case diagram showcasing how the publish/subscribe system would have worked. Figure 42: Publish/Subscribe Use Case Diagram 69

76 8 Design Summary of Hardware and Software 8.1 Software High Level Software Design The purpose of high level software design, also called software architecture, is to analyze and consider all requirements for a software and to define a structure to fulfill those requirements. Non-functional requirements need to be considered, such as scalability, portability and maintainability. A high level design describes the major components in a system and how they interact with one another. This can be further refined into a low level design. The first step in designing software is to define the architecture by outlining the components and layers of the software. The following diagram shows the high level design of our adaptive ECG filtering project from the input, to adaptive filtering, to deployment on the embedded board. It shows the relationships of each component and the order in which the system will flow. An important note is that this block diagram includes both the Simulink model and the C++ adaptive filtering methods, located in the diagram on the section titled, Adaptive DSP using Two Methods. We will be identifying which method has the best performance and the most feasibility. The final project may not include one or the other, or it could be a combination of both methods. The software system starts off with three different kinds of input, all of which are digital. The first input is real-time ECG signals directly in the environment testing of an MRI while integrated with the rest of our hardware system. This signal will be used in the final stages of testing to ensure our product using real data. This signal will also be displayed onto a GUI tablet, for comparison and presentation purposes. The second input is the ECG signal taken from a database online. These are recordings of real ECG signals. These might contain noise and if they don t we are going to insert our own simulated noise into the signal. The last form of input is generating a digital ECG from a set of parameters. This will be the ideal case for an ECG signal. The other two forms of input will likely not be ideal and contain differences on each heartbeat. The adaptive DSP filtering will be done in two methods, using the model-based design in Simulink and by coding them ourselves using C++. The model-based design will be used as a test bed for different adaptive filtering algorithms. The MATLAB and DSP System Toolbox components are able to be integrated into the Simulink model. The Embedded Coder is able to generate code for the embedded device from the Simulink model. This method relies on the Embedded Coder generated fast code for a supported hardware device. Once we have a system of filtering that works, we will code it up in C++. This method should be able to apply 70

77 to any type of hardware device. By using these two methods we need to compare which performs the fastest. Also the output needs to be verified against a known solution, the original simulated ECG signal. This is why we start with an original ECG signal and then apply noise to it. The performance comparison and verification can both be visualized to show the results. The configuration file component will store the different settings used to do filtering. This will allow us to quickly test and modify different configurations CMSIS CMSIS stands for Cortex Microcontroller Software Interface Standard. CMSIS is used to allow Cortex-M silicon vendor products to migrate over to other products without a large change in source code. The main proponent to using CMSIS is the ability for software re-use. The CMSIS libraries are optimized with regards to the Cortex M4 processor. It does this by using the SIMD instruction set that the Cortex M4 has. Many benefits were found by using the CMSIS libraries. The primary benefit being the Least Mean Square algorithm include within it. Inside the CMSIS libraries is an optimized Least Mean Square library. The Least Mean Square library has been implemented for 16 bit and 32 bit systems. The 32- bit float system was chosen over the 16 bit integer and 32-bit integer systems due to us not needing to scale coefficients or having to deal with Overflow and Saturation. Also, our system while needing a decrease in orders was usable by our microcontroller despite the changes. The implementation of the Least Mean Squares Filter with CMSIS required an initialization; in which the coefficients can be pre-weighted to a selected value. After initialization, the coefficients will converge to a final results. As such, the Least Mean Square Filter is required to remember multiple data points for obtaining the filtered signal. Using the CMSIS library will hopefully allow other research teams to further our current development and continue to improve the quality received from ECG Signals Microprocessor Implementation The implementation of the Least Mean Squares Filter was done using the ARM Cortex CMSIS library and embedded C++. Embedded C++ was chosen to allow a more object oriented approach than straight C. This allows the use of three instances of the filter without a lot of extra code. As such, if more signals were inputted this project would be able to filter more of them at once. The filter is attached to an Interface, called IFilter. This interface has a filter attached to it that processes the data. Performing the filtration in this manner 71

78 allows changes to easily be done between different filters or to add changes on top of the existing system. The architecture of the system utilized a Top-Down approach so that the underlying code importing data, the code filtering the data and the code sending the data were separated. One such way this was done was with a Publish/Subscribe system. The Publish/Subscribe System currently only sends data to MATLAB, but, it was written in such a way to allow it to send data to any waiting programs that the device has access to. This will allow the program to also send the data by way of a digital to Analog device. This will allow further processing of the signal and the display in legacy devices that Philips currently has Publish/Subscribe A publish/subscribe system was implemented to allow the sending of data to multiple publishers. The publish/subscribe system does not contain a Topic Manager and as such requires the publishers to know about the subscribers. The subscribers are listed as objects inside the publishers. Essentially, a publisher will contain a MATLAB subscriber which when passed data will send it to MATLAB and any other subscribers attached. Another subscriber is a Digital to Analog subscriber. Essentially creating an analog signal from our filtered data. To implement the Publish/Subscribe system correctly, a system was initially implemented in Visual Studio C++ prior to receiving the boards that used a Topic Manager. However, this system was not up to the task for the Embedded Device and was later scrapped for a simpler model that took up less memory. Figure 43: Class Diagram for Publish/Subscribe Figure 43 the modified Publish/Subscribe system. Utilizing this method allowed the program to work. However, the subscriber list was not implemented as a list 72

79 and they were simply declared within the publish class to ensure that memory allocation happened prior to runtime Serial Synchronous Interface After the input data has been filtered, the output needs to be sent to the digital to analog converter. The DAC is an external IC, so to communicate with it, SSI (serial synchronous interface) was used. SSI also stands for SPI (serial peripheral interface) which they can be used interchangeable. The TM4C123GH6PGE comes with 4 different SSI modules. One module is used for each DAC. Each module can send a programmable data frame size from 4 and 16 bits, can operate in either master or slave operation, and can be configured into three different types of frame formats, MICROWIRE, Freescale SPI, and Texas Instruments Synchronous Serial Interface. The MICROWIRE and Freescale SPI are pretty similar where the FSS pin is active low for the duration of frame transfer. The TI SSI has the FSS pin pulsed for one serial clock period prior to frame transmission. It is important for the FSS to be pulsed while high when no conversion is occurring because the DAC needs the clock to be pulsed in order to know when the FSS goes low to start the conversion. The only frame format that supports on our MCU is the TI SSI. Figure 44 shows the timing diagram for this mode. Figure 44: Texas Instruments SSI Timing Diagram MATLAB Implementation The MATLAB program was built in a modular way to allow multiple graphs to be created. In this project a total of nine graphs were displayed, but it is very simple to decrease or increase the number of graphs displayed within the MATLAB program. Inside the program, data is received in real time and as such; results must also be displayed in real time. This displays the filtration of the objects immediately and requires a limit to the amount of data objects that can be shown. The data will show a set number of points, currently thirty points were chosen as it seemed that thirty points gave an accurate representation of the data. The number of points is very easy to change and can be used to display more or less data at once. 73

80 There are three components to the MATLAB program, the COM port connection, the Graphing of the Plots and the data stored in the plots. The COM port connection needed to be set to the same rate as the UART in the Microprocessor to receive data at the correct rates. The COM port was essentially used to receive the data to plot the different values. One of the problems that occurred within the data sending of the values was an invalid header file. The program would send correct data initially to MATLAB if MATLAB was started prior to the device running. However, if the device was already running and it sent data to MATLAB, MATLAB would receive data in the incorrect order and would display the results in an incorrect graph. This solution was remedied by forcing the application to send the graphs position twice prior to plotting Graphical User Interface As part of the extended scope for our project we will build a graphical user interface (GUI) on a tablet. After we have deployed our filtering system onto the system, we need a way to verify the results without using any external software. This can be done by displaying the unfiltered and filtered ECG at the same time onto another device like a tablet. This will serve as an easy way to showcase our project to the senior design fair and to the committee review. Philips already has a device that displays the ECG and other signals called the Invivo Expression, as shown by figure

81 Figure 45: Invivo Expression MRI Monitor (Permission from Philips) This is a proprietary device that we may, or may not have access to use with our project. The Invivo Expression is designed to withstand demanding environments with strong magnetic fields. It can displays two ECG, SpO2, EtCO2, and two IBP signals on the main window some of which are transmitted wirelessly to the machine. This has so many features that we do not need and it doesn t do a good job of displaying the results of our project. What we need is to be able to display the results so that we can compare the before and after ECG signals to prove that our filtering design works. Our project is a proof of concept and so we need to be able to display our results in an organized way. We think a tablet is a good device to display our results on because it is portable and has a touch screen. The touch screen makes it easier to use by being able to select options without the use of a mouse and keyboard. By being portable, it can be easily moved around. This is good for a hospital environment as the patients get moved around and the monitoring device always 75

82 needs to be with them. For our needs, having a portable device means that it is easy to showcase our project during senior design and to the committee board who will be reviewing our project. The tablet will either run Windows 8 or Android as its operating system (OS). The tablet will receive output from our embedded device in a USB format, which would contain all the information about the ECG signals interleaved. It is unclear at this time whether the signal we will receive will be in analog or digital form. This is because we are not sure of how to interface an analog signal with a tablet. But our final project will output an analog signal by having a digital to analog converter at the end. Figure 46 is a clear representation our prototype. 76 Figure 46: GUI Prototype Our GUI will be composed of two main sections. The left section being the ECG display and the right section being the stat and toolbox. The left section will support up to 4 different ECG signals to be displayed at once. When monitoring a patient s ECG you put multiple electrodes on them and each electrode creates its own ECG. Our project will deal with a maximum of 4 different ECG signals and then filter each signal independently. On the GUI we will display these signals all at once which makes it easy to see the status of the patient. For each signal, we will display the raw ECG measured by the electrode and the filtered ECG run through our filters. By showing both of them it allows an easy demonstration of a proof of concept for our project. You will easily be able to see whether the filtering is doing its job or not. A label will be present for each ECG signal, filtered and non-filtered. The label will consist of the placement of the electrode on the patient and identify which ECG is filtered and non-filtered. It is important to note the placement of the

83 electrode because that may explain differences in the ECG. For example if an electrode is placed at the patient s ankle, the ECG signal should be weaker due to being further from the heart. The right section of this device will consist of a beats per second (BPS) display, a layout dropdown menu, and a dropdown menu for the type of filter being used. The layout section will show how many ECG signals are being displayed currently and then have a dropdown to be able to change the amount. The number of ECG signals that can be displayed at one time will either be 1, 2, 3, or 4. The reason why this is here is because 4 ECG signals might not necessarily be used at one time, and so reducing them to the amount that you have will make it easier to see the other ECG signals. This can be changed by selecting the arrow to the left of the 4. The user will also be able to view what type of filter is currently being used on the ECG signal. This allows us to view the performance of the ECG based on what type of filter is being used. The user would be able to change the filter being used by a dropdown menu, selected by the arrow to the left of the current filter type. The filters that the user can select are preprogrammed by us. The filter s names will either be composed of one filter where the name is just the name of the filter, or be a combination of filters where the name would be something like, custom1, custom2, custom3 Additional features that may be added if time allows is the ability of the user to program their own filters. This would be done in either a block diagram format, a code development environment, or by uploading their code. The code would then be sent to the embedded device on which the filtering is being done. The coefficients for the filter would be reset. The new filtered ECG would clear the previous filtered ECG and start fresh from the left side. Another feature would be able to visualize the coefficients of the filters. The filters work by constantly updating the filter coefficients to be able to account for various noise levels. This probably wouldn t be very useful for a user, but for us it would be interesting to see how these coefficients are modified as it filters. 8.2 Detailed Software Design Detailed software design, also called low-level design, details with how the software is going to be built and representing the relationships among modules. Class diagrams are used to detail the required construction and relations between classes. A class is defined to have a distinct type, it can be instantiated upon itself which is known as objects. A class contains data fields that must be associated with state variables which belong to the class or instances of the class. A class has behavior by its methods, which enables the class to interact with other classes. Figure 47 below details the class diagram that was used for the construction of our Adaptive ECG Filtering project. 77

84 8.3 Hardware 78 Figure 47: Class Diagram of Software Design The Adaptive ECG Filter hardware was designed in stages. The first stage is focused around allowing the microprocessor to be programmed. The second stage was integrating the analog to digital converter into the microprocessor, designing the analog front end, and integrating the analog front end into the analog to digital converter. The third stage was designing the digital to analog converter and designing the USB port. The final design stage was designing and assembling the Printed Circuit Board. The stage system is designed with the most important design steps being performed in the beginning of the process. We will create a Gerber file for each design stage so that the final stage will be primarily integrating all of the stages together. The goal of the first stage of the design process is to get a program loaded on the microprocessor. We believe this is the most important step because the microprocessor performs the actual filtering and it is the heart of the system. The program we will implement has the same power demands as the adaptive filter to ensure the processor can handle the program we write. If we were to have encountered any problems with the microprocessor we wanted to encounter them early in the design process because every other component is built around it. If we had to change the microprocessor later in the design process we would have needed to redesign the PCB, analog to digital converter, digital to analog converter, and power supply. To initially program the microprocessor we used a prefabricated experimental board. The experimental board allowed us test the microprocessor without having to dedicate a significant amount of time building unnecessary components. Also, having an experimental board allowed the microprocessor to be tested and optimized with sample ECG signals while the hardware is being designed and constructed. After we ensured that the

85 microprocessor was compatible with our design we will move onto the second step of the design. The second design stage was concurrently integrating the analog to digital converter to work with the microprocessor and designing the analog front end. After both of those steps were completed the analog front end was integrated to work with the analog to digital converter. Renato worked on integrating the analog to digital converter with the microprocessor while E.J. worked on designing the analog front end. We planned on integrating the analog to digital converter using a breadboard and the microcontroller experimental board however the breadboard was unnecessary and an Analog to Digital Converter was included with the processor. The converter was placed on a breadboard with wires extending to the experimental board and power supply, but it was not used. We tested to ensure that the analog to digital converter was working by attaching a function generator to the analog to digital converter and observing how the microcontroller received the data. At this point the microcontroller did not have an output and because of this, we created a program to output the data to MATLAB which graphically displayed our results. The input was initially a simple sinusoidal wave therefore the outputted data in MATLAB displayed these results graphically. The design and implementation of the analog front end was the most difficult task. The analog front end has Butterworth filter and was a third order filter. The filter has a gain of about 5 and a cutoff frequency of about 150 Hz. The Butterworth filter was designed by adjusting the component values in the Butterworth configuration in a method known as functional trimming. To functionally trim a filter the transfer function must be derived using a circuit analysis method such as Kirchhoff s voltage law or Kirchhoff s current law. The transfer function is placed into standard form and the components needed to modify of the quality factor, resonant frequency, and gain can be observed. The first value to be obtained is the gain, the second value is the resonant frequency, and the last value is the quality factor. When modifying components it is essential that the components adjusted are not located in the formula for another section that has been previously modified. The bandwidth is then calculated by dividing the frequency by the quality factor After the front end is designed it was simulated on Multisim to ensure functionality. The circuit could have then been assembled on a breadboard and tested with a spectrum analyzer and a function generator. The function generator could have been configured to output a signal similar to that of an ECG electrode and the spectrum analyzer will be used to ensure the output is correct. After ensuring the proper operation of the front end it was connected to the analog to digital converter and microprocessor. The equipment will be tested the same way as before with the microprocessor outputting the data to a device. In this case the Invivo Precess Machine. We also tested it by measuring the voltage as it was outputted. The design of the analog front end and integration of the analog to digital converter were performed concurrently because we wanted the analog to digital converter to be attached to the microprocessor as soon as possible. The primary reason we 79

86 wanted this accomplished quickly is because we wanted to have the ability to make a design change to the microprocessor or the analog to digital converter without having to redesign any other equipment. Also, having the analog to digital converter attached to the microprocessor allowed the microprocessor to be tested with true analog signals generated from a function generator. The design of the analog front end was the most time consuming because it required the most amount of circuit design. If we were to encounter any problems with the front end we want to encounter them as soon as possible. Once everything was assembled and discovered to be working correctly the most difficult part of the design process was completed and we were able to move onto the third stage. Stage three in the design was implementing the digital to analog converter while simultaneously implementing the USB port. Our primary goal was to output an analog signal but we choose to also attempt a USB port so that we have a backup if anything goes wrong with the digital to analog conversion. Renato worked on the USB output while E.J. worked on the digital to analog conversion and output. The USB output would have allowed the Adaptive ECG Filter to communicate with the planned tablet computer to expand the functionality of the system. We believed that adding USB to the board will be quite simple. One of the challenges that comes with using a USB port is in programming the microprocessor with the correct communication protocol. However this was not the only problem and due to some unknown problems the USB was not fully integrated. The USB design protocol is discussed in the programming section of this document. The digital to analog conversion was performed with a digital to analog converter manufactured by Analog Devices. Once the conversion was performed, the converter was connected to output electrodes to transmit a filtered ECG signal that is similar to an ECG signal produced by electrodes in a non MRI environment. The digital to analog converter was attached to the microprocessor and tested to ensure functionality. The test included the whole system working together to filter an analog signal and have a final analog output. We tested the design by attaching a function generator to the input what is generating four separate signals. Two of the signals passed through the filter and were within the normal operating range of an ECG and one was outside of the normal operating range and was filtered out. After this test was successful we had a functioning Adaptive ECG Filter and began to attach the components together in a permanent manner which is the next and final step of the filter design process. The final step in the design process was to design the circuit board and attach all of the components onto it. During each of the earlier design phases a PCB layout file was completed. The circuit board design stage was simple and consisted of combining the separate files into a single file to construct the final circuit board. During the board design phase we reevaluated the overall plan to power the components and determined if any changes need to be made. After the board design was reviewed; we finalized it and it was ordered through a Philips distributer and had a projected turnaround time of about two weeks. However, the board took a lot longer to receive. Once we receive the printed circuit board we had all of the components attached by another of Philips distributors. Once we have the final 80

87 product we tested it in the lab with the spectrum analyzer and function generator the same way we meant to test the circuit before assembly. After confirming the operation in a lab environment we then coordinated with Philips to test the filter in an actual MRI machine and observe the final result. Once this was determined to be working we finished building the filter and have a deliverable product. A Pert Chart displaying the estimated design plan can be observed below in figure 48. However, the timing for it did not accurately reflect our project. Load test program onto microprocessor December 15, 2013 January 5, 2014 Design and order PCB February 20, 2014 March 2, 2014 Solder components to PCB March 2, 2014 March 10, 2014 Actual Start Actual Finish Actual Start Actual Finish Actual Start Actual Finish Function test and integrate analog to digital converter January 5, 2014 Actual Start January 30, 2014 Actual Finish Connect A/D Converter to microprocessor for function testing January 30, 2014 Actual Start February 8, 2014 Actual Finish Connect all components for system function testing February 8, 2014 Actual Start February 20, 2014 Actual Finish Function test final Product March 10, 2014 March 20, 2014 Actual Start Actual Finish Design Analog Front End January 5, 2014 February 8, 2014 Function test and integrate Digital to analog converter January 12, 2014 February 12, 2014 Actual Start Actual Finish Actual Start Actual Finish Figure 48: Pert Chart Displaying Design Plan The design plan was created with a focus on completing the design as expeditiously as possible. The biggest obstacle we faced is completing the project on time. The Adaptive ECG filter is a system of components working together and a change in certain components could have and did cause a ripple effect and necessitated the change in other components. For example, if we had planned on programming the microprocessor at the end of the design phase we may have discovered that it was not powerful enough to perform the filtering operations. If we have to switch to a different processor the new processor will have a different pin layout and would have required a redesign of the circuit board. A different processor may also have had a different power requirement and cause us to have to redesign the power distribution system. Along with a different power requirement the processor may not have worked with the analog front end or the digital to analog converter and require a redesign of those components. A redesign of those components will require a redesign of the board and power 81

88 supply again. This process can repeat many times over and our design was focused on avoiding this problem. We avoided this problem by starting our work on the inside of the system and working our way out. We know that everything is dependent on the processor working and because of this, we ensured that the processor worked before we moved onto the next aspect of the design phase. 9 Project Prototype Construction and Coding 9.1 Parts Acquisition Raspberry PI We considered using a Raspberry Pi as part of our project. We felt that it would be capable enough to handle the instructions that are given and complete them without too much chance of the system crashing. The GPU provides Open GL ES 2.0, as well as a hardware-accelerated OpenVG, and it has a 1080p 30 high-profile encode and decode. The GPU is capable of 1Gpixel/s of general purpose compute and it also features a bunch of texture filtering and DMA infrastructure. The Performance we need is around 10MHz. The Raspberry Pi operates at 700 MHz straight out of the box. However, the system can be overclocked and most devices will run happily at 800MHz. There is an option to change the overclocking options on first boot and then any time afterwards by running it. One nice feature is that the Raspberry Pi does not overheat. In figure 49 below is a layout of the Raspberry PI Figure 49: Raspberry Pi Board 82

89 The chip used in the Raspberry Pi is equivalent to a chip used in a cellphone, mostly because neither of which will become hot enough to need any special cooling. If you just like the look of a heat sink, you will not damage anything by placing any sized heat sink on it. The Raspberry Pi has 8 dedicated GPIO pins with two chip selects and a ground. The maximum number of GPIOs can be indefinitely expanded by making use of the i2c or SPI bus. A negative side of the Raspberry Pi is that it does not have a real time clock. A couple of reasons why is because non-network connected units will have their clocks updated manually at startup. Adding a Real Time Clock is surprisingly expensive, once you have inserted batteries, the area and the component would have pushed the price of the Raspberry Pi dramatically higher. Another negative feature of the Raspberry PI is that the RAM is a Package on Package on top of the SoC, so you cannot remove it or swamp it out and the 512 MB is the maximum RAM the Raspberry Pi can support. Figure 50 below illustrates the LED design in the Raspberry PI board.. Figure 50: Raspberry PI LED Diagram A television was planned to display all of the data, what we like is that there is composite and HDMI already on the board, so you could hook it up to an old analogue TV through the composite or through a composite to scart connector, to a digital TV. There is no VGA support, Passive HDMI->VGA cables will not work with the Raspberry Pi. Another great feature of Raspberry Pi is that it can encode and out of the box. There is also two additional codecs that you can purchase through the Raspberry Pi Store that will enable you to decode any MPEG-2, it is a very popular format to encode DVDs, video camera recordings, TV and a second one that enables you to decode VC-1, a Microsoft format found in its media programs and DVDs. The media connections are shown below in figure

90 Figure 51: Media connections of Raspberry Pi The device can be powered by 5v micro USB. Exactly how much current the Raspberry PI requires will rely on what we would have to hook it up to. We realized that purchasing a 1.2A power supply would provide us with ample power to run the Raspberry Pi. In most cases the Raspberry Pi will use around mA depending on what peripherals are connected to it. The maximum power the Raspberry Pi can sustain is 1 Amp. If we were to connect a USB device that would take the power limits above 1 Amp then we would have to connect it to an externally powered USB hub. The power requirements of the Raspberry Pi will increase as you make use of the various interfaces on the Raspberry Pi. The GPIO pins can easily draw 50mA safely; the HDMI port normally uses 50mA. The Raspberry Pi by default, supports Python as the educational language. Any language which will compile for ARM can be used with the Raspberry Pi. That is a reason why we liked the Raspberry Pi because we are not limited to using Python. C, C++, Java, Scratch, all come installed by default on the Raspberry Pi. However, since we could code the entire solution on the Tiva Stellaris board and did not need to integrate the raspberry Pi, we felt this solution was pointless. While it is a powerful device, especially related to its cost there was no reason for us to use it and as such we didn t. The solution with the ARM Cortex M4 met our requirements and had all the necessary components for our project. 84

91 9.1.2 Hercules Launch Pad The Hercules launch pad is a high performance automotive grade microcontroller for safety systems. The safety architecture dual CPU s in lock step, CPU and memory built in self-test logic, ECC on both the flash and the data SRAM, parity on peripheral memories, and loopback capability on peripheral I/O s. The launch pad integrates the ARM Cortex which offers an efficient 1.66 DMIPS/MHz and can run up to 133 DMIPS. It consists of 384KB and 256KB integrated flash and 32KB data RAM with single bit error correction and double bit error detection. In the figure 52 below is how the Hercules board reads data. Figure 52: Hercules Functional Block Diagram The flash memory on this device is a store memory when power is absent. The flash system runs on a 3.3V power supply input for all the read, programming, and erase operations. When in pipeline mode it runs on system clock frequency of 80MHz, the SRAM supports single cycle read and write accesses in byte, half word, and word modes throughout the frequency range The Hercules Pad includes peripherals for real time control based applications including a next generation high end timer timing coprocessor with up to 1.9 total I/O terminals and a 12 bit analog to digital converter supporting 16 inputs in the 100 pin package, it also has an intelligent timer which provides timing functions for 85

92 real time applications. Due to the fact that its software controlled, it reduces the instruction set with the specialized timer. It knows how to pulse and modulate outputs, capture or compare inputs. In figure 53 & 54 below displays how the level outputs work. Figure 53: Level Input Figure 54: Level Output The Hercules pad has 12 bit resolution MibADC with 16 channels and 64 words of party protected buffer RAM. The channels can be converted individually or can be grouped by software for sequential conversion sequences. The launch pad also comes with a frequency modulated phase locked loop clock module that is used to multiply the external frequency reference to a higher frequency for internal use. The device also has an external clock pre-scale module, when the clock pre-scale is enabled it outputs a continuous external clock. One of the features that really stood out to us was the error signaling module monitors all device errors and determines whether an interrupt or external error pin is triggered when a fault is detected. In figure 55 is a description of the clock domains. 86

93 9.1.3 Tiva Launch Pad Figure 55: Clock Domains The Texas Instrument's Tiva Launch pad provides with a high-performance ARM Cortex based architecture with a broad set of integration capabilities and with a strong ecosystem of software tools. Alongside its excellent targeting performance and flexibility, the Tiva launch pad s architecture offers an 80 MHz Cortex with FPU with a variety of integrated memories and multiple programmable GPIO. The Tiva Launch Pad is designed around the ARM Cortex processor core. The ARM Cortex processor provides the core with a high-performance, low-cost platform that will meet the needs of minimal memory implementation, and low power consumption, while also delivering outstanding computational performance and exceptional system response. The Tiva Launch Pad is displayed below in figure

94 Figure 56: Cortex M4 System Bus Interface The Tiva Launch Pad comes with a battery-backed Hibernation module to power down the launch pad to a low power state while it s in extended periods of inactivity. The Tiva Launch Pad also features a power-up and power-down sequencer, a continuous time counter, a multiple wake-from-hibernate options, and a dedicated battery backed memory. The Hibernation module makes the Tiva launch Pad microcontroller perfectly for battery applications Figure 57: Tiva Launch Pad LED Diagram Due to the built in components of the Tiva Stellaris C, we decided to choose it. However, we chose the actual developmental board as opposed to the Launchpad to ensure that we had all necessary requirements. This proved to be incredibly useful in the future development of our project since it had a built in Analog to Digital convert, support for the CMSIS libraries and it was able to be shipped by our main supplier Digikey. 88

95 9.1.4 AFE0064 The AFE0064 is a 64 channel analog front end designed to suit the requirements of flat panel detector based digital X-rays systems. It includes 64 integrators, a PGA for a full scale charge level selection, a correlated double sample, and 2 differential output drivers. The hardware selectable integration polarity allows integration of a positive or negative charge and provides more flexibility in system design. The AFE0064 also contains thin film transistor charge injection compensation, this helps maximize the usable signal charge range of the device AFE0256 Figure 58: AFE0064 The AFE0256 is a 256-channel analog front-end designed to suit the requirements of flat panel detector based digital x-ray systems. The device has 256 integrators, a programmable gain amplifier for full-scale charge level selection, correlated double sampler with dual banking. This device also features four 14-bit successiveapproximation register analog-to-digital converters on board. Serial data from the ADCs are available. Hardware-selectable integration polarity allows positive or negative charge integration and provides more flexibility in system design. 89

96 9.1.6 AFE1256 The AFE1256 is a compact, USB 2.0-based evaluation kit. This kit has all the electronics integrated on the EVM required for characterizing. Some of these blocks include digital-to-analog converters for driving the inputs, a 3.4-V power for the AFE1256, options for driving the AFE1256 from external power supplies, a fully-flexible pattern generator implemented in the FPGA for providing various timing and control signals to the AFE1256, and FPGA-based data acquisition for capturing the AFE data output. The onboard DACs and CLK generator implemented within the FPGA can be directly controlled with the GUI. The GUI configures the AFE, loads and runs patterns to the AFE1256, and analyzes the AFE1256 output data. The image viewer integrated with the GUI provides a monochrome image representation of the captured data. The image could as well be offset corrected. Common analysis are performed and displayed along with the captured data. The GUI can be used to save the AFE1256 data in text format for offline analysis. The AFE 1256 is shown below. Figure 59: AFE PCB Vendor and Assembly Making of the Board Originally printed circuit board artwork generation was a full manual process done on clear Mylar sheets normally on a scale of 2 or 4 times the desired size. The schematic diagram would first be converted into a layout of components pin pads, then traces were routed to give the required interconnections. The preprinted non reproducing Mylar grids assisted in layout, and the rub on dry transfers of most common arrangements of circuit elements helped standardize the layout. The finished layout was then photographically reproduced on the resist layers of the blank coated copper-clad boards. In other methods the unwanted copper would be removed to leave only the desired copper pattern. In most common methods the pattern is electroplated onto a bare 90

97 substrate using a complex process. The great thing of the additive method is that less material is needed and less waste is produced Figure 60: PCB creation Process Chemical etching is usually done with ammonium persulfate or ferric chloride, any additional steps of electrolysis deposition would done after the holes are drilled, then copper would be electroplated to build up the thickness, the boards are then screened, and plated with tin & lead. The tin & lead combo becomes the resist leaving the bare copper to be etched away. As more copper is consumed from the boards, the etchant will start to become saturated and less effective; the different etchants have different capacities for copper, with some that contain as much as 150 grams of copper per liter of solution. In commercial use, the etchants can be regenerated to restore their normal activity, and the dissolved copper would be recovered and reused. Smallscale etching would require attention to disposal of used etchant, which is toxic due to its metal content. The etchant would remove all the copper on all surfaces exposed by the resist. Undercut would occur when etchant attacks the thin edge of copper under the resist; this would reduce conductor widths and cause open-circuits. The needed control of the etch time is required to prevent undercut. Where metallic plating is 91

98 used as a resist, it would overhang which can cause short-circuits between the adjacent traces when closely spaced. Most multi-layer printed circuit boards have trace layers inside the board. An easy way to make a 4-layer PCB is to use a two-sided copper-clad laminate, you will need to etch the circuitry on both sides, then laminate the top and bottom prepare and the copper foil. The lamination process is done by placing the stack of materials in a press and applying pressure and heat for a certain period of time. It is then drilled, plated, and you will need to etch again to get traces on top and bottom layers. Finally the PCB board will be covered with solder mask, a marking legend, and a surface finish may be applied. Holes through a PCB are normally drilled with small drill bits made of solid coated tungsten carbide. Tungsten carbide is recommended because many board materials are very abrasive and the drilling must done in high RPM. Drill bits must also remain sharp to not tear the traces. Drilling with steel spinning at high speed is simply not done since the drill bits would dull very quickly and would tear the copper possibly ruining the board. Once the holes are made they are often filled with annular rings to create vias. The vias allows the electrical and thermal connections of conductors on opposite sides of the PCB board. After the printed circuit board is completed, the electronic components must be attached to form a functional printed circuit assembly. The components are placed on pads or the lands of the outer surfaces of the PCB board. In the both kinds of construction, the component leads are electrically and mechanically fixed to the board with a molten metal solder. There are a vast variety of soldering techniques that can be used to attach components to a PCB board. High volume production is usually done with a SMT placement machine, but experienced technicians are able to solder very tiny parts by hand under a microscope, using small tweezers and a fine tip soldering iron for small volume prototypes. In a boundary scan testing, test circuits are integrated into various ICs on the board form temporary connections between the PCB traces to test that the ICs are mounted on correctly. A Boundary scan testing requires that all the ICs to be tested use a standard test configuration procedure, the used one being the Joint Test Action Group standard. The Joint Test Action Group test architecture provides a means to test interconnects between the integrated circuits on a board without using any physical test probes. The Joint Test Action Group tool vendors provide various types of stimulus algorithms, not only to detect any of the failing nets, but to also to isolate the faults to specific nets, devices, and pins. Often, sometimes a through hole and surface mount construction must be combined in a single assembly because some of the required components are available only in a surface mount package, while others are available only in a through hole package. Another reason that we would use both methods is that a through-hole mounting can provide needed strength for components likely to 92

99 endure any physical stress, while components that are most likely to go untouched will take up less space than using surface-mount techniques. 9.3 Final Coding Plan The plan we used for coding the final project is listed below. The PERT (Project Evaluation and Review Technique) chart is a tool used in project management used to analyze the involved tasks in completing a given project. It specifies the time needed to complete each task, and identifies the minimum time needed to complete the final project. This schedule was chosen so that we would complete the project in a timely manner. More time was chosen for items that are expected to be difficult, less time for components that are expected to be easy. Unfortunately the time scale did not accurately reflect our projects timeline in this project. Figure 61: PERT chart for Coding Plan Version Control Our method for managing the source code of the project will be version control. Version control is able to track and provides control over changes to the source code. We have two members who be worked together developing the source code. Having this control will allow us to collaborate more effectively by being able to see the exact changes the other member has committed. 93

100 The software we used for version control is called Bitbucket. We chose this software primarily because it allowed us to have free private repositories for up to 5 people in a group. Our repository needs to be private because we do not want strangers to be able to look at and possibly copy our code. A lot of work will be put onto this project and we want to keep it to ourselves and Philips. With the repositories being free, it allows us to save some spending. Bitbucket also has all the main features you would want in a version control software like pull requests, code reviews, remote hosting, and a web based interface. Another alternative is GitHub, however GitHub costs a yearly subscription fee to utilize for the project. 10 Build and Prototype Plan 10.1 Software The build plan required us to build different parts of the software at different times. For example, we initially created the Filters and created a Publish/Subscribe system. We had one team member working on each of these and they were helped if one was ever stuck on a problem with regards to the software. After the Publish/Subscribe system was completed, a graphical display was necessary for testing the data. Below is a PERT chart detailing the various things we thought we needed to do to complete the software section of this project. We also ensured that the Hardware is done prior to testing the filters for the project. This is necessary, but as it is our last step we will ensure plenty of time prior to this event. The PERT Chart is fairly accurate other than the fact that we did not test various filters and the timing is incorrect for our project. 94

101 Figure 62: Pert Chart for Project Completion 11 Project Prototype Testing 11.1 Hardware Test Environment Interference To test our ECG filter we needed to have several products supplied to us by Philips, most being an ECG signal provider. A feature we had to put in our design for our adaptive ECG filter was a housing that would not transmit frequencies and disturb the MRI as the final product in later developments aims to be used in the MRI. The reason being; that we must keep the area around the MRI clear of any unwanted magnetic fields, RF frequencies, or vibrations. 95

102 Magnetic Field Excessive DC interference will cause blurring of the image. Possible sources of DC interference include railroads, elevators and highways. Excessive AC interference will cause multiple images to display ghosting. All air conditioning, power lines, improper wiring or grounds are possible sources of AC interference. An Engineer will measure the AC and DC interference levels at the site during testing. The values that are obtained will determine whether or not external compensation must be used to reduce interference to minimal levels. The maximum values for both the AC and DC interference with and without compensation are in the table below Maximum Values without Magnetic Compensation needed DC(<5Hz) AC(60Hz).3mG pk-pk.2mg pk-pk Maximum Values with Magnetic Compensation DC(<5Hz) AC(60Hz) 30mG pk-pk 10mG pk-pk RF Frequencies Radio Frequency (RF) Interference may cause lines, bands, or spikes in the images acquired by an MRI scanner. The external RF noise cannot be more than 40dB mv/m. RF interference will be determined during the MRI Site Test performed by an Engineer. The data obtained will be used to determine the best magnet frequency for your site and whether any additional shielding will be required for your E-Scan Extremity MRI device to function properly Maximum Acceptable RF Interference 40dB mv/m Vibrations Building vibrations or shocks affecting the magnet may degrade image quality. The Vibrational Acceleration amax must not exceed 70dB for a frequency range of 0 to 100Hz. Vibration testing will be completed during the site test. Building Vibration Requirements 96

103 amax -70dB from 0-100Hz Lighting Fluorescent lighting causes AC interference with the imaging system. The light Fixtures should be removed and replaced with Incandescent fixtures Temperature and Ventilation The air conditioner for the scan room must operate constantly. The temperature of the scan room must be maintained within the Fahrenheit temperature range. The temperature cannot change by more than 5 F per hour. The software will disable the scanner should these conditions not be maintained. Provide separate vents to remove helium gas produced during boil-off and quench of the magnet. While the boil-off is a normal venting phenomenon, the quench occurs when a super conductive magnet becomes resistive. An automatic emergency 100 percent exhaust system, in the gantry room, to remove helium gas during an accidental spill. The MRI device will operate at the following temperature and humidity levels: Temperature Max Temperature Change Relative Humidity 68 F-79 F <5 F/Hour 45%-80% noncondensing Power Requirements The power requirements for a MRI device are as follows: Voltage Frequency Current Max Apparent Line Resistance 120 VAC

104 11.2 Hardware and MRI Specific Testing ECG Adaptive Filter The adaptive ECG filter will be tested on a subsequent iteration of the project with the format that Philips uses to test their current ECG devices. Because we have seen the past success rate that was archived by Philips. When testing an ECG Filter, it is not too complicated when it comes to the connection stage. We simply connect the ECG Filter to the Simulaids Interactive ECG Simulator Box, once the desired settings on the simulator have been set. Once setup is compete then the MRI will be turned on and the magnet will be run at the highest possible SAR rating. This allows the maximum amount of RF energy to couple on the ECG. To simulate a human body that picks up RF energy and gradients, we connected a loop of wire to the ECG lead set. We then connect the 3 Ultrafire mah 3.7v to the analog filter and make sure the LED showing power lights up. On the PCB board its self we have 3 LED s that show power connection, good connection of the ECG cable, and good connection of the user interface. Once we ran the simulation through several trials, consisting of different variable analog filters we will compare our results with that of trails done by Philips on their other models of ECG machines Power Source We decided to go with rechargeable 3.7v batters, we found it would be sufficient for the filter due to the fact that the User interface would already come with its own battery incorporated in the device, and the ECG simulator plugs into a standard 120V outlet. We tested to see that the batteries supplied sufficient power to the filter device and that it didn t short-circuit either, the connection of the batteries also need to be connected to the analog device and that the analog device recognized that it had power by turning on its LED light displaying POWER ON Software Test Environment The testing was done on multiple systems. We initially tested the results using MATLAB to display the data on multiple graphs and ensured the LMS Filter was working appropriately. Then we tested it using values from a function generator to ensure the results were expected. The gradients were used as one analog signal and the signal was another. After doing this we tested each individual part. For the development of the ECG filters, we utilized Test Driven Development. In Test Driven Development, the idea is that, if a piece of software is worth creating, it s also worth testing. As such tests are created prior to an item being developed. The tests are automatically used and it will allow a very succinct product to be created. We tested the results from the Processor with those of MATLAB. However, due to memory issues it was difficult to create appropriate unit tests for our device. 98

105 As Test Driven Development is an Agile Methodology, it will allow for quick iterations and allow us to ensure each part is created adequately. With regards to an article by the National Research Center in Canada, people who write more tests are more productive and produce higher quality products. With this being the central theme behind Test Driven Development, we hope to produce the best products we can. After we have completed the Tests, we will of course be performing integration testing to ensure that our code is correct and that we cover all outlier cases. Integration testing is done to ensure that each of the units works together. Unit testing is done to test individual sub-modules. However, knowing that certain parts of our code work; doesn t mean that when used together, they still work. As such we will ensure the strictest of standards with regards to our testing and will enforce a zero-defect policy. A zero-defect policy is such that we will fix any problems we find as soon as we find them. The reason behind this policy is because; if an error is found early we want to fix it before it s forgotten. If an error is found early in development and it s not fixed it almost always will come back and bite you harder later on. Errors in development are cheapest early on in the development cycle and will compound later on. Another thing we will do to ensure quality is have our programs peer-reviewed. This will help to catch any mistakes that testing may not have done and will ensure that our code is manageable by other team members. The peer-review is largely for fixing errors and as such will not fix things like grammatical mistakes etc. One main feature we tested was ensuring that our filter matched the results of that in MATLAB. Doing this led to the finding of several errors inside our code. At one point we were sending all zero values to MATLAB and at another, an extra byte was being sent when the ASCII code for new line was sent. It sent return line. As such we had to change the format of which we sent code to MATLAB. Another issue was within MATLAB itself with regards to how quickly it received the data. This was fixed by reading in multiple bytes at a time as opposed to doing several read functions. For some reason doing several read functions slowed our program down a lot. After we ensured our algorithms were performing correctly and we compared the results of data with the data sets we expected from MATLAB we also checked the data with actual results from the ECG Generator that Philips owns. This will allow us to use simulate data and filter out the noise as opposed to guessing the data and putting in completely irrelevant noise. The next step after we ensured that our application works as designed, is that we had to ensure that the application meets all of the requirements. This is defined as System Testing. System Testing ensures that the program itself does not have any arbitrary side effects that were not intended. That no stray threads are left 99

106 running after completion of the program and that there is no memory leakage. We used automatic resource management whenever possible. Luckily automatic resource management was always possible in our program. Since the software will be run on an embedded device, it only makes sense to perform the testing to match the specs of the embedded device. Initially, this was not done to save on time, but we ensured to always test on the embedded device near the end of an addition. One of the primary things we encountered problems with is memory and speed. There are often bottlenecks in programs and to avoid these, it s necessary to find where the speed needs to be enhanced. Oftentimes the program runs slow in only two percent of the code and that 2% may need to be rewritten using tricks to make it faster or completely rewritten in assembly. Writing the code in assembly was of course, not an option. Primarily due to the increased time it takes to code in assembly and problems with maintenance. In certain parts of the code, we care more about maintainability, and how the code looks than how fast it runs. These situations are the situations that we have an excess amount of memory and time or only affect the memory and/or time slightly Software Specific Testing As stated previously the software specific testing was performed during all stages of the development cycle. We continuously tested the various components of the program to ensure everything was up to spec. One other thing we used to test; is just us running our software through and ensuring all results are probable. Of course, since we were running this on potentially millions of ECG results, it was not be possible to do so in every situation. However, another thing that we ensured happens is that we throw errors for any unexpected situations inside the program. Throwing errors would have allowed us to ensure that certain things never happen and if they do, we were notified of it. One thing that ensured quality is running the program for an extended period of time and seeing how it deals with memory issues. Memory issues are a very real occurrence when dealing with the ECG. This is because a lot of memory from the MRI will be sent to us. To remedy this, we will consider this situation in the programming of our devices. One such way to remedy this problem is to have more than one algorithm for the computation of the ECG display. However, this was not used due to confidence in the LMS algorithm. Some computations may be a lot more memory intensive than others and could cause a problem in this regard. This was not a problem due to the memory used in the LMS Algorithm. Also, it was possible to change the Number of inputted values and the filter order to change the amount of memory required by the software. 100

107 One other thing we used to mitigate the storage issues is to check to see where the issue is. There are generally multiple ways of storing and or retrieving the information and a faster method will often mitigate some of the memory based problems. One way we ensured it ran faster is by changing the optimization levels in the settings of the device. Another rather prevalent issue in software programs is speed issues. This may be a problem based on the algorithm we used for filtering. Unfortunately, some algorithms while very good at removing noise may not be the best at using little processing power. As such, we will measure the time it takes for the algorithms and ensure that it runs fast enough for our given requirements. We checked the speed at which our program sent to MATLAB on the Stellaris boards and after a lot of refinement this was not an issue. One of the most important things to check prior to checking for issues inside our own programs; is ensuring that the data we receive is correct. It s rather difficult to filter out data that is already malformed. We initially checked this by inputting the data through a MATLAB filter and later created an algorithm to ensure that the inputted data is correct. There can be a variety of things that can mess the program up and ensuring the inputted data is similar to what we are expecting is rather important. As such, our program will utilize various methods to ensure that it doesn t take up too much memory or processing power. The first thing we did is find out when the program is taking up too much memory. The next thing we did is find out if we can ensure it uses up less memory. After that we ensured preventative measures were taken in the chance that memory is being taken up too quickly. Memory can be taken up by a variety of different factors and to ensure that the program is modular, we must use a smaller amount of memory for the program. Another thing that is incredibly important to ensuring the memory is not being taken up is to ensure there are memory leaks. Luckily, leakage in memory can be measured by external programs and we will ensure these do not exist. However, we can never be 100% confident that our program is perfect and as such we will implement a back-up program that our initial program switches to if the results are becoming odd. Bad results can be due to memory being implemented incorrectly or a malfunction inside the application. Our program ensured that memory was not allocated at run-time and this ensured no memory leakage occurred. This program will also be tried out on several different devices and varying inputs of data because a change in hardware or the software it is interlacing with could cause a problem inside the code. An automatic testing process using the Boost Test libraries would have been implemented. This would have been selected because boost is a very good open source library that is often incorporated in the standard C++ library. Therefore, Boost Test is the closest we can get to a standard testing library inside the C++ framework. However, due to using Embedded C++ 101

108 versus C++ this was not possible and we could not test it using any of the boost libraries. Boost Test allows a lot of functionality. One thing it allows is checking if an item works correctly. When it uses checking it will signify an error but the program will not crash, if it requires a specific thing, the test will crash if it does not succeed. The tests for boost test will be written separately than the normal application and will ensure speedy and frequent tests. The more tests we run, the more confidence we will have with our application. This is one of the main things behind using test driven development. Another benefit behind Boost is that it delivers the test results in a human readable format or in an XML based format to allow automated testing. Some tests should be read by us, but other tests may need to be done autonomously to allow us to create better error reports or use another program to analyze the reports. As such, we have decided that the Boost libraries are the best choice for testing. However, since our device does not support boost like we expected we cannot use it. We also tested to ensure all functions we get from other locations work properly. Oftentimes, just assuming that their functions are working correctly could cause a multitude of problems. As such, tested with outliers for their functions and ensuring that their code meets the same level of success that our code requires for the project. One of the first things we need to do when checking if a program has a bug, is look at the current bug reports for the function and see if our problem is common. Depending on where we found the libraries we are using, it is very likely that any faults are with our code as opposed to the libraries. However, they need to be tested as well. This problem was shown time and time again. At times one developer would blame the library we were using only to find that it was an issue on our part. The interface itself would have needed to be tested thoroughly and we would have needed to make sure any user options that are selected do not interfere with any other selections that the user may make. This will require extensive testing and we will do our best to automate many of the user s selections or things they may do, because while our application will likely come with a manual not everyone wants to read the document. However, due to using the Invivo Precess Machine to display the information this part of the project was not necessary to display our results and almost no time was spent on doing this part of the project. As always, even now after testing is completed, it would be advised that the user ensures that the data returned are as expected. There may be select cases that could not have been covered by our testing and we cannot guarantee that there are no defects in our software. We did our best to ensure it and did extensive testing for every feature that we implement, but, that is often not enough and unfortunately the cost of errors can cost millions of dollars to corporations. Many 102

109 companies that have much more vast testing regulations than these, like PayPal, have continued to experience inaccurate results at times. While everyone hopes these do not happen, it is an undeniable fact that software development is difficult and has a lot of complexities. As such we hope these testing practices were exhaustive enough to avoid any and all major problems with the application that we have created PCB Testing To test the PCB board shows in figure 63, we had to verify that all the hardware on the board worked first. In figure 64 we used a JTAG programmer to program the software to the board. This was done by measuring the voltages values of the power supply modules to check if they are correct. A sine wave signal was inputted through the ECG pins and the processor was set to do no filtering. This makes it so that the analog output should be the same as the input. First this required checking that the signal received by the MCU are the correct values. If it was not, then that means that something is wrong with the circuit before the signal gets to the MCU. The signal being outputted from the MCU was also checked. To send data to the external DAC, SPI had to be used. Figure 65 shows the oscilloscope readout of the three pins that SPI uses, Clk, Fss, and Din. Pink is the Clock, blue is Fss, and yellow is the data being sent to the DAC. Lastly we check the output of the DAC. Since no filtering is being done initially and a sine wave is being passed through, figure 66 shows the results. This is a sine wave obviously but you can see that it is digitized by the blocky signal. This is to be expected because the signal was represented digitally. Now at this point, we know that all the hardware on the PCB board works. 103

110 Figure 63: Printed Circuit Board Figure 64: JTAG Programmer 104

111 Figure 65: Synchronous Serial Interface Oscilloscope Readout Figure 66: DAC output from sine wave The next thing to test is a generated ECG signal. Figure 67 shows the machine that was used to generate the ECG signal. The characteristics of the signal is a maximum of 5.5mV and a frequency of about 50 khz. The machine has four pins that we use. These represent), and RL (right leg), RA (right arm), LA (left arm), and LL (left leg). The color coordination is kept consistent between the ECG generator to the color of the wires. Figure 68 shows how the machine is hooked up to our PCB board and then to the wireless transmitter. The wireless transmitter then sends the analog signal to the Invivo Precess machine. This machine is built for displaying ECG signals very accurately. 105

112 Figure 67: ECG Generator Figure 68: Connecting generator to PCB to wireless module 12 Results In figure 69, it shows the ECG output from our PCB board with no filtering being done. From what you can observe is that the display is reading 120 bpm (beats 106

113 per minute), the peaks are defined, but there is a lot of intermediate noise between the peaks. Figure 70 shows the output when the filtering functionality is turned on. You can observe that the beats per minute is 118 (close enough to 120), peaks are not as high and the intermediate noise between the peaks is slightly lessened. Overall there is a slight improvement by using our filtering. Admittedly there are lots of room for fine-tuning and that is fine. We accomplished our goal of providing a platform that can be customized with different types of filters by programing the MCU. This project will hopefully help advance the proficiency and quality of Philips medical equipment with respect to the gathering of ECG signals. Hopefully at a later date in time; the use of Adaptive Filters will become commonplace when recording ECG signals. Figure 69: ECG output without filtering 107

114 Figure 70: ECG output with filtering 13 Personnel and Bibliography of Related Work 13.1 Edward Jezisek Edward Jezisek is an up and coming Computer Engineer from the University of Central Florida. He is currently working at D&SCI and is going to be working for Verizon Wireless as a Systems Engineer. He also creates android applications in his spare time. If you re interested, check out his android application Floating Draw. It currently has 68,000 downloads and he has several up and coming updates for this application. It was recently obtained by dsinestudios. Feel free to check it out Brandon Autrey Brandon Autrey is a Computer Engineer at the University of Central Florida. He currently works at the Institute of Simulation and Training at the STOKES Advanced Research Computer Center. His current interests include parallel programming, networking, computer graphics, and computer gaming. During summer 2014, he will be starting with Lockheed Martin at Mission Systems and Training as a Software Engineer. He plans to come back to school get his Masters in either Computer Engineering or Computer Science. 108

115 13.3 Edward Nowlin Edward Nowlin is an Electrical Engineer interested in the Analog and Digital Center. Edward Nowlin is interested in a government job and already has experience working for the US Navy Renato Ortega Renato Ortega is an Electrical Engineer. He is interested in power systems and power generation. Currently Renato interns at Siemens energy working in plant engineering sector. Renato has also done research for the UCF nanotechnology and optics sector under Dr. Debashis Chanda. 14 Sponsor/Consultant Philips is the sponsor for our project, which is being made for Invivo. Invivo Corporation is a section of Philips that provides technology solutions to the healthcare market. Invivo develops patient monitoring systems for use in an MRI environment. More specifics include the following: Headquartered in Gainesville, Florida, the Invivo Corporation is a subsidiary or sister company of Philips Healthcare and world leader in MRI coils and related accessories. The company s vision is to deliver clinical solutions to customers, whether indirectly through Original Equipment Manufacturers of MRI scanners or directly to clinical MRI users. Philips/Invivo s history is grounded in the expert development of MRI coils and more recently in the development of integrated clinical solutions like Functional MRI and the DynaCAD breast imaging systems. Research and advanced development are at the core of the future of the MRI field and are a key part of Invivo's strategy for growth. Another area of the corporation is the Invivo based in Pleasanton California, which designs, manufactures and markets monitoring systems that measure and display vital signs of patients in medical settings. These can be used in both magnetic resonance imaging (MRI) environments and in general monitoring applications. Invivo s systems simultaneously monitor heart function, heart rate, respiration, blood oxygen levels, as well as invasive and non-invasive blood pressure and exhaled carbon dioxide levels. Invivo is also involved in the industrial instrumentation business. It designs, manufactures and markets sensor-based instruments and then sells these patient monitoring products to hospitals, imaging centers, outpatient surgery centers and original equipment manufacturer (OEM) customers. Invivo markets its instrumentation products primarily to various industrial users. Since introducing the first Philips light bulb in 1891, Royal Philips of the Netherlands has grown into a diversified technology company, focused on 109

116 improving people s lives through meaningful innovation in the areas of Healthcare, Consumer Lifestyle and Lighting. The company is a leader in cardiac care, acute care and home healthcare, energy efficient lighting solutions and new lighting applications, as well as male shaving and grooming and oral healthcare. Philips is providing the financial resources for us to use in order to complete the project. These financial resources can be spent on anything that goes into our project including software licenses, electrical components, production of PCB board, etc. Invivo is also a consultant for us and have already provided, or will provide, the following assistance. Offering their advice as experts in the field of patient monitoring in the MRI environment. Teaching us project management techniques and the project management lifecycle. Providing us confidential parts of the circuit board for us to use and modify, primarily because they already have similar projects to ours already in development. Our project will expand upon previous knowledge to be able to provide a proof of concept for a new technique in ECG filtering. We cannot release the circuit board parts that Invivo provides, since this is proprietary, but anything else that we make will be public since it is associated with the University. We will be traveling as a team to the Gainesville location to test our product. 110

117 15 Administrative Content 15.1 Milestone Discussion Our group had several milestones. These included our initial project proposal, four check-ups to ensure that progress on the senior design document is going as planned, a rough draft, a revision date our group sets to revise the document and a final revision date. After the final revision, everything was to scale, so our project was completed. Philips will continue our project by developing the Adaptive Filtering for MRI machines. We met several times during winter break and had a rough prototype of our final project prior to the spring semester. We also were able to ensure that our program meets all evaluation requirements. Then at this date in time we turned in our project. In regards to the design phase of this document, we had four check-ups for this document. The first check-up was on October 22 nd, 2013 at 8:00 AM to ensure that everyone finished at least 7 pages. We wanted to make sure everyone has 7 pages so that we can be aligned to finish prior to the deadline. The second check-up was on October 29 th, 2013 at 8:00AM to ensure that everyone finished at least 14 pages. This was to improve the quality of the design documents and ensure that everyone was able to complete their sections. Many of us have rather busy schedules and need a fairly tight schedule with regards to Senior Design to ensure that everything was completed on time. We will also be reviewing the pages and critiquing them and marking any necessary changes to the documents. We wanted to deliver the best possible product we can with regards to these documents. A lot of the research needed to be done at the initial documents date to ensure that we could complete the project on time. One of the biggest risks that we associated with this project is the speed at which we could learn the material. None of us in the group had any experience with image filtering and needed to learn everything to create this project. We also utilized a 3 rd party library to ensure the proper programming of the device. We had a third Check on November 7 th, 2013 at 8:00AM to ensure that everyone finished at least 21 pages. We also checked for any errors and created a more detailed view of exactly what we need for the project. This meeting ensured that our group is on track to finishing prior to December and that we had a week or two extra to spend studying on our other exams. We had a final page count check on November 18 th to ensure that everything is together and that everyone finished 30 pages. We also ensured that the appendixes were up to date and that all references were cited and that we were legally allowed to use any references that we have listed. We either got permission 111

118 from the entities provided to us with these resources or we ensured that the material we produce was fair use for the project. We also ensured that we are not missing any of the requirements listed in the document specifying this project. After completion of the design document our group implemented the design. To implement the design we had a prototype phase that was due before the start of the second semester, a prototype debugging phase was used ensure that all the code is written well and is very modular. The prototype phase essentially ensured that we had one filter set up with the hardware. We intended on testing with multiple different filters and hoped to ensure that the filter itself is simple to change. However, our first goal was to ensure that one filter is working with the MRI machine. This was initially going to be a non-adaptive filter as a proof of concept, but we were able to use the Least Mean Squares Filter to filter the results. After this development, we ensured that we had an adaptive filter working with the ECG. We attempted to measure the amount of noise removed and the visibility of any and all important artifacts, but due to it being worse than the linear filters this was not very effective. The next step is testing. While writing our programs, we used a Test Driven Development methodology, wherein anything worth coding is worth being tested. This will allow us to have tested software throughout the development cycle. Whenever we add a new feature, some of these tests will not always be accurate. When the tests were not accurate we fixed the problem immediately as we have a zero-defect policy. Later we used integration testing to ensure that each of the individual parts worked together in the system. After we completed testing, we ensured that Philips believes that our project meets all specifications. We ensured that Philips agreed with our choice of filters and that our product does the project s intended purpose. Other than these milestones which were required for completion of Senior Design I, we also sent periodic reports to Philips. Since we were being funded by them and they requested it, we only thought it fair to continue along this path. Every month we delivered an update to Philips of some form in regards to what we did with the project. This was largely related to the Gantt chart with our schedule for the project, however the dates were not accurately reflected by that. We wrote a report discussing the various things we did and/or researched. One of the main things we did for our project was figure out exactly what Philips needed us to do. This obviously required many meetings with them and the necessity of using some of their resources to get the project done. Some of the requirements for starting the project included signing NDAs so that we were able to get more information in regards to the project. They stated and sent us some of their knowledge of many patents that recently expired and we 112

119 certainly used these to aid the development of our Senior Design I project. As such another milestone was the completion of reading the materials that Philips sent us. The previous milestone was included with all research, but unfortunately due to the schedule of the receipt of said information, we cannot start until after we have already completed most of the other research. The next milestone was the completion of the Embedded System device. We needed to ensure the embedded system did not violate any of the requirements we had with regards to using the MRI machines. The embedded device was used in conjunction with an Analog Front End that was developed by the two electrical Engineers along with the hooking up of the embedded system with the MRI machine. They needed to check the voltage of each of the systems and ensure that the correct amount is being supplied to the device. Unfortunately, this was a problem and the device short-circuited after our presentation. For future senior design students it would be advised to add protection of incoming voltages to the device. They are simple to add in and invaluable in case something bad happens. We also had a list of tasks for each member to work on with regards to this document. The Required tasks are included inside a Gantt chart which shows everything each of the team members needed to do. We have divided up the work in an effort to be equal and pertain to each individual s unique skill set and interest base. The tasks for the Initial Project and Group Identification Document are shown below. 113

120 Figure 71: Task List for Project and Group Identification Document Further, we have a task-list detailing the requirements for the overall document. This is shown below. 114

121 Figure 72: Final Document Deadlines There is another document listing the deadlines for the entire project. This is shown below. 115

122 116 Figure 73: Senior Design II Project Deadlines 15.2 Budget and Finance Discussion This project was an idea presented to our group by Philips. As such Philips paid for any financial need we had. This project s goal is to deliver the best result possible; therefore we spent money on some devices more than once to ensure we had the best quality option. Philips will be furthering the project we make to

123 some extent and obtaining the best results is important. Essentially quality is the most important part of this project. The budget included driving to the MRI machine and of course the equipment we needed as a group. We were also planning on obtaining licenses for MATLAB and other required software for this project. However, this was not necessary as the school had MATLAB machines for us to use and we did not use the embedded coder. Our group created our own Analog Front End device for this project due to the requirements of the project and for correct patient protection. Creating our own Analog Front End gave us more customizability and potentially gave us better quality. The potential risk associated with creating our own Analog Front End was the cost of creating said device and ensuring that our device meets medical standards. These risks were alleviated through due diligence and the help of Philips in designing the board. Our total budget as of October 15, 2013 was $9,500 sponsored entirely by Philips. We were able to remain under budget despite having a rather expensive board. This budget will include two of every component to allow us to have a backup in case anything failed on our devices. We looked into several ARM processors, two of Texas Instruments Medical based processors. The device we ended up choosing was the Tiva C Series Developmental Board. We will also looked for the equipment for the Analog Front End. The Analog Front End required a circuit board, many wires for setting up the Analog Front End and a variety of other items. The items for the PCB are discussed in some detail on the budget sheets. One of the other items included in the budget report is the amount of money spent on gas to go to the MRI machine. Unfortunately, due to the current state of the project this was not necessary. However, luckily we didn t need to spend time driving there and testing on things that would not have been very fruitful. Another potential cost was the Licenses for software. This was expected to be one of our largest costs. However, due to the projects requirements and the materials presented for us we actually did not need to spend anything. All of the software was provided by the school or Philips to aid in the completion of this project. We coded the program in Embedded C++ and we found it useful to obtain a library that performs many of the adaptive filters for us. This library was CMSIS and luckily was free with the board that we chose. MATLAB was used to verify that the CMSIS LMS Filter was created correctly. Some other costs were required to order the board from 3 rd party vendors. We created the board layout, but did not be creating the board itself. As such sent out the board information to be created elsewhere and they will made it per our 117

124 specifications. The board needed to have multiple parts to it and was fortunately able to connect to Philips current equipment. Luckily, Philips knows several board manufacturers and were able to use their suppliers. The cost of the board is listed in the budget displayed in Table 6. Obtaining the boards and ensuring they meet the standards given by Philips was our most expensive task. As we are making them per a specific standard and must develop the given features required by it; the board will be very similar to a previously created board by Philips. Our board, since it will possibly be used in a commercial application must look professional and must operate flawlessly. This made our board rather expensive. Some of the costs are not included within our budget. These costs were covered by Philips and we unfortunately did not report them in detail. We also received one day shipping in a panic rush to finish the project. It worked! In the future our project will be using an MRI machine, but Philips owns their own MRI Machine. We have created an excel spread sheet with the costs regarding this project. Each of the costs has a reasoning detailing why it was needed and its designed purpose regarding this project. We also show the amount of budget that we are given and the total associated costs for the project. On the following pages is a detailed budget detailing the cost of various items for our project and reasoning behind each of the items. Unfortunately, the budget sheet is unable to fit on just one page and we must add a second page to include more of the budget items that we needed to purchase. These items were added after the original budget as more specifications were delivered from Philips. 118

125 Table 1 - Budget Sheet Part 1 Parts Price Quantity Total Reasoning Tiva Stellaris C Series $200 2 $400 Analog to Digital Converter $101 1 $101 PCB Components Varies 417 $1000 Circuit Board $750 2 $1500 The Stellaris C was a good representation of our project. To speed up development time two boards were needed. One for each developer. Luckily the Tiva Stellaris C board included an Analog to Digital Converter which removed our need to put together the one we ordered. The Analog to Digital Converter was going to be used to convert Analog data to digital. However, removing components from the board reduced the complexity and made it easier to implement. The total for the PCB Components was $1000. These were necessary to provide a working PCB. They included the resistors, the Digital to Analog converters and all other components in the PCB. There were 417 parts in the building of the PCB. The Circuit Boards were $1500 to print. We needed these to display our project and this needed to be professionally done as we had a 6 layer board with 417 components. 119

126 Table 2 - Budget Sheet Part 2 Parts Price Quantity Total Reasoning JTAG Programmer $79 1 $79 The JTAG Programmer was necessary to code the software onto our board. This was ordered last minute to finish the board. Total Cost Est. Extra $5580 $9500 $

127 16 Bibliography [1] N. Thakor and Y.-S. Zhu, "Applications of Adaptive Filtering to ECG Analysis: Noise Cancellation and Arrhythmia Detection," IEEE Transactions On Biomedical Engineering, pp , [2] K. Soundarapandian and M. Berarducci, "Analog Front-End Design for ECG Systems Using Delta-Sigma ADCs," Texas Instruments, Dallas, [3] N. S. Roger Arrick, "What is solderingand how do you use solder tools?," [Online]. Available: [Accessed 20 November 2013]. [4] A. Niebauer, "Cardiology Explained," [Online]. Available: [Accessed 30 October 2013]. [5] L. K. Muma, "Basics of EKG Interpretaion," [Online]. Available: [Accessed 19 october 2013]. [6] M. Lynch, K. Robinson, O. Ghita and P. Whelan, "A Performance Characterisation in Advanced Data Smoothing Techniques.," Proceedings of the Irish Machine Vision & Image Processing Conference, pp , [7] learnvst, "MATLAB Coder vs hand coding?," [Online]. Available: [Accessed ]. [8] K. S. Kreger and C. R. Giordano, "Bio-potential signal processor for magnetic resonance imaging". United States Patent , 30 June [9] A. Gupta, Signal Processing of an ECG Signal in the Presence of a Strong Static Magnetic Field, Orlando, [10] K. Coyne, "Magnet Lab," 21 July [Online]. Available: e.html. [Accessed 12 november 2013]. [11] A. Carusone and D. Johns, "Analogue adaptive filters: past and present," IEE Proc.-Circuits Devices Syst., vol. 147, no. 1, pp , 200. I

128 [12] A. Berger, "British Medical Journal," 5 january [Online]. Available: [Accessed ]. [13] S. Behbahani, "Investigation of Adaptive Filtering for Noise Cancellation in ECG signals," Second International Multi-Symposiums on Computer and Computational Sciences, pp , [14] Welch Allyn, "Welch Allyn," 16 january [Online]. Available: [Accessed 18 november 2013]. [15] United States, "United States FDA," [Online]. Available: ocuments/ucm htm. [Accessed 7 October 2013]. [16] United States Department of Health and Human Services, "United States Department of Health and Human Services," [Online]. Available: [Accessed 7 October 2103]. [17] Texas Instruments, "Texas Instruments," 13 july [Online]. [Accessed 12 november 2013]. [18] Texas Instruments, "Texas Instruments," 12 june [Online]. [Accessed 30 October 2013]. [19] Texas Instruments, "Texas Instruments," 09 april [Online]. Available: [Accessed 30 October 2013]. [20] AD1274 Datasheet, "Texas Instruments," [Online]. Available: [Accessed 15 October 2013]. [21] "Products and Services," MathWorks, [Online]. Available: [Accessed ]. [22] "Plant Model," MathWorks, [Online]. Available: [Accessed ]. II

129 [23] "Overview of Adaptive Filters and Applications," MathWorks, [Online]. Available: [Accessed ]. [24] "Model-Based Design Definition of Terms," Autonomie, [Online]. Available: [Accessed ]. [25] "Invivo Expression," Invivo, [Online]. Available: [Accessed ]. [26] INVIVO, "INVIVO," 17 july [Online]. Available: [Accessed 11 november 2013]. [27] PhysioNet, "Image Database," [Online]. Available: [Accessed 2 November 2013]. [28] "High Level Software Design," The-Software-Experts, [Online]. Available: [Accessed ]. [29] General Electric, "GE HealthCare," 12 July [Online]. Available: sting/mac_800. [Accessed 15 November 2013]. [30] "Design Control Guidance for Medical Device Manufacturers," United States FDA, [Online]. Available: ents/ucm htm. [Accessed 7 October 2013]. [31] "Build C/C++ MEX-Files," MathWorks, [Online]. Available: [Accessed ]. [32] "BitBucket Features," Atlassian, [Online]. Available: [Accessed ]. [33] McGraw-Hill Professional, "Basic Principles of ECG Interpretation," [Online]. Available: jenkins_ch01_p pdf. [Accessed 14 october 2013]. III

130 [34] Atmel Corporation, "ARM Cortex-M Optimized code from MATLAB," [Online]. Available: [Accessed 20 October 2013]. [35] Texas Instruments, "ADS8568 Datasheet," Texas Instruments, [Online]. Available: [36] Philips Corporaton, "Achieva 3.0T X-series MRI," [Online]. Available: [Accessed 7 october 2013]. [37] Philips Corporation, "accessory," [Online]. Available: [Accessed 7 October 2013]. [38] Hologic Extremity, [Online]. Available: Scan_Opera/SitePrep/E-Scan- Opera%20Site%20prep%20Hologic%20Rev%202.pdf. [Accessed 2013]. [39] World Health Organization, World Health Organization, [Online]. Available: [Accessed 19 October 2013]. IV

131 17 Permissions V

132 VI

133 VII

134 VIII

135 IX

136 X

137 XI