Question for the HW engineers

On Sun, 05 Apr 2015 17:12:55 -0700, Mauritz Jameson wrote:

>> I assume you mean a DC-blocking filter, AKA a high-pass filter.
> 
> Yes
>  
>  
>> The problem with a DC-blocking filter is that, along with the method
>> you have outlined, you won't know what the values of the readings are.
>> Of course, with the drift you won't know that either.
> 
> Is that because it takes a while before the DC filter reaches steady
> state and the signal to be measured is measured over a very short time
> interval? So the output of the DC blocking filter won't even have
> reached steady-state at the time where the ADC reads the output from the
> DC-blocking filter?

No, it's because the DC blocking filter removes all information about 
what's going on at DC from your signal.  This means that your measurement 
is

x = (desired value) + (unknown value)

and all you need to do is to subtract out the unknown value -- which, of 
course, you don't know.

This is the SAME PROBLEM that you have with the drift, for that matter.

>> 2: Put an "auto zero" circuit in the hardware that zeros out the analog
>> output when the ADC isn't converting (or when the SW says so), then
>> holds that offset when the ADC _is_ converting.  Then your ADC readings
>> will be from zero instead of from whatever the drifting value happens
>> to be.  It should be possible to implement this with a single op-amp,
>> an electronic switch, and a few passives.
> 
> Is there a generic design for an "auto zero" circuit? Or would the
> selection of such a circuit require more information about the "target
> system" where it's going to operate?
> 
> I found this white paper:
> 
> http://goo.gl/Fd4DtH
> 
> Is that the kind of circuit you're talking about?

That is a tout sheet for a chopper-stabilized operational amplifier.  You 
want a circuit that, when commanded, adjusts an offset voltage in a 
capacitor such that the output is zero, then holds that offset voltage 
steady otherwise.

>> The important thing to do to make this work is to make sure that the DC
>> blocking filter is slow enough that the amount that it changes in
>> response to the LEDs shining on things over the duration of a reading
>> is small enough not to affect the system accuracy.
> 
> Can you elaborate on this? What exactly do you mean by "slow enough"? My
> background is in signal processing (SW). I know that with digital
> filters, there are things like settling time to deal with. I assume the
> same phenomena exists in the analog HW domain? Is that what you're
> talking about?

It's a pretty good characterization to say that nearly all the filters 
that you'll see in the analog domain, except for ones involving 
transmission line effects, are IIR filters.  Their responses will look an 
awful lot like IIR filters do in the digital domain.

When I say "slow enough" I mean "not too fast".  When you turn a light 
on, the filter, being high-pass, will jump in value and start to settle.  
You need to be able to measure the magnitude of the jump accurately, 
which means that the filter does not substantially settle as you're 
measuring it -- it also means that the time between turning on the light 
and the ADC taking the measurement should be constant.

-- 
www.wescottdesign.com

On Sun, 05 Apr 2015 14:02:47 -0700, Mauritz Jameson wrote:

> 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

Y'know, it really sounds to me like each reading is

x = ((desired signal) + (unknown signal))*(god knows what)

I could, of course, be wrong.

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.

This should not be hard.  This should not be hard at all.

-- 
www.wescottdesign.com

On Sun, 05 Apr 2015 14:02:47 -0700, Mauritz Jameson wrote:

> 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

Are you using the diodes in photovoltaic mode, or are you using them in 
photocurrent mode?

-- 
www.wescottdesign.com

> 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 meant to say "the bandpass cut off frequencies are: 0.1Hz and 6Hz"

Tim Wescott <tim@seemywebsite.com> wrote:
> On Sun, 05 Apr 2015 14:02:47 -0700, Mauritz Jameson wrote:

(snip)
>> 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.
 
>> 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.

(snip)

> Y'know, it really sounds to me like each reading is
 
> x = ((desired signal) + (unknown signal))*(god knows what)

I think so.
 
> I could, of course, be wrong.
 
> 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.

Yes, I believe that is what it is doing. When you divide, the
(god knows what) cancels out.

And, by measuring with LEDs on and off, subtract out
(unknown signal)*(god knows what), maybe separately for the two,
you are left with the ratio of (desired signal)s.
 
> This should not be hard.  This should not be hard at all.

-- glen

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.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Mauritz Jameson <mjames2393@gmail.com> wrote:
(snip)

> 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). 

Hmm. Sine and "slowly increasing" are very different, though 
locally they may look the same.  What (about) is the frequency
of the sine?  I am wondering if it is a transient in your filter.

-- glen

> Hmm. Sine and "slowly increasing" are very different, though 
> locally they may look the same.  What (about) is the frequency
> of the sine?  I am wondering if it is a transient in your filter.

Well. In one case (if you look at the plots), the pulse train (signal of interest) seems to be riding on a line with a positive slope. In another case, the pulse train seems to be riding on a sine. Wouldn't you agree?

I have plotted an FFT of the red signal (test #1):

http://ge.tt/2XCGAxD2/v/0?c

And here's the FFT of the red signal (test #2):

http://ge.tt/7aRSBxD2/v/0 

Here's a video showing the FFT of a 1-minute window sliding over the signal.

http://youtu.be/Eh5YJ2NAX1Y?hd=1