A sensor board, a numeric display and a feedback motor can make a prototype look finished. The harder question is what the displayed number means. For a team exploring optical sensing, that question has to be answered before the interface presents a value as a physiological measurement, and in a product with health implications it decides the whole evidence plan.
On our bench we built a small integration prototype in a clear case: a MAX30100 optical sensor module, a four-digit display and a vibration motor module, all driven by a Raspberry Pi Pico on a Graft carrier and programmed in BIPES blocks that generate MicroPython. The project was framed as a blood-oxygen estimate. What the code and the bench run actually support is narrower: reading two optical channels and pushing a computed integer to a display.
Follow the value all the way to the display
The program initializes the MAX30100 on I2C0, with SDA on GPIO4 and SCL on GPIO5, updates the sensor and reads the red and infrared channel values. It checks that the infrared value is nonzero before dividing. That avoids one arithmetic failure; it says nothing about whether the signal is any good.
The program then computes:
value = 100 - 25 * red / ir
converts the result to an integer and sends it to the four-digit display. A vibration motor runs when the value falls below a threshold.
We have no validated derivation for that expression, no calibration data, no waveform analysis and no comparison with a reference instrument. The expression must not be used to interpret anyone's blood oxygen. It is a placeholder that turns two channel readings into a number that fits on a display, and the number looks more authoritative than it is because it lands near familiar values.
Keep versions separate instead of inventing one clean history
We had two versions of this program. One drove the display on pins 21 and 20, the motor on GPIO6 and triggered below 70. The other drove the display on pins 7 and 8, the motor on GPIO9 and triggered below 80. The written description of the project also mentioned formatting and thresholds that matched neither.
Those are different configurations, and neither threshold has a medical basis. It would be misleading to combine the clearest parts of each into one tidy "measurement session" that never happened. When a prototype drifts through several versions, record which code, pins and thresholds were running for each observation. Otherwise nobody can tell later which result belongs to which build.
Treat the module as one part of a measurement system
Analog Devices describes the MAX30100 as integrating LEDs, a photodetector and signal-processing circuitry. That component description does not validate the formula above or the assembled device. The product page also marks the MAX30100 as obsolete. That matters if you are choosing parts for a new design rather than studying an existing module: an obsolete sensor is a supply risk before the first batch is built.
The measurement system includes far more than the chip. How the finger or skin meets the sensor, ambient light leaking in, motion, the LED drive settings, the sampling rate and the processing between raw samples and the final number all shape the result. A single expression applied to one pair of readings skips almost all of that.
What a bounded next step looks like
For an engineering next step that stays honest, keep red and infrared values labeled as sensor channels in the interface and the logs. Record the raw samples over time rather than a single reading, and watch how they change under controlled optical conditions: covered, uncovered, in steady light and with deliberate motion. That shows whether the mechanical arrangement and the sampling produce a usable signal at all.
Do not put a health label on the display while that work is still open. A product that makes physiological claims needs a substantially different evidence and validation program, with reference measurements and the right expertise, and this bench prototype does not provide any of it.
The general issue is the same one that comes up whenever raw sensor values become a display: connecting a sensor to a screen is not the same as establishing what the result means. Decide what the number is allowed to claim, then design the test that would support that claim, before the enclosure and the interface make the prototype look further along than it is.