Pulse sensor interfering with other sensor readings

[worldfamouselectronics]

Pulse sensor interfering with other sensor readings

[biomurph]

First a couple of things.

I can't see the images that you link to.
What hardware are you targeting?
You need pulseSensor.begin() in the setup to start the Pulse Sensor reading correctly.

Finally, you can't use the ouputSample function the way that you want to. The parameter that outputSample takes is the number of Pulse Sensors you have, if you have more than one. You will have to put in your own line that prints the gsr_average and the comma to print to the serial plotter.

Let me know if that fixes it.

[sorexy]

Hi there,

Thank you very much for your response! I've fixed the URL to the images and it should be working now.

I am currently using the Genuino 101 for this project.

I added pulseSensor.begin() to the setup (shown below), but it still produces the interference described.

void setup() {
  Serial.begin(115200);
  
  /* ===== Setting up the pulse sensor ===== */
  pulseSensor.analogInput(PULSE_INPUT);
  pulseSensor.setSerial(Serial);
  pulseSensor.setOutputType(OUTPUT_TYPE);
  pulseSensor.setThreshold(THRESHOLD);
  // Skip the first SAMPLES_PER_SERIAL_SAMPLE in the loop().
  samplesUntilReport = SAMPLES_PER_SERIAL_SAMPLE;
 
 pulseSensor.begin();
}

With regards to the outputSample function, i've actually overloaded the default one and didn't think it would cause any problems. I have removed it though and just added prints to see if this was the problem. Unfortunately, the issue still persists.

    if (--samplesUntilReport == (byte) 0) {
      samplesUntilReport = SAMPLES_PER_SERIAL_SAMPLE;

      /* outputs GSR readings along with pulse readings in the same line, separated by commas */
      Serial.print(gsr_average);
      Serial.print(',');
      pulseSensor.outputSample();
    }

I look forward to hearing from you.

[biomurph]

That is very strange that your A0 input is affected by your A1 input...
Or maybe not. I don't know much about the genuino 101 and how it does analog read stuff.
Here's some things to try.

Move the Pulse Sensor to a more physically distant analog input and see if you have the same issue?

Your GSR readings don't need to be happening all the time. Try doing them only occasionally? There is a variable called isInsideBeat that you can access with pulseSensor.isInsideBeat() it returns true if the pulse wave is above the threshold, and false when it's not. If the weird crosstalk continues when you move the pulse sensor physically far away, you could access that boolean and only check your GSR when it returns false. LMK if that works.

[sorexy]

Moving the pulse sensor further from the GSR sensor did not stop the interference unfortunately. With regards to the isInsideBeat() function, I tried it and noticed something completely bizzare as well. When the amplitudes of the PPG waveform were not so strong, the signals would always cross over the threshold, according to the isInBeat() function. The threshold is set to the default (550 i believe).

However, here comes the weird part, when the waveform starts ramping up in amplitude and causes interference in the GSR readings, the isInBeat() seems to switch between True/False states synchronously with the interference patterns. Here is a screenshot of the readings

https://imgur.com/a/yynnmL3

On another note, do you think it could be a power supply issue?

[biomurph]

This all makes sense.
First point to make is that the threshold value varies when there is a steady beat and takes the value of 1/2 of the pulse amplitude. That is to help with noise and to get closest to the 'moment of heart beat' according to people smarter than me...
When the signal crosses the threshold, the isInsideBeat will return true. Your graph is really nice and shows how those variables and the algorithm are working, cool!
But, you still have noise in your GSR....

I took a look at the grove sensor, and it's output is buffered by a low pass filter. The resistor that is used is 1M, so that means that the grove sensor has a pretty high impedance output. The Pulse Sensor, however, has a very low impedance output. So the Pulse Sensor is sending current into the system that is effecting the grove output. There's a couple of things to try to mitigate this problem.

First option, fix it in code. As mentioned in my last comment, the GSR values really don't change that fast, so you don't need to measure them as often as you are doing. You can easily avoid the current noise in the GSR signal by only measuring it when the isInsideBeat() returns false.

Second option, fix it in hardware. You can try to put a resistor in series with the Pulse Sensor signal. That would reduce the amount of current bouncing around, and should dampen the noise in the GSR signal. With the sketch running, try a few different resistors, like 1K, 10K, 100K, 1M, and see what happens to the signals in real time.

LMK what happens.

[yury-g]

Sorexy, Cool project! Backing up a bit can I ask you a question. There are three (3) BPM projects on our page: https://pulsesensor.com/pages/getting-advanced Which one are you using to test/calibrate your PulseSensor before plugging into the greater project ? Thanks, Y.

