Question for the HW engineers

On Mon, 06 Apr 2015 17:41:24 +0000, Rob Gaddi wrote:

> On Mon, 06 Apr 2015 10:19:57 -0700, Mauritz Jameson wrote:
> 
>>> Are you using the diodes in photovoltaic mode, or are you using them
>>> in photocurrent mode?
>> 
>> I'm not sure, but I can find out.
>> 
>>>It sounds to me like what you _really_ want to be doing is to measure
>>>the total light reflected at one wavelength, then measure the total
>>>light reflected at the other, then get a ratio -- is that correct?  If
>>>so, then at best you're measuring (total - offset) at one wavelength,
>>>(total - offset) at another, and then doing some magic (what -- a table
>>>lookup?) in the middle.
>> 
>> That's exactly what I'm doing. So I end up with 2 digital signals a
>> "red signal" and a "infrared signal". And I'm supposed to estimate the
>> DC and AC component of each signal where "DC" is the mean and "AC" is a
>> measure of the peak-to-peak amplitude. Then I'm supposed to calculate
>> the "ratio of ratios" which is defined as:
>> 
>> R = ("RED AC" / "RED DC" ) / ("INFRARED AC" / "INFRARED DC")
>> 
>> The R value can then be mapped to an SPO2 value via a lookup table.
>> 
>> You can see some examples of the signals here:
>> 
>> http://ge.tt/4JsatwD2/v/0?c
>> 
>> The document shows the results of 3 tests. For each test, I have
>> plotted the raw, digital signals (red and infrared). Then I bandpass
>> filter the signals to suppress DC and frequencies which I'm not
>> interested in. The bandpass cut off frequencies are: 0.1Hz to 6Hz. So
>> there are 3 x 2 figures in total.
>> 
>> In MATLAB I get the filter coefficients like this:
>> 
>> [b,a] = fir1(512,[0.1 6]./(25/2))
>> 
>> The sample rate is 25Hz.
>> 
>> You can clearly see that the signal is "riding" on a slowly, increasing
>> DC component....or in the case of figure 1: the signal of interest (the
>> pulses) is "riding" on low-frequency sine.. And the control SW adjusts
>> the LED when the signal is about to creep above a pre-defined upper
>> boundary. That's when you get that big drop (figure 1, second subplot).
>> 
>> I can't imagine that I would get any reliable result out of this. The
>> "drops" will manifest as "noise" in any frequency domain analysis of
>> the signal, right?
>> 
>> To me it looks like the HW design is flawed. Either there is a "bug" in
>> the HW design/implementation or the chosen HW design is not suitable
>> for measuring electrophysiological signals.
>> 
>> What do you think?
> 
> I think that I certainly wouldn't be getting any warm fuzzy feelings
> from the hardware design.  Photodiode amplifiers are one of those things
> that should be hard to screw up, yet people do time and again.
> 
> If you were desperate, and had to make it work with the existing
> hardware, you could cut your overall sampling rate to cycle between
> (RED,
> IR, OFF), and keep subtracting out the OFF value of the reading from the
> other two, but something sure seems to be up at a fundamental level with
> the hardware.

That only works if the "off" signal from the photodetector is valid.  But 
yes, that's one of the things that several of us have tried to push.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Mon, 06 Apr 2015 10:19:57 -0700, Mauritz Jameson wrote:

