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.

Progress Report Update

We made some good progress in todays Lab meeting. Our efforts are now focused on development of the software for interfacing with Channel 1,2 and populating the rest of the board.

Today, Jon populated channel 2 on our two development boards. We replicated the original component values that were specified in the initial channel 1 design. We hope by making this choice that software design will be simplified as hardware will be uniform.

Today, I continued my effort to implement my Digital IIR Filter on the micro controller. In my last post I documented the development cycle of a simulation I ran. The actual process of implementing the subvi on the micro-controller was difficult.

The problem I ran into was trying to verify that the ADC values were in fact being sent to an array. It's critical that the values be stored in some dataset because the digital filter operates on past values. I discovered that the JTAG interface does not send array contents back so the VI front panel was not updating. A quick hack suggested by Cevin was to use the OLED to display array contents. I had the screen output the i-1 item in the array so that it was always displaying the previous updated array item. In this way, I was able to verify that the data was being stored. After concluding that the data was stored I proceeded to implement the DC Filter as a subvi. Everything worked out of the box and the program now shows a DC offset from output of ADC.

In the future, I'd like to link the ADC array output back to the computer so I can debug more thoroughly and plot the ADC output.

Goals for next week:

1. Fully operational TIA section. I will be going back and increasing the feedback resistor to bring the signal closer to 5 volts. I'll likely need to performing a stability analysis and perform some form of compensation to decrease the oscillation. I will provide an update later this week on my efforts.

2. Improve performance of POX Software Controller. Right now I've split many of the components into SubVI's. Now that the program can determine DC bias I will be creating a software solution to modify DC bias dynamically from this input. For instance, today in lab I observed that the output from the DC Tracker was 2240 corresponding to analog voltage of around 2.69v. In the future I want to be able to push this DC offset to 2.5v so I will have to dynamically modify the DAC value for DC subtraction.

I will also this week be integrating this with the ability to increase gain in the PGA stage. I had implemented the PGA as a SubVI but this isn't working. I think labview doesn't like elemental IO pins in subvi so I need to figure that out. So goal this week is to be able to give a PGA gain of 200 and keep DC offset at steady 2.5v auto.

3. Jon is work on testing the channel 2 and fixing all problems.

4. Megan is running a simulation in LabVIEW. The simulation will entail a mock gain session on a sinusoid with a random AC amplitude. The program will be adaptive and try to take full scale of the ADC. Therefore, the program will required some conditional logic to determine if PGA is possible if it won't saturate. The program will also have ability to add smaller AC bias from increasing brightness of LED.

This is really just a simulation but the reasoning will serve how we make our adaptive process to modify parameters to get full scale performance from ADC.

DC Block Digital Filter Simulations

Progress was made in regard to implementation of the DC Blocker and detector. As explained previously, we want to take full advantage of the ADC so we use a PGA to provide a variable gain. The PGA operates on a reference DC bias of 2.5v and provides gain to any AC on this DC line. However, the signal that arrives from TIA and after S/H circuit has some random nonzero DC bias associated. This DC bias needs to be detected and removed to analyze just the AC component.

While an analog filter could be used to remove the DC, an analog circuit would have to be developed to detect DC bias. A better solution is to implement a digital filter on chip. This was accomplished with minimal experience with DSP. An IIR filter was simulated first in MATLAB to quickly analyze and confirm results. Then the solution was transfered to a LABVIEW environment as will eventually be encapsulated as a Sub-VI for integration in full software.

DC removal transfer function:

DC Tracking transfer function:

To simulate with MATLAB the transfer function was implemented in the 1D filter function. A link is provided below.

Figure1,2: Random 1 volt bias applied with DC tracking no noise. Random 2.3 volt bias applied with some noise.

http://www.ece.ucdavis.edu/~shraken/code/eec136_dc_design.m

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/filter.html