On Wed, Jul 25, 2018 at 9:42 AM Joel Murphy ***@***.***> wrote: This all makes sense. First point to make is that the threshold value varies when there is a steady beat and takes the value of 1/2 of the pulse amplitude. That is to help with noise and to get closest to the 'moment of heart beat' according to people smarter than me... When the signal crosses the threshold, the isInsideBeat will return true. Your graph is really nice and shows how those variables and the algorithm are working, cool! But, you still have noise in your GSR.... I took a look at the grove sensor, and it's output is buffered by a low pass filter. The resistor that is used is 1M, so that means that the grove sensor has a pretty high impedance output. The Pulse Sensor, however, has a very low impedance output. So the Pulse Sensor is sending current into the system that is effecting the grove output. There's a couple of things to try to mitigate this problem. First option, fix it in code. As mentioned in my last comment, the GSR values really don't change that fast, so you don't need to measure them as often as you are doing. You can easily avoid the current noise in the GSR signal by only measuring it when the isInsideBeat() returns false. Second option, fix it in hardware. You can try to put a resistor in series with the Pulse Sensor signal. That would reduce the amount of current bouncing around, and should dampen the noise in the GSR signal. With the sketch running, try a few different resistors, like 1K, 10K, 100K, 1M, and see what happens to the signals in real time. LMK what happens. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALoBYGt2cmSlQsiAD4nnC2BWp6TFTNY_ks5uKHW2gaJpZM4VbWKs> .

-- YuryG www.PulseSensor.com

[sorexy]

Hi guys,

Thanks for the responses.

So I tried implementing in code to only measure the GSR when isInsideBeat() is false, but the interference still persists. It seems rather bizzare. I've also tried to make it read and report the GSR values only when the pusle sensor PPG waveform is lower than the baseline GSR reading. Still interference. I even tried adding delays of 10msec before and after taking GSR readings, but to no avail. I am currently unable to fix it via hardware as I do not possess the required components.

With regards to which BPM project I am using, I am using BPM Alternative. The first one does not work for me unfortunately.

Many thanks.

[biomurph]

@sorexy please share the code you are using. I don't see how you could still get interference when you are measuring GSR when the isInsideBeat is false.

[sorexy]

Yes of course,

I tried this

  if (pulseSensor.sawNewSample()) {
  
    if (!pulseSensor.isInsideBeat()){
      long sum=0;
      for(int i=0;i<10;i++) {          
        sensorValue=analogRead(GSR);
        sum += sensorValue;
        }
      gsr_average = sum/10;
      }
    
    if (--samplesUntilReport == (byte) 0) {
      samplesUntilReport = SAMPLES_PER_SERIAL_SAMPLE;
      
      /* outputs GSR readings along with pulse readings in the same line, separated by commas */
        Serial.print(gsr_average);
        Serial.print(',');
        pulseSensor.outputSample();
    }
  }

and

  if (!pulseSensor.isInsideBeat()){
    long sum=0;
    for(int i=0;i<10;i++) {          
      sensorValue=analogRead(GSR);
      sum += sensorValue;
      }
    gsr_average = sum/10;
    }

  if (pulseSensor.sawNewSample()) {
    if (--samplesUntilReport == (byte) 0) {
      samplesUntilReport = SAMPLES_PER_SERIAL_SAMPLE;
      
      /* outputs GSR readings along with pulse readings in the same line, separated by commas */
        Serial.print(gsr_average);
        Serial.print(',');
        pulseSensor.outputSample();
    }
  }

The first reduced the interference significantly, but not eliminated it. In fact, sometimes the interference comes in the form of a negative spike.

The second did not reduce interference.

Please check here for images

https://imgur.com/a/CzUbYpi

[biomurph]

I can see by the images you shared that you are definitely getting good GSR when you're outside of the beat, but when you are measuring GSR just after isInsideBeat goes false (right after the beat) you are catching the last bit of the noise that is in the signal. So, you need to only use (or measure) GSR that is clean before the isInsideBeat turns true.

Have you tried to put a resistor in series with the Pulse Sensor purple wire?

[sorexy]

So I tried the resistors, only the 1M resistor seemed to reduce the interference but not eliminated it. I have decided to use two arduinos instead.

[biomurph]

@sorexy bummer about that.

One last thing to try in hardware would be to buffer the GSR signal with an op amp set up to be a voltage follower. That would make the signal from the GSR much lower impedance, and it will have a fighting chance against the Pulse Sensor signal.

[yury-g]

more or less at resolution.