aromring / MAX30102_by_RF

Arduino C code for MAX30102 pulse oximetry sensor (MAXIM Integrated, Inc.)
166 stars 73 forks source link

Calibration issue -> Potential issue with maxim_max30102_read_fifo #34

Closed elidonner closed 2 years ago

elidonner commented 2 years ago

Hi Aromring,

Thank you very much for providing such a wonderful (and well documented resource).

I have used your code successfully, and it works great. My issue comes when I try saving my data.

I am using a Seeeduino Xiao BLE Sense, which has a nrf32840 chip that clocks in at 60 Mhz (with 256k of flash, like the M0). I have made a PCB for this project that interfaces the Seeed board with an on board IC SPI flash. I build up a buffer of 4096 bytes of data, including IMU readings, sensor readings, and time stamps. 4096 is the size of one page on my flash memory.

I have created a way to calibrate the LED amplitude to try and maximize the ADC readings without oversaturating the photodiode, it is a very simple proportional feedback loop. If you are curious about how I do this, I have forked your code and have a minimal viable code to show the issue (comments should be pretty clear but please reach out). There is a macro header you can comment and uncomment to see the issue.

My calibration works great, and the readings I get from the sensor are beautiful, when I do not write to the flash memory. When I do write to the flash memory, which introduces a 125 ms delay each time the buffer is dumped, the calibration process goes unstable. I have a number of MAX30102 boards and they all run into the same issue.

I'm including 1 file that has two sheets, one showing the problem with calibration, and one where I do not "write to flash".

Test_Data.xlsx

The reason I thought you may care about this issue, is I think it could potentially be a problem with the max30102.cpp file in the function maxim_max30102_read_fifo. The datasheet suggests that the FIFO_WR_PTR, OVF_COUNTER, and FIFO_RD_PTR be cleared when starting a new SpO2 calculation. (See paragraph three of below excerpt from datasheet).

image

I may be mistaken, but I'm not sure this occurs in the call to calculate the spo2 and HR values (in either your, or maxims original code), please do correct me if I'm wrong. I'm still new to manipulating registers, so I do not fully understand this clearing of the FIFO.

Thank you for any advice on this issue, whether it be in the clearing of the FIFO or any other issues you see in the way I am using your code.

As a bonus, you may, (or may hate) checking out my code. I've included some encoding I do to save memory when writing to my flash memory, as well as python files for reading that encoded data from a txt file straight into excel, I think it's pretty neat.

EDIT: I am using the MAXREFDES117 from Maxim. (not the knockoff).

aromring commented 2 years ago

I am traveling at the moment and won’t be able to look at this issue for the next few weeks. Please include a plot of raw data when writing to flash - at least 2 subsequent readings.

elidonner commented 2 years ago

Thank you very much for the response.

Here is the raw data as requested (with plots) and the calibration feature turned off.

The first sheet is without the write to flash delay included. The second is with the flash delay included.

test.xlsx

I greatly appreciate your help and will update you with any solutions I find.

aromring commented 2 years ago

Hi elidonner, I see that you have significantly modified RD117_ARDUINO.ino code so that it's very different from mine. In addition, the problem appears with the specific Seeeduino hardware which I don't have. I'm sorry, but I won't be able to help you under these circumstances. The raw data coming from the sensor looks good, thus with high probability the problem is related to flash memory write. Is it timing? Is it the broken interrupt assertion? You point to FIFO clearing issue, but this can be easily tested: just call maxim_max30102_init() before each reading to see if it matters. In defense let me bring the example of ADALOGGER which stores data on an SD card - and this process is in principle much slower than writing to flash - all with the existing code and without any problem. Unless you find an actual bug with my code, I consider this issues as closed. Good luck!