When you’re trying to do something that has a high probability of failure/low probability of success, it probably is so because P(A&B) is P(A)*P(B) when A and B are independent events. Say A succeeds 1 in 10 times, and B is similar, the net probability of success is 1 in 100. The easiest way to improve your odds is to break this large chunk of work into smaller independent blocks, which are then worked upon until they have large probabilities of success. Then these blocks are put back together, which increases their probability of success. One might argue that the process of putting blocks together introduces new complications and handshake errors. With enough attention to detail, these can be avoided.
A system to obtain SpO2, HR and RR comprises of multiple independent (arguably) stages. There’s a data acquisition stage, followed by the data processing and user interface stages. The data acquired by the sensor communicates to the microcontroller through I2C and also operates on 1.8V necessitating external circuitry for interfacing. Once the data is acquired by the microcontroller, multiple DSP algorithms need to work on the photoplethysmograph (PPG) to extract respiration induced variations. The user interface involving light/sound/tactile routes form the final piece of system.
Thinking out loud, there are a few things that could be done to speed up the process of development
- Get a MAX30102 evaluation board (which comes with I2C code to interface to an Arduino). This eliminates most sources of failure at the data acquisition and communication stages. Some of these could be
- Poor contacts during soldering
- Mistake in PCB design
- Firmware issues (i2c communication protocol)
The code running on the arduino can be modified such that it prints the SpO2 value to the serial port. At this stage, the acquisition circuit and sensor can be simply viewed as a blackbox that takes a finger/earlobe and outputs the SpO2 value. This modularity makes the data processing part easier. (the data processing also needs to be done separately, as the atmega 328 is not powerful enough to implement advanced DSP algorithms). Implementing a blackbox for mobile applications is slightly difficult, involving either datalogging using an SD card, or wireless bluetooth transmission. However, the lack of a gold standard (self measured RR for example) to compare these results against renders any efforts in those directions almost useless.
- Use MATLAB functions to apply the custom filters required to extract RR in real time. There’s serial data input into MATLAB, so it can accept the data that it receives from the Arduino. Once we achieve a proof of concept that RR can be reliably extracted from PPG, the code for the algorithms can be implemented for embedded systems (I’d love to stick with atmega since its the only thing I know, but maybe I need to push myself out of my comfort zone). PJRC’s teensy 3.2 that has a ARM Cortex M4 (sweet sweet 72Mhz) and 32x more RAM + 8x more flash might be something to tack on the next oshpark order.
- The user interface can similarly be prototyped separately, to decice how loud the sound/ what colours/frequency/intensity the lights need to be to attract a bystander’s attention. More discussion with stakeholders needs to happen to better understand the environment in which overdoses happen.
That being said, the technical requirements/adventures must not take away from the original goal of this effort – to make an ultra low cost vital signs monitor that can act as an early alert system for fentanyl overdoses. I can’t imagine the BOM of such a device being greater than $10. Additional roadblocks towards making a tangible difference with this device might be a classification of this device as a medical device (which it most likely it is), unless I could paste an analog watch face on the top and label it a wellness device (srs, not srs but hlf srs).