Next, I worked to implement this in the LABVIEW environment. I ran into early problems with lack of documentation. I desired a solution as simple as MATLAB's 1D filter function that allowed me to simply specify filter transfer function coefficients. Most IIR filter examples I found for LABVIEW were about using Elliptical, Butterworth, etc. filters. I did finally find a control 'IIRFilter' that allowed me to specify forward and reverse coefficients. The result is presented below.

I wanted to leave some space to discuss issue of precision. MATLAB and LABVIEW allow for 64-bit double precision. But on a DSP chip the precision might be much lower. Our design was simple enough with a low precision coefficient (alpha=0.9). I will comment in more detail on this in a later post.

Further Discussion on Software

As Nick discussed in his previous blog, we have been working on being able to operate all 4 DACs in such a manner that we can dim the LEDs as necessary using DACs 3 & 4, and be able to subtract out DC values using DACs 1 & 2. As of now, we have a program that allows us to run through the DACs, changing input values as necessary. In the near future, this program will need to be implemented in a manner where there is no longer a user defined interface, although that the computer will be programmed in such a way that it is making all of the necessary adjustments to our heart monitor signal through input coming from the ADC.

Problem statement #1: The ADC will take in an input signal, which will be analyzed. In the computer analysis, the signal will have an AC signal riding on a DC value. This exact DC value must be subtracted out, so that the signal sits on 0 V DC. This is important so that later in the system, the signal can be biased to 2.5 V allowing for the signal to swing in a dynamic range of 0-5 V. Build a program that allows the computer to calculate this DC value and is able to increment or decrement the DC value in order to have the signal sitting at 0 V DC.

Problem statement #2: As mentioned above, this signal will eventually be biased at 2.5 V. The signal then needs to use the PGA, or programmable gain amplifier to adjust it automatically to swing from 0-5 V, without having saturation.

Problem statement #3: Included above is our thoughts in having need for operating all 4 DACs and eventually operating them solely with the computer and no user input interface. This is another challenge to overcome.

Team Sierra is making progress in software situation, and most importantly identifying what the problems to overcome are. Before implementing ideas, it is important to explore the potential problems and come up with solutions to those problems. For example, it may be easy enough to identify a DC value from knowing the maximum and minimum values from peak to peak of our signal range. We would need to take a sample that would be inserted in an array to allow us to do this. However, we would also have to take into account where the minimum DC value starts from. We may find the DC value from peak to peak to be 1.5 V, although the minimum value may be sitting at 0.5 V to begin with. We must be careful for troublesome points such as this. In dealing with the gain, we must decide whether the computer program will be allowed to saturate before it decides that it needs to go back one gain setting. We must make careful adjustments to the PGA. All different scenarios must be considered.

LABVIEW control

Megan and I have been working on the ability to control devices on the POX board. In the near future, a software solution will be developed to adaptively control all devices. This first bit of test code is meant to demonstrate abilities and help test and debug.

The program below offers control of all 4 DAC's. DAC 1/2 represent Channel 1/2 and offer ability to specify DC value to subtract. DAC 3/4 offer ability to control brightness of LED by adjusting bias voltage on base of transistor.

In the next work we will be integrating this control with the ADC and PGA. The adaptive software will act as a feedback system. The goal is to get maximum performance of ADC. This requires true DC subtraction and for the PPG signal to operate rail to rail (0 to +5v). To accomplish this we will have three (2) routes.

(1) modify PGA gain. This will allow major gain but steps (1, 2, 5, 10, 50, etc.) limit the maximum gain as we can't saturate.

(2) modify the brightness of LED. This will allow minor variations.

Trans impedance progress

Today I populated the trans impedance stages. I knew from earlier experiment that a photo diode of similar specifications provided a 88 uA current for an enclosed setup. This enclosed setup mimicked the shielding provided by the probe. I also had to fix the V(+) and V(-) error by cutting traces and rerouting. I followed the guide that was posted under TIAfix.pdf.