>> Are you using the diodes in photovoltaic mode, or are you using them in
>> photocurrent mode?
> 
> I'm not sure, but I can find out.
> 
>>It sounds to me like what you _really_ want to be doing is to measure
>>the total light reflected at one wavelength, then measure the total
>>light reflected at the other, then get a ratio -- is that correct?  If
>>so, then at best you're measuring (total - offset) at one wavelength,
>>(total - offset) at another, and then doing some magic (what -- a table
>>lookup?) in the middle.
> 
> That's exactly what I'm doing. So I end up with 2 digital signals a "red
> signal" and a "infrared signal". And I'm supposed to estimate the DC and
> AC component of each signal where "DC" is the mean and "AC" is a measure
> of the peak-to-peak amplitude. Then I'm supposed to calculate the "ratio
> of ratios" which is defined as:
> 
> R = ("RED AC" / "RED DC" ) / ("INFRARED AC" / "INFRARED DC")
> 
> The R value can then be mapped to an SPO2 value via a lookup table.
> 
> You can see some examples of the signals here:
> 
> http://ge.tt/4JsatwD2/v/0?c
> 
> The document shows the results of 3 tests. For each test, I have plotted
> the raw, digital signals (red and infrared). Then I bandpass filter the
> signals to suppress DC and frequencies which I'm not interested in. The
> bandpass cut off frequencies are: 0.1Hz to 6Hz. So there are 3 x 2
> figures in total.
> 
> In MATLAB I get the filter coefficients like this:
> 
> [b,a] = fir1(512,[0.1 6]./(25/2))
> 
> The sample rate is 25Hz.
> 
> You can clearly see that the signal is "riding" on a slowly, increasing
> DC component....or in the case of figure 1: the signal of interest (the
> pulses) is "riding" on low-frequency sine.. And the control SW adjusts
> the LED when the signal is about to creep above a pre-defined upper
> boundary. That's when you get that big drop (figure 1, second subplot).
> 
> I can't imagine that I would get any reliable result out of this. The
> "drops" will manifest as "noise" in any frequency domain analysis of the
> signal, right?
> 
> To me it looks like the HW design is flawed. Either there is a "bug" in
> the HW design/implementation or the chosen HW design is not suitable for
> measuring electrophysiological signals.
> 
> What do you think?

The symptoms certainly point to the hardware not working correctly.  I 
hesitate to jump up and down and point without knowing more.

I do know that, unless there's some overriding reason that it shouldn't 
work, that I'd want to have detectors working in photocurrent mode, with 
the expected full range of the detectors taking up the full range of the 
ADC in such a way that the photodiode current at "off" can be measured 
with exactly the same precision as the photodiode current with either of 
the LEDs on -- there are too many variables (not least of which is ambient 
light) in a system like that to know the zero-light current exactly 
without measuring it.

Unfortunately if the hardware design really is deficient, and if you can't 
convince the hardware engineer of this or if you don't have a higher 
authority who can override the guy and who can be easily appealed to, then 
your problem becomes a political one and not a technical one.

If I were in the shoes that I think you are, I would want to have some 
written -- or even verbal -- description of what the hardware should be 
delivering to the ADC in order for the software to have a chance at doing 
its job right.  Then you can take that written description (perhaps after 
writing it down) to the hardware guy and ask him to please show you how 
his hardware is delivering on that promise.

Hopefully what will come out of that exercise is that one of you will slap 
your forehead, cry "oh, of course!" and run off to their cubicle to solve 
the newly-discovered problem.  If the hardware guy refuses to cooperate 
then unless he's the company owner you can go to his boss and make a 
pretty good case that he's not doing his job.  If the two of you can't 
agree on the basic requirements, or if you each look at what the hardware 
does and come up with a different story on whether it satisfies the 
requirement, then it's back to appealing to a higher authority (or 
shopping your resume around).

This part is a blatant plug: if you need a guy from out of town with a 
briefcase to come and be a tie breaker, I can help (so can several others 
in this group, BTW -- but I'm better looking and have a grander bedside 
manner).  I don't play favorites, and I do like to see problems solved, so 
I'm not going to just stir the pot to generate more hours or for the fun 
of it.  If you're in the middle of a log jam here I can review the system 
design, electronics and the software and help get your project going 
forward again.  If I'm lucky, I can even do it without pissing anyone 
off.  So feel free to share my name with your boss.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Thu, 2 Apr 2015 15:50:25 -0700 (PDT), Mauritz Jameson <mjames2393@gmail.com> wrote:

> I'm working on a project where we're supposed to design a
> reflectance-based pulse oximeter.  The device has a red and infrared
> LED which takes turns emitting light.  There is one photo-transistor
> which then picks up the reflected light and sends it off to an ADC.
> The ADC sample rate is 25Hz and the data collection loop is 40ms long.
> During a time window of 40ms, the data is collected like this:
>
> 6ms: Turn RED LED ON
> 10ms: Start ADC conversion
> 14ms: Read RED Pulse OX Value from ADC
> 26ms: Turn INFRARED LED ON
> 30ms: Start ADC conversion
> 34ms: Read INFRARED Pulse OX Value from ADC

Hi, Mauritz.

