Can't get SpO2 to work

[robcazzaro]

First of all, thanks so much for the work you did and for making it available.

I'm having a problem making the code work properly and I'm hoping you can point me in the right direction.

I'm using an ESP32, which is many times faster than the M0 processor you are using. And I have quite a lot of ESP32 experience, so I'm sure I2C works properly. I built a separate ESP32/MAX30102 project and that worked perfectly, so I checked the code for any potential problem and I think that the data reading from the sensor is working properly. I also have 2 different MAX30102 boards, and there is no real difference in the results between them

I'm including 2 files, one a data capture in txt format, the other I imported the same data as CSV into Excel and plotted the graph for the first 100 samples. To my eyes, that looks like an almost perfect graph, so I was expecting the code to work. The only potential issue is the the amplitude of the IR signal is much lower than the RED one

MAX30102.xlsx
MAX30102.txt

You will notice from the CSV that I'm printing both the results of your algorithm and the Maxim results and, if anything, the Maxim ones are worse, so I'm struggling to understand where the problem is. Your algorithm does a great job of reporting the heart rate (double checked with a commercial pulse oximeter), but does not report any valid SpO2 result (flag is 0, result is -999.00, expected when the flag is 0)

I tried changing the LED intensity (registers 0x0C and 0x0D), but it doesn't make a real difference, outside of "shifting the curves up" when I do it

Thanks in advance for any idea/pointer to troubleshoot my problem

[aromring]

Hi Rob,
Thank you so much. Yours is the perfect model of a proper bug report submitted with enough information and data. Others should learn from you! Usually, I am getting no more than 1-3 sentences, like "It doesn't work. Help me." Some people expect me to have psychic powers. ;)
Since I am dedicating part of this weekend to looking at MAX30102_by_RF issues your submission will get the first priority. Stay tuned.

[aromring]

Hmm, at the first glance the raw signals produced by your sensor are very good. I can't imagine why there would be no SpO2 output. Hence, debugging time... Stay tuned; I should have something by Sunday.

[robcazzaro]

:) thanks for the nice words. I used to work in support for a long time, and I know perfectly well what you mean.

You might notice from the file capture that I slightly changed the print() format for the algorithm results, but that should not make any difference. As you saw, the data capture seems good, but I didn't dig too deep into the algorithm yet.

I wonder if it's possible that some of the ESP32 math libraries produce different results due to rounding errors or such, but I'm not aware of any problem in that area currently and by now the ESP32 toolchain is really mature, so it would be a surprise if that's the case.