The two stage differential trans impedance amplifier above allows for current to voltage conversion with elimination of common mode noise. While both stages can provide gain, I choose to provide gain in stage 1 and have stage 2 as a differential follower. I wanted to bring the output voltage to about 500 mV. I selected a 20k resistor in the feedback path to provide an estimated output voltage of 1.7 volt. The second stage will act as a differential follower such that the following is observed. I chose R1 = Rf = R2 = Rg = 50k.

To test the operation of the trans impedance stage I performed the following. I drove the CLK1,2 lines on the POX board with +5v square waves from two function generators. I then use micro controller to program DAC3/4. This allowed modification of brightness of LED in probe. I then turned on the probe and observed the output from S1out, S2out, and AmpOut. As I was driving with a square wave I expected to see the same waveform (freq) on scope. I found the amplitude was below my expectations and actually was around 750mV.

The capacitors CTI1, CIT2 are implemented for stability concerns. The challenge is to prevent oscillation from occurring causing overshoot and ringing. I am preparing notes on this with details to our implementation. I will also include in these notes details on elimination of common noise and why differential amplifier is preferred selection.

http://www.ecircuitcenter.com/Circuits/opitov/opitov.htm

I'm starting to look into software and have found some good links on DC removal for DC subtraction. Today I played with implementation in MATLAB. A 1D IIR filter can be implemented easily in MATLAB. Once we have good result in this respect we can transition development to LABVIEW environment.

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/filter.html

http://www.mathworks.com/matlabcentral/fileexchange/13792-the-dc-blocking-filter

EEC136 LED Driver and Trans impedance update

The LED driver circuit was simulated and populated this week. An early problem encountered by Jon and I was that with no LED's as a load the circuit demonstrated erratic behavior. Without the probe plug, the supply produced by the regulator dropped below +5v. The DAC's also failed to provide full supply. The LED driver will produce current depending on the bias selected from the DAC3/4 from micro controller. If the current has no where to go but through the bottom transistor. This problem was remedied with construction and introduction of the finger probe.

The LED driver was tested by using the I2C DAC LABVIEW program to modify the voltage on the base of the bias transistor. The brightness was modified by changing the voltage from the peak (+5v) to (0v) transistor off. We need to investigate just how hard we can push these LED's as the brightness can improve the signal coming out of PD. To do this, we will need to modify the emitter resistance and see just how far we can push.

The finger probe was constructed in the following manner. First, a pre-prepared probe from Masimo was acquired and modified. The wire was cut and the wires were stripped. The color code is as follows:

ORANGE - LED IR

RED - RED LED

WHITE - PHOTO DIODE 1

GREEN - PHOTO DIODE 2

METAL - GND

I took a copper prototype board and cut traces. Then I soldered the wires into specific traces. I think soldered a 16-pin male connected on the POX board where the LED output and PD input's come in. Then, I soldered a 16-pin female connected to this copper prototype board. The final result is displayed below:

I'm nearing completion on the work of the transimpedance stage as well. I've populated the entire subcircuit but am running a couple of last minute simulations to choose feedback and input resistances. A problem was discovered by Shanit in which VCC and VSS are wired backwards. To remedy this, I will have to cut a trace and use jumper wires to each of the 3-vcc/vss pads. I will post another update with progress on this front in the next few days.

Megan has been given the task to complete an integrated software solution. The software solution will enable control of all 4 (four) DAC's, the PGA, and the ADC. This will allow modification of the intensity of the LED's, DC subtraction, and programming the gain amplifier. At this point the team will regroup and focus for the rest of the quarter on software development.

Class Discussion: Clock Timing

A clock signal must be implemented on board to drive the LED driver circuit. By repeatedly flashing LED's on an off modulation is achieved. The photons from LED's after passing through fingertip are received on a photo diode. This signal then must be demodulated back to baseband.