I'm not an electronics expert -- I can't even get paid to play one on TV
-- and about the only sources of drift I normally encounter are un-tied
CMOS pins which slowly accumulate charge. ( "Of _course_ I checked those
solder joints. ...  Oh.  Well, they all _looked_ good until you pried
that IC pin up.")

I was curious, however, about whether you ever attempt to calibrate the
LED intensities and if so, how you do it.  You're using -- if I
understand you -- a ratio of intensity-ADC values, so you might not have
considered it, but it might be handy to know whether the "creep" is due
to an LED getting brighter or the photodiode bias shifting.  I'm thiking
something simple, like a mirror and piece of black paper for the visual
LED and something IR-absorbing and something else IR-reflecting: four
sets of samples to establish a baseline.

Jes' a thought.


Frank McKenney
--
  As a physicist whose research is on subjects like elementary particles
  and cosmology that have no immediate practical application, I am
  certainly not going to say anything against knowledge for its own sake,
  but doing scientific research to fill human needs has a wonderful way
  of forcing the scientist to stop versifying and to confront reality.

                        -- Steven Weinberg, "To Explain the World"
-- 
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney aatt mindspring ddoott com

>The signal from the sensor is not referenced to ground.
>It is instead referenced to a 3.3V rail. 
>
>The PGA in the ADC is not able to operate below its 
>power supply voltage divided by 4, so referencing 
>to the upper rail seemed like the best option. 
>
>The signal is 0.3V away from the rail so it
>might be possible to reference to ground in 
>the next HW revision.
>
>The output from the sensor phototransistor is normally 
>at the 3.3V rail when there is no signal. As light reflecting off the
skin
>increases, 
>the signal drops from 3.3V.    
>
>This sensor signal goes into one ADC input, and a stable bias point
that is
>now 
>set to 3.3V/11 goes into the other input. 
>
>The PGA gain in the ADC is set so that we are looking at a range of
8mV
>below 
>the bias point. 
>
>The input multiplexor to the ADC is set so that the sensor signal is
>subtracted 
>from the bias point. Since the ADC output is a two's complement number,

>the sign bit is shifted out. 
>
>The result is a 16 bit digital output that covers an 8mV range, on top
of an
>approximately 
>0.3V bias.
>
>The bias is approximate because the power supply has a typical
regulation of
>+/- 0.5%.
>The 8mV range is determined by the ADC's internal reference voltage,
and the
>initial 
>range for the reference is 2.048V +/- 0.003V, with perhaps a 5 ppm/C
drift
>with temperature.
>
>The code adjusts the brightness of the LEDs to keep the ADC output
within a
>narrow range. 
>If the ADC is out of range the DAC feeding the LED changes its value by
one.
>
>
>The control SW tries to keep the signal between 92 and 97 percent of
full
>scale, 
>or within the range of 60294 - 63569. If the signal goes beyond either
of
>these values 
>the next sample will jump as a result of the change in the DAC value.
>
>Generally, we see long term drift in the signal, over the scale of at
least
>several 
>minutes after start up. We don't have data yet that shows how drift
evolves
>over
>several hours.
>
>The single sensor is illuminated in turn by two different LEDs, so the
>signal is a 
>series of pulses. We are looking at very small changes in the pulse
height 
>and need the top of each pulse to stabilize before we can run the ADC.

>A DC filter would (presumably) destroy the signal (I don't understand
why it
>would
>destroy the signal).
>
>ADC used: ADS8866

The ADC you describe has no PGA inside it (ADS8866). Also the ADC you
describe is not 2's comp output, its unipolar, straight up binary. Also,
you describe using a 3.3/11 V signal to one input of the ADC and the
sensor signal is the other input (3.3-3.0 V range based on your
comments). The ADS8866 ADC will then take the difference of those two so
your difference will be ~3.0 to 2.7 V range. This is a poor design, as
you are always forcing your differenced output to be near the ADC rail,
any drift on your sensor in the positive direction will force your
difference value to be closer to full scale, change your 3.3/11 to 3.3/2
or something so you have more range available in your difference signal.
Are you sure you are using an ADS8866?
---------------------------------------
Posted through http://www.DSPRelated.com

> Are you sure you are using an ADS8866?

I asked the HW engineer, and the design has been changed so we're now using ADS1220.

>> Are you sure you are using an ADS8866?
>
>I asked the HW engineer, and the design has been changed so we're now
using
>ADS1220.

My comments still stand, you should be doing differential measurements
with the PGA, so if your transistor is baised from 3.3V, you should put
that into one input of the A2D, and then the sensor output to another
input, then the PGA will take the difference and gain it accordingly.
Your hardware engineer should understand this easily.........
---------------------------------------
Posted through http://www.DSPRelated.com