BME Project 3 Writeup Preston Hoang (ID: 58904993) Alex Almanza (ID: 32214258) 

 Dear Eric Mikula,  

For this project, we are tasked to reliably measure a patient’s heart rate using LED lights and an Arduino Board. In order to accomplish this, my group partner and I designed an algorithm that “cleans up” the input data (waveform) from the A0 pin. To fully explain,  our cleanup removes fluctuations from the signal’s raw data by way of mean subtraction and 11­point filtration. What is obtained from our cleanup is then detrended, thus giving a waveform with peaks that are all of similar height. From there, the signal is then checked against multiple sets of criteria to see if it is of  “good” or “bad” quality. Specifically, our program checks the following:    

(1) The standard deviation of the autocorrelated signal’s periodicity. (i.e. Does the data correlate to a rapidly changing heart­rate atypical to a human?)  (2) The area of the ABS detrended signal.  (i.e  Does the area exceed a certain threshold, thus indicating large variability between the highs and lows of the data?) (3) The range that the heart­rate data falls within. (i.e.  Is heart­rate within the 40 to 240 heartbeats per minute characteristic of a normal human? ).  

 Through these multiple checks, we hope to give the patient the most accurate reading 

possible. Hopefully, this device will make it easier for doctors to give a proper diagnosis to the patient. Based on the project’s instructions, we integrated data logging into the heart rate data by exporting it into an excel file. Moreover, with the help of a $5 app called TouchOSC, we created a means by which doctors can view a patient’s heart­rate in real­time from their iPhone.   

 How it works 

To obtain heart rate readings from our device, a user places their finger on a photodiode while light from an LED is shined from above. Surprisingly, my partner and I found that the best source of light for obtaining a quick and reliable heart rate signal did not come from an LED wired to our arduino.  Instead, we found that the LED obtained from the “flashlight” function on the iPhone 5 gave a sufficient amount of light to instantaneously find a user’s heart rate. Since our device is equipped with an app that displays the user’s heart rate data, we feel as though our device would be marketed with the intentions of being used exclusively by iPhone users. That way, a minimal amount of supplies is needed for our device. 

 When the program starts to run, it goes through initializing the Arduino and setting it so 

acquires continuous data. The usual parameters, like how samples to read or which analog pin to read from, are all included in the project’s block diagram and front panel. The program then starts building waveforms associated with the LED light’s intensity as follows: 

 From there, the array gets “conditioned” so that it meets certain specifications for further 

analysis. To begin the conditioning process, the raw signal is subtracted by its own mean and is filtered by an 11 point moving average. This filter takes the average of one particular point, and 

five data points to the left and right. This average becomes the new normalized point, which corresponds to that one particular point. It is then arranged into a new sub­array which removes the first 11 points from the waveform (an artifact of the filter).   

 After the array gets conditioned, it is then detrended so that the peak­heights of the 

waveform are similar. Essentially, the signal’s linear trend is subtracted to the signal itself. The following images show the process in more detail: 

 

 

 

Sub VI:  

 

 The detrended signal then goes through its first quality­check. From Prof. Botvinick’s 

algorithm, the signal’s absolute value and the area under the curve is measured. In 90­95% of cases, if the area calculated is greater than some threshold, it is rejected as a bad signal. To give a brief explanation, if there are frequent, massive “jumps” in the filtered signal (bad), the area reported should be a high number. Conversely for better signals, if it stays within a more stable range, the area calculated should be a low number.  

     Later, the signal is then normalized and the auto­correlation waveform is then 

determined. What this process does is that it maps a new waveform based on the existing signal. Fundamentally, it takes the average product of the array value at a certain index, and another array value separated by “J” indices. If the value is at its largest (assuming J > 0), then the “J” value corresponds to the periodicity of the signal. Bigger “J” values that correspond to the local maximum of the autocorrelation waveform are multiples of the signal’s periodicity. The following code and formula was used in the development of the code:   

 

 

 The autocorrelation signal is then fed into the HR Calculator subVI, which calculates 

where the peaks are detected and their corresponding indices. Primarily based on Botvinick’s code (with minor modifications), it then calculates the heart rate by finding the difference of these consecutive indices, multiplying it by dt, inverting it, and multiplying it by 60 to get the frequency in beats per minute. This process gets repeated in a for loop (depending on the 

amount of peaks), and the heart rate data is stored in an array. The average is then calculated from there.   

   After this subVI is executed, the heart rate data (labelled under “Heart Rate (RAW 

DATA)”) goes through another quality check. In normal circumstances, the human heart rate does not fluctuate rapidly from one moment to the next (e.g. one patient’s heart rate is at 85, 83, 80, 81 in BPM). To check the HR data’s periodicity, the standard deviation of the array is calculated and is compared against a threshold. If it is above that threshold, the signal is rejected. Another criteria to check is the number of elements in the array. Typically, if our program picks up an extremely aperiodic / unreliable signal, then there’s usually zero or one element(s) in the HR data. Signals that fall in the aforementioned category are also discarded. The range of the average heart rate is also accounted for in this program. Unless one is a trained athlete, the normal human heart rate at any given moment should fall between 40 to 240 BPM. If the calculated average exceeds this range, then it is most likely due to faulty readings from this program — the corresponding signal is deemed questionable and is thereby rejected. 

 

 

 All the conditions mentioned earlier are stored into boolean arrays for final analysis. In 

other words, each index within the boolean array correspond to conditions that determine the quality of the signal. This boolean array is funneled into a “for loop” which serves two purposes (1) to print out any comments on why a signal is good or bad and (2) to check to see if the signal passes ALL the listed criteria. If it fails even one criteria, it is rejected as a bad signal. Naturally, there should be some justification on why the threshold for a good signal is so high. As the professor mentioned earlier in lecture, it is a good idea to reject some high­quality signals if it means filtering out all the faulty signals. An accurate diagnosis for the patient is completely dependent on reliable, accurate data.    

 If the signal pass through all the quality checks, the program prints out a “Good job!” in 

the front panel. The LED lights that represent “Keep!” or “Reject!” are fairly self­explanatory. Moreover, if a signal passes our quality tests, the corresponding heart rate is saved to a text file for later exporting and analysis within MS excel. The coding we used to achieve this is essentially a replica of the one used by Prof. Botvinick. Where our code differs, however, is in how and when it decides to save the data. In our code, we use the same logic that decides when a signal should be kept to also decide when a signal should be saved. This way, only the heart rate data corresponding to values actually corresponding to the patient, and not machine error, is stored for later analysis.   Bonus Feature: Sending Real­time Heart­rate Data to an Iphone  

With the help of the open source programs TouchOSC and TouchOSC editor, as well as alterations to freely available LabVIEW code found online, my partner and I were able to design an app that allows a doctor to remotely monitor a patient’s heart­rate. 

 In the previous image is the section of our code that transmits data to a user’s phone. At 

(A), the program initializes what is called User Datagram Protocol (UDP), which is a special type of network protocol that allows users to send and receive packets of data from other computers on the same network. At (B), the data packet is constructed in the format Open Sound Control (OSC). Also at (B), the type of data to be sent and the address of the data pathway within the app are defined. Then at (C), the data is finally sent.  

  

  

  

 

In the image to the left is a screenshot of the editor we used to create the interface for our app. In the image to the right is a screenshot of what the user will see on their iPhone. Clearly indicated on app is an interface with the tile “Heart rate” which displays either a live heart­rate reading or the last recorded heart rate value, depending on if whether or not the device reads a signal during that given moment.