Week 6: Prototype Evaluation & Formalising System Architecture

Week 6 was the critical turning point for A.E.G.I.S. While Week 5 was simply about getting the hardware pieces to communicate, this week was about forcing the prototype through real-world logic tests. If the mathematical engine is flawed in a controlled test, it will fail disastrously in a real medical emergency. Therefore, my priority was to evaluate the prototype, break it, and fix the underlying logic before formalising the UML documentation.

Prototype Evaluation & Refinement

During my initial testing of the Raspberry Pi processing hub, I discovered a major flaw in my math. To make the Wi-Fi wave shifts more obvious, I had applied a massive 50x multiplier to the raw subcarrier data. This caused a severe issue: because the multiplier was so high, it amplified microscopic thermal changes in the room. If the room temperature shifted, the variance baseline drifted, and the system would trigger a false "movement" alert in a completely empty room.

The Fix: I completely stripped out the artificial multipliers. By forcing the Python engine to rely strictly on the true standard deviation of the 10-frame rolling buffer, the thermal noise vanished, and the baseline stabilised.

The second critical failure occurred during impact testing. If I dropped a heavy stack of books off a table, the Wi-Fi CSI accurately detected the massive physical wave distortion and immediately flagged it as a fall. Dispatching an emergency response for a dropped book is completely unacceptable. Because Wi-Fi CSI cannot tell the difference between a human mass dropping and an inanimate object dropping, single-sensor logic is inherently flawed.

The Fix: I hardcoded the LD2410C mmWave radar into the master logic loop to act as a definitive cross-reference. The new cause-and-effect logic is absolute: If the Wi-Fi variance spikes above 10.0, the system flags a potential event. It then immediately checks the radar. If the radar detects the micro-movements of human respiration at floor level, but absolutely zero walking macro-movement, only then is a fall confirmed. This completely eliminated the false positives.

Software Requirements Specification

Following the BEng guidelines, I had to formally document the requirements and methodology driving this architecture.

Software Methodology Justification

I am utilising a Hybrid Methodology (combining Waterfall and Agile).

Justification: Because physical hardware procurement relies on rigid shipping times, Waterfall was necessary for the initial build phases. However, because real-world radio frequencies are messy and unpredictable, using Waterfall for the software would be disastrous. If I discovered the thermal noise issue in Week 8 under a strict Waterfall model, I wouldn't be able to step back and fix it. Agile allowed me to constantly rewrite and test the Python engine without shattering the project timeline.

Functional & Non-Functional Requirements

Functional:

The ESP32 network must autonomously generate a continuous 10-FPS UDP stream. If it relies on a user's phone to create traffic, the phone will eventually disconnect to save battery, and the system will starve for data.

The system must calculate kinetic variance using Wi-Fi CSI and cross-reference it with 24GHz mmWave radar data.

Non-Functional:

Absolute Privacy: The system must not utilise any optical camera lenses. If a camera is used, the idea of privacy goes, making it completely unsuitable for high-risk areas like bathrooms.

Latency: The processing and alert state must occur in under 3 seconds. If the Pi's USB buffer jams and delays the alert by 15 seconds, that lost time is life-threatening in an emergency.

User Requirements:

Zero Compliance: The system must operate completely passively. If it requires an elderly user to actively wear a pendant or remember to charge a watch, they will eventually forget. A safety system that relies on human memory is fundamentally flawed.

Design Diagrams (UML)

I have completed the UML diagrams to map out this finalised logic.

Use Case Diagram:

Sequence Diagram: