Pulse Oximeter project continued

I've decided to continue efforts on the pulse oximeter project. I'm now developing a solution that will integrated with a serially linked bluetooth controller to transmit data back to a home computer or mobile handset (iPhone, Android, etc.).

You can follow the progress of that project at:
http://pulseoxwireless.blogspot.com/

Heart Beat and SpO2 detection

I made some real progress this weekend in integrating the software to compute the heart rate (in bpm) and the blood oxygen saturation. I also made some real progress in reading real PPG signals from the TIA and providing dynamic gain. The pieces are coming together and a final blog update post will chronicle the past successes.

Heartbeat detection, reference:

A reference ADC sample had to be taken to determine the frequency (bpm) of the PPG signal. To do this, I used the function generator to drive a simulated PPG signal with a frequency of 2 Hz with p2p of 100 mV.

From this reference I noted that I captured 5 full periods. I then measured the index between from a peak-to-peak. In the image below, I measured from index 38 (with value 1286) to index 134 (with value 1312). This distance of 134-38 = 96 represents an index count of one full period of the simulated PPG. I also know that the repetion rate is 2 Hz so each full period represents 500 millsecond.

Now when I have a real ADC sample I compare the distance between peaks in this. In the image below, I measured from index 125 (with value 952) to index 325 (with value 967). this distance of 325-125 = 200 represents the index count of my pulse.

I now can set a basic porportion by stating that 96 index = 0.5 sec and 200 index = X seconds. Solving for X the result is 1.041 second. Therefore I noted that my pulse is 1 beat per 1.041 second or 62.5 bpm. This is a little under the average human heart rate of 72 bpm because I eyeballed last measurement.

Simulated PPG waveform

Real PPG waveform

Heartbeat detection, simulation:

Before I started implementing any code on the micro controller to analyze the ADC information I wanted to run a simulation. I started by writing my own program and creating a mock-array to mimic a PPG pulse ox signal.

I then started researching how to do peak detection in LabVIEW environment. Peak detection is very common in Signal processing and there was an abundance of resources on the topic. I quickly discovered the Peak Detector .VI in LabVIEW. This is a really cool VI which interpolates your data as a polynomial then takes derivatives to find maxim and minim points. I found a good example provided in the SDK which I just modified around my simulated pulse ox signal. Here is an image from the result:

You just specify threshold for max and min and it calculates valley and peak and puts the index and amplitudes in corresponding arrays. Knowing this, I really wanted to use it to implement the solution on my micro controller.

Heartbeat detection, practice:

I quickly ran into some problems when I tried to use this .VI on the micro controller. It appeared that it wasn't processing the data. I examined and googled the error result "-20001" and discovered this is the code for OUT_OFMEMORY error. I knew I would likely hit this point at some point as my program had really grown in size. I tried to slim down my program by deleting unused memory allocation routines but to no avail.

This is the biggest drawback in my opinion of developing in the LabVIEW environment. In a C environment I would quickly be able to diagnose this error and make a creative solution. But since I have no idea how memory is allocated by the high level (it should be dynamic and typeless to prevent memory leak) I simply cannot use this VI.

I was really disappointed so I had to create a new way to detect peak and valley. The solution I came up with is kind of elegant and will work. Here is how it works.