The only other thing I can think about is that I had some issue reading the MAX30102 in my other project (in that case I was reading 2 MAX30102 at the maximum speed of 400Hz and sending data via BLE, so any small glitch caused problems with the FIFO reading and my data could get out of sync. I'm wondering if it's possible that the RED and IR data are shifted by 1 frame due to I2C problems with the ESP32. I have a STM32F104 board, and I can try on that (M3 @72MHz, so closer to the board you used), if the ESP32 is a dead end

Anyway: I truly do appreciate your time, and I'd be happy to try anything to make this work and see if your code can work on the ESP32, which is a pretty common and cheap board. The value of the ESP32, is that it's then easy to use the built-in BLE to create a truly wireless solution and act as a heart rate sensor for other apps

Needless to say, there's no rush.

[aromring]

Well, no line debugging was necessary. I've figured what happened using an Excel spreadsheet.
The answer to your problem is the applicability domain of the Maxim's calibration equation:

SpO2 = (-45.06*Z + 30.354)*Z + 94.845

where Z is defined in my Instructable (roughly, it's a ratio of normalized variabilities of RED to IR signals). The above equation is an inverted parabola with one negative root and one positive root at ~1.826. Z values above the latter would result in nonsensical negative SpO2 values.
Here is an example of expected raw signals in the first graph and centered/leveled ones in the second:

As you can see, normalized AC/DC ratio for RED should be lower than IR. The Z value in the case is 0.4589 and SpO2 = 99.28% - reasonable.
And here are analogous graphs plotted from your signal:

In contrast to previous example, RED's AC/DC far exceeds IR's. The Z value in your case is 1.958 which would produce SpO2 = -18.52%. The following line of code:

if(xy_ratio>0.02 && xy_ratio<1.84) { // Check boundaries of applicability

captures this case and sets *pch_spo2_valid flag to 0.
BUT, if you switch your RED and IR signals, then Z = 0.51 and SpO2 = 98.59%. Therefore, I am suspecting that in your setup you've mixed RED with IR and vice versa.

[robcazzaro]

That's interesting... I don't think I switched anything like that in the code, but I wonder if the I2C FIFO reading loop is doing something weird.

I'll do some more tests and get back to you with the results. For now, thanks for the great analysis!

[arzaman]

I'm using an ESP32, which is many times faster than the M0 processor you are using. And I have quite a lot of ESP32 experience, so I'm sure I2C works properly. I built a separate ESP32/MAX30102 project and that worked perfectly, so I checked the code for any potential problem and I think that the data reading from the sensor is working properly. I also have 2 different MAX30102 boards, and there is no real difference in the results between them

I'm doing same attempt to run the amazing @aromring code running on top of the ESP32
did you fork the project and have a repository for that ?
any direction / suggestions to adapt to ESP32 ? I had some compilation error

_

In file included from C:\Users\arzaman\Documents\Arduino\RD117_ARDUINO\RD117_ARDUINO.ino:35:0:

algorithm_by_RF.h:45:12: error: expected identifier before numeric constant

#define FS 25 // Sampling frequency in Hz. WARNING: if you change FS, then you MUST recalcuate the sum_X2 parameter below!

C:\Users\arzaman\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\libraries\FS\src/FS.h:86:7: note: in expansion of macro 'FS'

class FS
_

If I comment the define USE_ADALOGGER the compilation is OK

will follow also the thread for calibration issue
thank
Davide

[robcazzaro]

I did more tests, and the only possible conclusion is that indeed the IR and RED LEDs are swapped. But the weird thing is that they are not swapped in my code, but on the chip itself (!). For what is worth, I'm using a Chinese MH-ET LIVE MAX30102 module. But I really doubt that Chinese cloners reverse engineered the Maxim part. More likely it's a different silicon revision (I have a contact in Maxim, will try to see if they know anything about it)

According to the MAX30102 datasheet, LED1 is RED, LED2 is IR. And when reading the FIFO, the first 3 bytes are the RED channel values, the following 3 are IR, then repeats for all the samples

But not on my 2 devices. The actual LEDs on the chip are swapped. It's pretty easy to see if that's the case:

In file max30102.cpp, change as follows

if(!maxim_max30102_write_reg(REG_LED1_PA,0x00))   //Choose value for ~ 7mA for LED1
    return false;
if(!maxim_max30102_write_reg(REG_LED2_PA,0x24))   // Choose value for ~ 7mA for LED2
    return false;

According to the datasheet, only the IR LED should be active. But in my case, only the RED one is.

Then I tried

if(!maxim_max30102_write_reg(REG_LED1_PA,0x24))   //Choose value for ~ 7mA for LED1
    return false;
if(!maxim_max30102_write_reg(REG_LED2_PA,0x00))   // Choose value for ~ 7mA for LED2
    return false;

And in this case only the IR LED is active: use a phone camera to look at the LED in a dark room, you will see a faint purple dot, since phone cameras are sensitive to IR (if you use 0x80 instead of 0x24, the IR is even more visible)

So, unsurprisingly, when reading the FIFO, the values are also swapped.

It's trivial to fix, by simply changing one line in the main loop() from"

maxim_max30102_read_fifo((aun_red_buffer + i), (aun_ir_buffer + i)); //read from MAX30102 FIFO

to

maxim_max30102_read_fifo((aun_ir_buffer + i), (aun_red_buffer + i)); //read from MAX30102 FIFO

Just in case, I checked the device RevID and PartID , and I got 0x03 and 0x15

  uint8_t revID;
  uint8_t partID;

  maxim_max30102_read_reg(0xFE, &revID);
  maxim_max30102_read_reg(0xFF, &partID);
  Serial.print("Rev ");
  Serial.print(revID), HEX;
  Serial.print(" Part ");
  Serial.println(partID, HEX);

Would be interesting to know what your MAX30102 reports

As for the ESP32 port, there is really nothing to do. Simply use the right SDA (D21) and SCL (D22) pins and an interrupt pin (I usedD19, changing the oxiInt value to 19), commented out #define USE_ADALOGGER, compiled and everything worked just fine, happily printing values (when valid) in the serial monitor output. The ESP32 has definitely more than enough computing power and memory to handle something like this

Thanks again for the code and the troubleshooting help. Hopefully knowing that some modules might have RED and IR swapped could help other folks. By zeroing out one of the two REG_LEDx_PA
registers it's pretty easy to see if the module follows the datasheet or if LED1 and LED2 are reversed

I would suggest adding part of the above to your troubleshooting steps, to avoid more people pinging you about this if they also use Chinese modules

[arzaman]

As for the ESP32 port, there is really nothing to do. Simply use the right SDA (D21) and SCL (D22) pins and an interrupt pin (I usedD19, changing the oxiInt value to 19), commented out #define USE_ADALOGGER, compiled and everything worked just fine, happily printing values (when valid) in the serial monitor output. The ESP32 has definitely more than enough computing power and memory to handle something like this

I'm still a step back compared to you :-) stil struggling to get some output
I use EP32 pico m5stick board and connected SDA 32 and SCL 33 (if I run ESP32 port scanner I can detect the MAX3012 on the right addres) and oxInt pin to 26
commented out #define USE_ADALOGGER (this still gives me compliation error)

but when I run the code no coversion happens
on serial monitor I just get
Press any key to start conversion
Time[s] SpO2 HR Clock Ratio Corr

but no data

if I run the DEBUG mode I can see the row data of R amd IR led and seems OK

MAX30102.txt
MAX30102.xlsx

so seems conversion won't start
any idea why the conversion is no perfomed ?

thnaks
Davide

[robcazzaro]

Your module, like mine, has the IR and RED channels swapped. So you also need to change the same line I changed into

maxim_max30102_read_fifo((aun_ir_buffer + i), (aun_red_buffer + i)); //read from MAX30102 FIFO

Keep in mind that if the SpO2 reading is not valid, the code doesn't print anything. It only prints when both the heart rate and SpO2 are valid. So when IR and RED are swapped, there is no output unless you use DEBUG, then you will see that it prints -999.0 when there is no valid reading

As I said, I think that the majority of the Chinese modules on sale have swapped IR and RED. It would be possible to check in the main algorithm if the values are swapped and automatically fix it, but IMHO would be a waste of time: after all, it only takes a minute to figure it out and once figured it out, that will never change for the lifetime of the device

Re-read my previous entry, and you will see how to check if your LEDs are reversed

[arzaman]

update
I swap RED and IR reading of the fifo as suggested by @robcazzaro and conversion now works fine !!
I have same Chinese clone module
thanks so much I will never realize such a problem without your help

Davide

[arzaman]

One more question/doubt
I see that in @aromring implementation the INT signal of MAX30102 is is controlled by the SW
From data sheet there are several status when the interrupt is triggered (FIFO data ready etc..), what is the case in this sketch ?
I see other examples that don't use the INT pin so I expect application does continuos polling of the FIFO register, is there any way to avoid INT usage ?...reason is simple save on more wire to the breakout sensor and just rely on I2C bus and simply the connection and wiring
What happens if I force the INT with pull down resistor on the breakout board ?

thanks again for any suggestions
Davide

[robcazzaro]

Davide, it's considered bad Github etiquette to hijack an existing issue to ask unrelated questions. ESP32 port questions might have been on topic, but changes to the code are not

The MAX30102 datasheet is easily available, as are multiple open source MAX30102 libraries that can be used with and without interrupt. The original code is easy to read and well structured, so you can simply use any method to read an array of 100 IR and RED values and invoke the rf_heart_rate_and_oxygen_saturation(() function

Please refrain from adding additional comments on this issue

[aromring]

Rob,
Thank you very much for keeping this forum clean.
Since it was determined the SpO2 problems were related to cloned hardware, I am closing this issue.

[janusf]

You guys are awesome. I had the same problem. Did not realize I got a clone sensor until I read this thread. Thanks!!