Weekly Reports

The week began with thinking of design solutions. So far, we have divided this up into two steps: the obtaining of the motion artifact signal and the cleaning up of the PPG signal. We determined that our solution needs to be a combination of quantification and processing of the motion artifact. After discussing potential options, we decided to go with using an accelerometer to quantify motion.  

In order to implement testing, we set up a meeting with Professor Widder to discuss data logging and visualization options. We discussed using Lab Chart, Arduino, and Raspberry Pi as options, and ended up decided that for our shortened time frame, it might be necessary to combine the initial data acquisition process through Lab Chart and a more refined data acquisition method through Raspberry Pi. We also obtained swipe access to the MEng Design Space. 

Lastly, we sent a clarifying email to our client about his wishes about the final interface of the product. We were unsure on whether or not our client would want our final design to interface with existing hospital software, and whether this would be feasible given limitations on . On the other hand, if this device is going to be used only in a research setting for now, we can design our own software to collect, display, and save the data.

We began the week with a meeting with our client. In this meeting, we discussed methods for data collection, retention, and logging. The hospital uses a specific Phillips IntelliVue software, however the information needed to intercept data and perform permutations on it is proprietary. Because of this, our preliminary development will utilize LabChart as a recording and display interface. Data will also be saved from the software for further analysis. 

Later in the week, we began looking for an accelerometer that best meets our needs. We decided that we should use an accelerometer with a gyroscope, in order to record the most information, so that the motion data could be best analyzed. Once our accelerometer is ordered, we can begin experimentation with both the pulse oximeter and the accelerometer.

This week began with a discussion of parts to buy for our accelerometer with Professor Widder. We decided upon the ICM-20948 from Adafruit, which offers 9 degrees of freedom and is relatively inexpensive. This accelerometer also has a low profile. We also discussed methods for data collection further, and researched some free, publicly available coding based methods in Matlab and Python. 

Work also continued on the progress report. Pugh Charts were created for hardware, software, and algorithmic solutions. It was decided that Siyuan will give this presentation and Abby will give the final presentation. 

In the next week, we hope to obtain the accelerometer and begin data collection and prototyping.

This week began with finishing up our progress report. Siyuan gave our progress presentation on Monday. Having completed these tasks, we decided to order the parts for our first stage of prototyping. We ordered an IMU, USB adapter, and extension cable. In this training stage, we plan to do initial data collection with the accelerometer and the pulse oximeter, and therefore will need to complete the code to do so in the coming week. Once we have a proof of concept, we will contact our client and test our setup in the clinical setting.

During the last half of this week, we received our parts and began putting together our initial design. We connected our Adafruit ICM-20948 with 9 DOF to the Adafruit RP2040 QT Trinkey with a JST SH 4-Pin Cable. The Trinkey plugged into a USB-A input on a laptop. To test the initial connection, PuTTY was used in the serial connection setting. Then, we tried to implement the Matlab code. Unfortunately, we could not get this code to work, so we moved on to testing a Python script. We first used CircuitPython in the Mu environment to better understand how the packets were being transmitted. In this, we were able to collect x, y, and z acceleration data as a tuple. However, CircuitPython was not good for implementing algorithms and real time plotting, so we then turned to the PySerial package. Using this, we were able to import the same acceleration data and plot this data in real time with about a 10 second time delay. This next week, we will contact our client and let him know we are ready to do initial collection with the SpO2 data, as well as work on decreasing the time delay in the real time plot.

This week, we worked further on our real time plotting script. We were able to get the time delay down to almost under a second, which is a big improvement from last week. We also are working on updating our script so that it is able to collect data from the SpO2 reading. We communicated with our client and are going to the NICU next week to do initial data collection with SpO2 and accelerometer data. The goal of this is to make sure our collection script is compatible with the SpO2 data packets and to collect and store SpO2-accelerometer correlated data.

On Monday, we met with our client to do an initial data collection. We prepared
the hardware in the previous two weeks, and printed an enclosure that attached to the
pulse oximeter. Code was prepared with the intention of being able to collect both
acceleration and SpO2 data in the same script. Upon arrival, we were able to establish
a connection in the COM5 port with the Philips Intellivue monitor in PuTTY, but no data
was being printed. We guessed this was due to an internal protocol in the monitor,
because we were not specifically requesting data packets. We then found an open
source C#.Net program that was able to request data packets. This program collects
both SpO2 and PPG waveform data. By the end of the meeting, we were able to
simultaneously collect accelerometer data and SpO2/PPG data using both programs.
Our intention now is to be able to match up these files according to time and do initial
algorithm testing. While the algorithm is in development, we will also develop a program
that translates or interfaces between these two programs so the final product will only
need one script to run. Later in the week, we also went over verification and validation
steps for our report.

This week focused on development. Siyuan finalized a design for the accelerometer case. This iteration was a resin 3D printed slide in design and consisted of 1 part instead of two that snap together. Abby worked on finding ways to integrate the C# and Python codes and now has several routes to choose from in doing this. We have no questions at this time.

This week focused on code development. We found an open source python project on github that integrates with the Phillips Intellivue system. While trying to integrate this with our existing code, we have been running into issues regarding package dependencies and updating this project (it seems to have been built on an older version of python).

This week was focused on code testing and data gathering. We began on Monday by going to the NICU and trying to test code we had developed in the previous week. This was a Python program we had found and tailored to our needs, however, it could not establish a proper connection to the Intellivue system. For the remainder of this visit, we focused our efforts on doing a longer data collection in order to have more available data for algorithm development. The rest of the week we researched potential options for our program. In the coming week, we will begin algorithm testing with our collected data and continue program development.

During this week, we finalized code for real time plotting. After trying to write and use a few programs in one language, we decided to combine the two programs that were already working. Now, the C# code from github will write to a csv that the python code will read the most recent line from in real time. Then, the python code can extract the data necessary to plot and plot this with the accelerometer data it is collecting.