Sensor-to-alarm data path in a two-node Raspberry Pi drowsiness monitor

Why use two nodes

PPG acquisition and camera-based EAR processing have different timing and compute loads. Running both on one Raspberry Pi can let frame processing interfere with sensor reads and alarm timing. This prototype separates sensing and analysis, transferring state through the network and file IPC.

The split does not prove better performance. It makes each input, stored state, packet, and output boundary inspectable.

PPG and camera nodes

The PPG sensing node reads samples and produces a physiological state. The camera/EAR node processes frames and calculates an eye-state signal. Public C/C++ source and architecture documentation support the existence of both paths.

The decision path combines the two states before driving alarms. A photograph cannot recover thresholds or accuracy, so module boundaries from source remain separate from wiring and assembly evidence.

Packet, file, GPIO, and I2C path

PPG sensor → sensing process → TCP/IP or shared file state
camera → frame processing → EAR state
PPG state + EAR state → decision path
decision → GPIO LED/buzzer + I2C LCD

A reproducible TCP/IP boundary needs message length, reconnect policy, and sender/receiver roles. File IPC needs protection against a consumer reading a partially written file, such as an atomic rename or explicit ready flag. GPIO needs active-level documentation; I2C needs the LCD address and error handling.

The saved code shows the network, file IPC, GPIO, and I2C paths, but it does not preserve every packet schema and timeout. I still need to rerun packet-loss recovery and stale-file cleanup before describing their behavior.

What the prototype proves

The photographs show the Raspberry Pi hardware, LCD, sensor wiring, and assembly. Reading the PPG-server and image/EAR-processing modules alongside them made the two-node data path clear. I did not put the screen values into a performance table because their calibration conditions are unknown.

Failures and unmeasured items

A two-node design must handle missing frames, dropped TCP connections, stale file state, failed I2C writes, and sensor timeouts. The public material does not verify every retry and fallback path.

I did not find saved measurements for end-to-end latency, sensitivity, specificity, false-alarm rate, or long-duration stability, so I do not present those values as measured performance.

Next verification

The next useful step is a fixed message schema with monotonic timestamps and a shared event ID in both node logs. Fault injection should disconnect the network and stop camera input to confirm that the alarm path moves to a safe state. Until then, prototype existence and performance claims remain separate.