-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't get SpO2 to work #13
Comments
Hi Rob, |
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. |
:) 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. |
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! |
I'm doing same attempt to run the amazing @aromring code running on top of the ESP32 _ 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 |
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
According to the datasheet, only the IR LED should be active. But in my case, only the RED one is. Then I tried
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"
to
Just in case, I checked the device RevID and PartID , and I got 0x03 and 0x15
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 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 |
I'm still a step back compared to you :-) stil struggling to get some output but when I run the code no coversion happens but no data if I run the DEBUG mode I can see the row data of R amd IR led and seems OK so seems conversion won't start thnaks |
Your module, like mine, has the IR and RED channels swapped. So you also need to change the same line I changed into
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 |
update Davide |
One more question/doubt thanks again for any suggestions |
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 |
Rob, |
You guys are awesome. I had the same problem. Did not realize I got a clone sensor until I read this thread. Thanks!! |
@robcazzaro Have you followed up on this issue to see whether this behavior is specific to a certain silicon revision of MAX30102 or the chips used on MH-ET LIVE MAX30102 are indeed clones expressing this kind of behavior? I tried to contact the guys at Maxim about this but didn't have any luck... P.S. I also noticed that in addition to IR and red led channels being swapped, both PPG_ RDY and ALC_ OVF interrupts don't work either on this particular board. |
@Alireza9900 I tried to get answers from Maxim, but never got a reply. If you get one, please share. The MAX30102 is a pretty old and simple chip and mostly used by hobbyists. So it wouldn't be that hard to clone and it wouldn't surprise me if many of the cheap eBay modules use cloned chips. After all, the STM32F103 series chips have been cloned by many Chinese makers, and that's a much harder chip to clone |
Alireza and Rob, |
@aromring I think you completely missed the point of the discussion. There are 2 possibilities here:
We are trying to get an answer from Maxim on "did you spin a revision with swapped LEDs?". If the answer is "no", then we will know for sure it's a clone and very likely much more than just the swapped LEDs are a problem (very likely in that case the readings are also going to be poor quality). And we can then share the knowledge with sites like Hackaday and others to warn other hobbyists. As things are now, there is only speculation. Something like this, to be clear https://hackaday.com/2020/09/15/deep-sleep-problems-lead-to-forensic-investigation-of-troublesome-chip/ If on the other hand Maxim created a different revision, then we know it's a simple fix and once again can share the knowledge. And know that once you swap the LEDs in the code, everything else works as expected Nobody is trying to hold Maxim responsible in any way for problems created by a potential clone. Just get more info on what happened, and know more. And I strongly believe it's in Maxim's interest to let people know if a counterfeit chip exists, since it might otherwise reflect poorly on them |
OK, fair enough, I stand corrected. However, if that's the case, then Maxim's silence is deafening in spite of numerous people asking this question. IMHO, it means that Maxim at least think of the scenario 2 rather than 1. |
Well, in my case it actually means that my contact left Maxim, so I never could get an answer :) not that Maxim refused to answer. I pinged another contact today and I will see if I get a reply. But you have to realize that, since this is not a work request, Maxim employees might simply prioritize it too low to answer (and I said as much in my request, I cannot burn my goodwill with a Maxim employee I interact thru one of my consulting projects. I'm sure Maxim people are plenty busy answering questions from actual customers who buy hundreds of chips, not hobbyists with a curiosity. If my module came from an approved distributor, I'm also sure that they would have jumped on it. But since it was a one off from eBay, well... So, please, don't read too much into the lack of an answer. It really means nothing in my specific case |
You are right but if I buy from other farmer with a bad taste and I go to the original farmer then he/she must tell me exactly what happened if he/she want to sell me in a future. I will buy him/her if that is the case. But as I can guess there apperas to be a permitted cloned market. Or maybe they don't sell directly assembled chips but only the specifications. So, maybe the ones that we have are "original" but from one of the assemblers that there are lying around. And I need an answer because this chip have the name of MAXIM. So MAXIM is permitting to have they name on something that they don't made? Really? That is something suspicious. Meanwhile the solution is just invert the channels but the doubt is still alive because I don't have the certainty over the specs of this chip. So, if this chip does not meet the specs I want to know. Maxim must write a public letter to clarify this. |
Anyone can post some photo about original and cloned board? I want to confirm if my board is clone one and if channels are reversed. |
Sorry guys, @Anyeos and @moononournation, although I sympathize with your woes this is not the right forum to ask these questions. The right forum is here: https://maximsupport.microsoftcrmportals.com/en-US/support-center/ |
I agree and I will not put future messages about it. But please dont remove the actual ones because it is not out of scope. We are using a library designed for Maxim chips on the first place and there are a relation with how the chip is working. Except the portion about the company decisions but the rest is related. |
I am facing the same problem. Reversed LED Channels that caused erroneous spo2 and Hr measurements in mode 2. To check the sensor I just tried to run it in mode 1 (only RED LED on) and found out that the IR LED was ON instead. Never realised it was this big a problem since there are no other mentions of this issue anywhere else. I wanted to ask a few things -
It's amazing that someone has converted the instructable post into actual working code. Thanks a lot! |
@robcazzaro kudos for your proper research and your conclusion on the LED swap on MAX30102 clones. I was facing days with figuring this issue and you just helped me with solving the issue with just changing 2 lines of code. Really appreciate your effort on identifying the issue and suggesting the solution.....!!! |
Thanks to Robcazzaro and Aromring for precious advises. The procedure from robcazzaro perfectly works for me on a esp32 with the MH-ET live max30102. I add some details for newbies like me.
#include <Arduino.h>
Thus, for me, it looks to work pretty well and i'm quite satisfied by the library and the trick of the hardware switch of red and IR led. My only concern is that I can't verify the quality of spo2 in pathologic situation (i.e when spO2 is smaller than 95%) and since i don't have a commercial apparatus, I can't compare data as well but i would bet that comparison may be quite good. Any suggestion to simulate smaller Spo2 to be confident about the data in pathologic situations ? Thanks a lot. Cheers. Via_Fx_24 |
Concerning my previous comment, I made some quick tests with a commercial apparatus that i borrow. Results were very similar. 99% of spo2 for the max30102 (right hand), 97% of spo2 for the commercial one (left hand). A small difference of 2%. Stopping breathing fall to 97% for max30102 et to 95% for the commercial one. Thus the difference (2%) between the two apparatus remains the same giving good confidence in max30102 data. Concerning heart rate, both apparatus found 68 bpm +/- 2. I' m thus quite confident with the data provided by this code and the hardware max30102. This comment may be considered "out of range" concerning the initial question. However I added it to encourage folks that get the MH-ET live max30102 to try the code" MAX30102_by_RF" with the modification proposed by Robcazzaro because it works well, it's an easy modification and results are quite consistent with professional apparatus. Hope it's help. |
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
The text was updated successfully, but these errors were encountered: