Sunday, May 23, 2010

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.

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.


Saturday, May 15, 2010

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.

Sunday, May 2, 2010

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.