The arduino yun board is not compatible with pulse oximeter sensor (e-health cooking-hack)
I put my finger to pulse sensor but it doesn't reading any values, just keep printing PRbpm= 0 and %SPo2 = 0.
Pulsioximeter.ino (2.22 KB)
Is there a question here? Or are you just stating facts?
I'm going to guess you're asking for help to get it working...
I'm not familiar with the product, but it looks like there are several different library versions, and they say you need the correct version according to the date of manufacture of the board. It looks like there are three different versions that support different versions of the pulseoximeter sensor. First step: are you sure you're using the right library version?
Looking at the library code, I'm not surprised you're having trouble. It looks like it's reading the individual 7-segment LED bars as the display is being multiplexed between different digits. Rather than using any kind of digit synchronization, it's getting an interrupt on one pin (presumably the start of a scan sequence) and then scanning the other pins, delaying, scanning the pins again, delaying, etc. The different versions of the library seems to be scanning a different number of times, and using a different delay with pass.
This is a very fragile way of doing it (as evidenced by the number of code updates they have had to do.) It looks like the delay is very carefully crafted to deal with the interrupt latency delay, and the digitalRead() delay, both of which could vary depending on the actual processor. I can see where it may work well with a '328P processor running at a particular speed (they probably assume you're running at 16 MHz) but could break down if the processor is running at a different speed (like a 3.3V 8 MHz model) or with a different processor. Furthermore, since the USB interface is built into the processor on the '32U4 that is on the Yun, it's entirely possible that the USB code is turning off interrupts at critical times, and that would change the pin interrupt latency, causing you to miss digits.
A much better way to deal with it would've been to capture the micros() value in the pin change interrupt, and then schedule the scans based on the current micros() time value. In this manner, only the initial pin change interrupt latency would've caused timing errors, which would've been bad enough. An even better way would've been to design a more intelligent interface than blindly reading display digit multiplex signals.
I'm sorry that I don't have a better answer for you. From what I see in the quality of the code and the schematics, you're facing an uphill battle to get this working reliably. No wonder they say it's for hobbyist and experimentation use only, and not for medical treatment. This would never pass any kind of medical certifications (I've worked on medical hardware/software projects, and know the kind of testing and certification that is required.)