sampling frequency not respected?

[ghost]

Hi,

I'm using the MAX30102, but in principle it shouldn't make any difference.
Using the Example6_FiFoReadings code, if I change the sampling frequency I notice that it is not respected.
I have tried changing the sampling rate and the averages together.
Here's a table with some results:

selected freq	avg	mode	effective freq
50	1	spo2	50
50	2	spo2	25
50	4	spo2	12.5
100	1	spo2	100
100	2	spo2	50
100	4	spo2	25
200	1	spo2	200
200	2	spo2	100
200	4	spo2	50
400	1	spo2	100
400	2	spo2	50
400	4	spo2	25
800	1	spo2	50
800	2	spo2	25
800	4	spo2	12.5

You can see that up to 200Hz it behaves as expected, but from 400Hz and on it seems to completely change its behaviour.
The other parameters were left as usual: pulseWidth = 411 and adcRange = 2048

Any suggestions?

[Marcoar92]

am using MAX30102 too. Were you able to solve this problem ??

[ghost]

no, actually I have tried with another MAX30102 and it showed the same behaviour.
I have looked into the source code of this library, and, from my naive inspection, it all seems fine. So, maybe the HW module has a defect and it's not this library's fault.

I haven't tried with any other MAX3010X module.

[kind-king]

Hi,
try this code:

void loop() 
{
  particleSensor.check();
  for (uint8_t i = particleSensor.available(); i != 0; --i, samplesTaken++) {
    Serial.print("[IR] = ");
    Serial.print(particleSensor.getFIFOIR());
    Serial.print("\t[Red] = ");
    Serial.print(particleSensor.getFIFORed());
    Serial.print("\n");
    particleSensor.check();
    particleSensor.nextSample();
  }
 
  Serial.print("[Temp] = ");
  Serial.print(particleSensor.readTemperature());
  Serial.print("\t[Hz] - ");
  Serial.print((float)samplesTaken / ((millis() - startTime) / 1000.0), 2);
}

[nseidle]

tldr; I'm confident the library and IC are working correctly.

When in doubt read the datasheet!

Page 20:

The sample rate and pulse width are related in that the sample rate sets an upper bound on the pulse width time. If the user selects a sample rate that is too high for the selected LED_PW setting, the highest possible sample rate is programmed instead into the register.

The combination of your pulseWidth, ledMode, and sampleAverage will affect the max sampleRate obtainable.

Additionally, off the top of my head, if you've got 2 LEDs active that's 6*3200 = 19,200 bytes that need to be read. At 100kHz I2C you can only read 10,000 bytes per second. Your controller and/or buffers may be the bottleneck.

I've added an "Example9" to the library to demonstrate reading 3200 samples per second using a Teensy. Using an Uno I was able to read ~2700Hz.

[ghost]

Yes, it's likely that the pulse width is too big, haven't thought about it. Also the bottleneck didn't came to my mind.
Many thanks for your explanation !

I hope this issue will be useful to others too who struggle with the same problem.