1. Sort the ADC array in Ascending order (low # first, high # last).

2. Reverse the order of this array to descending (high # first, low # last).

3. Index into element [0] to find maximum value in ADC array.

4. Now must check over the entire ADC array, let iteration count be represented by element j.

a. If ( (ADC[j]>ADC[j-1]) & (ADC[j]>ADC[j+1])) then element represents peak.

b. If ( (ADC[j]

I then have this basic delta detection scheme to determine distance (in index) from peak-to-peak or through-to-through. Now that you have this number you compare it to the reference spectrum calculated earlier. Like I said earlier, from reference we know what a period in index corresponds to so it's really easy to calculate Bpm from this.

I haven't finished writing code for SpO2 calculation but it's very easy from this new module. The new module can easily calculate max and min and can take ratio of these elements.

I think my biggest concern right now is time. Can I put this all together and have it working by Thursday. The one thing if I had more time is I'd make it more robust and reliable. There are odd quirks that I wish I could diagnose better.

Clock Timing nightmare

Hardware:

The clock circuit presented last time had problems. The two new clocks were non overlapping but due to the delay introduced would try demodulating the wrong channel. I tried re-working the circuit by delaying the LED driving clocks. In the end, this approach was just too complicated and I abandoned it.

As a replacement I adopted a circuit designed by Shanit. A relaxation oscillator was combined with a 555-timer in monostable operation to one shot a variable duty cycle. This output was then passed through an inverter. The result is a de-modulation clock with reduced duty cycle from the original CLK but not overlapping onto secondary channel.

What I learned: If something is starting to appear too complicated, ditch it and adopt the simpler topology.

Below is a schematic of the circuit I ended up using. The datasheet recommended I use a 1 uF with 5k POT to create a variable duty cycle. I built the circuit on the breadboard and have been using that to test the overall system. On Monday, Jon will construct an actual board which can be mounted on the POX board. Another great idea adopted by Shanit was to cut the Enable lines (EN1, EN2) and use them for the S/H demodulator clock line. In this way, the board won't look like such a hacked together nightmare.

There are a couple last minute changes Jon and I will be making to the board next week. We'll be fine tuning the gain of the TIA section and maybe making fine tuning changes to the LP filter.

Software:

Some tremendous progress was made on the software solution. In the last post I had discussed the DC detection, automatic detection and PGA gain. I've seen some other interesting solutions and am confident in my result. For instance, team Tango has a step-up PGA gain going from (1,2,5,10,20, etc.) till it reaches max rail. If I could return, I would most likely implement this solution. I like the elegance and the fact that it requires almost no error checking code.

My efforts last week:

1. Implement detection, subtraction, and PGA on both channels. Complete

2. Implement TCP/IP send back for both channels. Complete

To test this I drove a simulated PPG signal into the DC subtracter circuit and let my program run. It was actually very easy (think Copy/Paste) to implement the Ch2 code. I have a parallel system now where all actions are taken side by side in steps.

My focus this weekend and the next week is as follows:

1. Implement a peak detection scheme to calculate heart rate (in bpm).

2. Use peak detection scheme with a newly created SpO2 .VI detector to output the saturated blood oxygen level.

3. Fine tune the software to make it more/less aggressive. Right now, the output from the TIA is about 50 mV p2p so the gain is really trying to do gain 100 or 200. There are times when the output saturates which means I need to write error detection.

4. Error detection code.

I've created a thorough simulation of both of these components in LabVIEW and will update tmmrw or Sunday with a showing of the program. Basically, I wanted a test bench to test this code on my computer before I push changes to a micro controller.

I'm trying to figure out if any of these simulations or code would be helpful in an open source repository. I'd like to provide some thorough documentation and upload them as a project to Sourceforge or the LabVIEW example database (I wanted to check licensing agreement).

If anyone reads this blog and wants to contact me, my email is nlshrake@ucdavis.edu.

Non overlapping Clock generator

The design of this pulse oximeter called for a two phase non overlapping clock. Initially, our design had called for a simple oscillator circuit with an inverter. We found that the both clocks could be high at the same time presenting problems in demodulation for dual channels.

Therefore a non-overlapping clock had to be implemented. Initially I was going to use a 555 timer but I had difficulties finding resources on how to implement non overlapping clock. Non overlapping clock is very common in digital circuit so I found some resources from my Rababey book. It's often used for charge pumping and evaluate circuits.

http://books.google.com/books?id=vxGO4_B98gsC&pg=PA103&lpg=PA103&dq=non+overlapping+clock+nand&source=bl&ots=4k8qTqHc4v&sig=Pe_qcwaTse9pUWvxxnl4285c4W8&hl=en&ei=7OD5S9KCDIO8M93o7YMI&sa=X&oi=book_result&ct=result&resnum=6&ved=0CDEQ6AEwBQ#v=onepage&q=non%20overlapping%20clock%20nand&f=false

I have attached an image of the schematic and the resulting simulation. I built and tested this on the breadboard and had success. I was able to verify that with this design the clocks are indeed non overlapping. This week we will build an external circuit which will do this and can hook in with the POX board. Jon will update with progress on this front later this week.

TIA status and Software Update

TIA Update:

Since I haven't updated in so long I need to address some of the issues we had with the TIA and how we fixed them.

Initially we had implemented the TIA section using the OPA350 chip. The problem with using this chip was that it could only deliver a differential output voltage of 7 volts. As our POX board is designed with a VCC of +5v and VEE of -5v this chip wasn't right. Therefore, we tried implementing it with a more expensive chip, the OPA121. A problem was quickly encountered with this chip though. This chip requires use of trim offset to and as our layout leaves these nodes floating it simply would not work. Instead, we switched to a AD795 which finally worked.

Upon testing with a feedback resistor of 500k (expected gain of around 1e-6*500e3 = 500 mV) I found that there existed considerable overshoot/ringing occuring. I knew that I needed to compensate the gain stage as the Phase Margin was too close to zero causing instability in the loop. I kind of guessed on the first value picking 100 pF. I noticed that the ringing was depressed but still occurring. I therefore changed it to 50 pF and found that the ringing all but went away.

The signal amplitude was to small to discern the pulse. I changed the feedback resistor to 4 megaohm. I once again observed ringing so I divided the capacitance by 8. I know this isn't an exact science so I figured brute force method like this was appropriate.

I was able to clearly discern the pulse when looking on the scope but am thinking I could perhaps even provide more gain. This week I will try further increasing the gain to perhaps 6 megaohm.

Software Update:

Most of my effort in the past 3 weeks has been focused on development of the integrated software solution. When I last updated I had implemented a SubVI capable of taking an array of integer ADC values and producing a DC offset value. In this entry, I'd like to update with success and challenges faced in implementing the ability of DC subtraction and PGA gain.

First, it was rather hard to debug this program. The JTAG debugger will not pass back array contents to the front panel so there was no real way to verify if the data was being correctly stored. I ended up testing that data was in fact being stored in an array by using the OLED screen to print random indexes in the array and matching them up with a Oscilliscope output. Later, a program developed by our T.A. Cevin allowed us to send this array data over the micro controller TCP/IP to a local computer on a network. This will be a very cool addition to the program as it will allow us show the user their pulse in real-time.

Having cleared the hurdle of DC tracker I now wanted to implement the DC subtraction. The route I decided to go was to slowly decrement or increment the DC offset based on the current DC offset from the IIR filter. The problem I found with this solution was speed. It's just way to slow to decrement or increment the DC value based on current input. A solution I came up with was to quickly change by 20 if we're far away but to change by 2 or 3 if we're close (say within 25 of 2048 (2.5v)). This solution seems to work ideal, in my tests on different sinusoids of amplitude 100 mV, 200 mV, 500 mV, and 1 V it seems to get a lock to 2.5v within 10 seconds. I've attached a video of the program in action.

http://www.youtube.com/watch?v=olOcnDb8L2A

Having completed this I moved onto the PGA code. This was rather simple to implement as I used the PGA simulation from an early blog post. I quickly found that the ideal environment however simply did not work on the micro controller.

What I initially had envisioned was that the program would provide enough gain and then recenter the signal back to 2.5v. After a little bit of debugging I found that changing the DC bias from where I initially provided gain would move rapidly move the DC rapidly back and forth. This makes sense because there exists DC on the line when I provide the gain so adjusting the DC (even a small amount) will get amplified by the gain set on the PGA. As a solution to this problem I simply prevent and DC subtraction after a gain is provided. I think this is a fine solution as long as frame based processing is being used. This means that whenever a new frame is taken the program must calculate an appropriate gain.

There is a tremendous amount of work that needs to be done with the software. Right now it's perhaps to aggressive. I did testing and found that sometimes it gets really close to rail and clips or even saturates. I'll need to fix this in the coming week. I also need to start testing this on a real PPG signal instead of a sine wave.

In the coming week I will first examine an ideal PPG signal provided by function generator and then try out our actual signal.

I'll update on Monday with our teams goal for the upcoming week.

PGA Simulation LabVIEW

A simulation was run to mimic the future role of our software. Having implemented DC detection we can now determine the DC bias from the ADC. In the future this software must be able to detect the DC bias and attempt to remove it by writing dynamic software to control the DACs. In addition the software must be able to detect the peak-to-peak signal amplitude and reason how to provide gain. Gain is provided by using a Programmable Gain Amplifier (PGA) to provide gain in steps.

The first simulation ran demonstrated what the PGA will do. A sine function with a random AC amplitude (0 to 100mV) was generated. I then built a stage capable of detecting the peak-to-peak AC amplitude. I then used a for loop to run through each PGA options (1, 2, 5, 10, 20, etc.) to check if the signal was above 5 volt. If the signal was less than 5 volt then it is selected as the true PGA. In the figure below you will see operation of several different simulations. As you can see, with different random AC amplitude the gain is dynamically modified.maximum dynamic range of the signal would be 5 v.

The simulation below show the response of the simulation to different initial signal AC amplitudes. As can be seen, a smaller AC amplitude will allow a higher gain value.

PGA Simulation Sunday Update

This weeks goal for me was to work on a PGA simulation labview program. The hope in doing this was to lead to possible solutions in actual implementation for use of the PGA. These solutions could then be incorporated into the overall program. The PGA simulation did not progress as much as I would like, although it is a work in progress. Below I have listed questions of my struggles that I have posed to my team members...

1) As for the randomness of the amplitude of the signal, I have a bit of code in there that provides randomness, although is not hooked up to the sine wave just yet.
a) My first question about it, is that it is giving me integers, and I am not all that great with the types, so I am wondering if there is a way to make it do decimal values rather than U32 values.
b)My second question is that when I attach it to the amplitude, I need a way to have it pick a random number only once rather than constantly changing the amplitude. I am not sure how to do this. I am thinking of using a loop to only make it grab one of the random values, but still am uncertain of how.

2) The sine wave seems to be a nice wave right now. It was a bit tricky for me to get the max and min working, although, it does give me max and min values of y and x separately, which is neat, (i.e. ymin and ymax and xmin and xmax). This is really useful.
a) I have used this to my advantage of taking the ymax and using logic to see if it falls within a range of values (right now I have it set in a range of 4.75 to 5 V, which will likely need to be changed later so there is less error.) With this being said, when it is true, it goes to a true/false case where true does nothing and false has logic further asking if the value was less than 4.75 V, and I would like this to multiply by a particular number to act as the PGA does, so in the first case, multiply by 2. I have the ymax go into this case, but I don't know quite how implement this with having an array of values coming in.
b) The array of values need to be paired back up with the time values. Not certain of how to do this.
c) Of course, with each trial check through the PGA, the gain (or number multiplied by will need to change). Again, I think that this is some sort of loop where i increments (maybe for loop), but I need help on figuring the increment portion.

3) I have not looked at the implementation of adding a DC value for smaller adjustments just yet. Also, it can be noted that for now, the signal is starting out at 2.5 V as it would be assuming that the DC finder was working at this stage.

During lab, I will meet with my team and see what advice they have. Hopefully by the end of lab, there will be a running PGA simulation that fully works.