The question is: If the clock for S/H demodulator is out of phase or delayed from clock driving LED's then will error occur and how can it be fixed. The problem could arise from delays in the circuit. The oscillator is designed as a simple charging RC circuit with dual inverters. There exists a delay in switching of inverters.

To match clocks a phase delay of some sort must be introduced in the circuit. A simple RC delay can be introduced providing a phase of 45 degrees and can be cascaded to the desired result. This result assumes the delay is constant and a multiple of 45 degrees. A more complex delay network could be developed to provide variable tuning delay with a potentiometer or variable capacitor. If inductors are allowed in the design, then a maximum phase of 90 degrees could be achieved.

LED Driver

I (Jon) have been working on the LED driver circuit. I need to measure how much current is being fed to the LEDs to verify that the circuit is behaving as specified in my design. I am making good progress, and the LED driver circuit section of the board is populated.

Photo diode and Transimpedance update

I began construction on a circuit to experiment with photodiode and LED. First, a circuit was constructed to flash an LED. Another circuit was constructed with a photodiode to measure response to LED. Below is an idea of what the experiment looked like. Also attached are photos of the two circuits together.

The function generator was used to drive the LED’s at a specified frequency. The top of the LED was placed above the photodiode and mounted. In this manner, the output the response of the photodiode could be analyzed and quantized.

First, DC measurements were made on the constructed circuit. The diode had an open circuit voltage of around 650 mV. When the circuit was constructed with the 300k resistor though, the voltage across the diode dropped to around 280 mV. This suggests a current of a current of 88 uA. Next, the output of the photodiode was connected to the oscilloscope. I drove the LED with a square wave and observed the waveform at the photodiode output.

One thing I noticed was that an ambient light condition, a large DC bias exists. If the box was isolated and put in the dark box, then the Bias was removed. Additionally, the signal became much less noisy and clearly resembled the driving signal. Another thing I noticed was how the modulation scheme developed. The output LED’s are 180 out of phase and are switched. The switching procedure acts as a modulator shifting cardiac signal from baseband to the carrier band. In this manner, our previous circuit with high pass filter followed by Sample and Hold implements the demodulation application.

I also started looking into the topology selection for transimpedance stage. The reason for a differential stage is to eliminate common mode (CM) noise. I will update with some more information in a later blog. Below is some information on differential opamp stage extracted from Wikipedia. The key idea with this circuit is to amplify the difference between the terminals of diode.

In my next experiments, I will be implementing the transimpedance stage and analyze the approach to remove common mode noise. Additionally, I want to perform some quantization on how hard we can drive the LED’s. As we are driving the LED’s with PWM approach we can increase current through device.

Photodiode/Transimpedance Links

1. Photodiode Technical Information

http://sales.hamamatsu.com/assets/applications/SSD/photodiode_technical_information.pdf

2. Photodiode Characteristics

http://www.optics.arizona.edu/Palmer/OPTI400/SuppDocs/pd_char.pdf

3. Designing of Photodiode Amplifier circuits with OPA128

http://focus.ti.com/lit/an/sboa061/sboa061.pdf

4. OPA350 Datasheet

http://users.ece.utexas.edu/~valvano/Datasheets/OPA4350.pdf

5. Differential Operational Amplifier explanation

http://www.ecircuitcenter.com/Circuits/opdif/opdif.htm

6. Differential Operational Amplifier Stage

http://en.wikipedia.org/wiki/Operational_amplifier_applications

EEC136 Team Sierra Created

This is blog for postings on Team Sierra development of Pulse Oximeter. The teams consists of group members Megan, Jonathan, and Nicholas. This blog will deliver progress updates and status of the project.

This week, work was delegated into three areas. It was decided that Megan will began to work on software for LED driver circuit. Jonathan will begin researching and designing the LED driver circuit. Nicholas will be working with trans-impedance amplifier.

This Friday we will perform analysis on current characteristic of of photo diodes with response to LED's.