# HaloCare Stage 2 Prototype

**Product and technical documentation**  
Version: 0.1  
Status: MVP design specification  
Date: 2026-08-06

## 1. Purpose

HaloCare is a camera-free, contactless home-safety prototype for older adults. Stage 2 observes changes in the indoor Wi-Fi radio environment from two positions, detects motion patterns that may be consistent with a fall, checks whether movement decreases afterward, and exposes the result on a private local dashboard. A 60 GHz MR60BHA2 sensor adds bedside presence, breathing-rate, and heart-rate trends.

The prototype is intended to generate an **assistive safety alert**. It is not a medical device, does not diagnose a fall or stroke, and must not replace an emergency call system, caregiver supervision, or clinical assessment. In particular, Stage 2 cannot reliably determine that a person has had a stroke. It can only report observable proxies such as unusual motion, prolonged immobility, or missing expected activity.

## 2. Stage 2 scope

### Included hardware

| Component | Quantity | Function |
|---|---:|---|
| Raspberry Pi Zero 2 W | 1 | Local gateway, room-level fusion, event service, and dashboard host |
| ESP32-S3 N16R8 with external-antenna connector | 2 | Wi-Fi CSI capture, edge DSP, and local fall-feature generation |
| Matched 2.4 GHz 50-ohm antenna | 2 | One independent antenna for each ESP32 node |
| Seeed MR60BHA2 kit or module | 1 | Static presence and bedside breathing/heart-rate trends |
| Existing 2.4 GHz Wi-Fi router/access point | 1 | Stable packet illuminator and local IP network |
| Regulated power system | 1 | Recommended 5 V/4 A supply with switched, fused distribution |

The `N16R8` designation provides 16 MB flash and 8 MB PSRAM. The selected development board must also expose a U.FL/IPEX antenna connector; memory size alone does not guarantee external-antenna support. Each ESP32 requires its own antenna. Antenna splitters are not used.

### Explicitly outside Stage 2

- Clinical fall or stroke diagnosis.
- Emergency-service dispatch without a human confirmation policy.
- Camera, microphone, or wearable-based monitoring.
- MR60FDA2 radar fall confirmation.
- Whole-home multi-room routing or localization.
- Cloud processing as a normal operating requirement.
- Continuous long-term storage of raw CSI.

## 3. Product behavior

HaloCare Stage 2 provides four principal functions:

1. **Presence and motion awareness.** The ESP32 nodes observe how received Wi-Fi subcarriers change as a person moves through the room.
2. **Possible-fall alerting.** Each ESP32 computes motion energy and phase acceleration. A high-acceleration event is debounced locally before being reported as a possible fall.
3. **Cross-node confirmation.** The Pi compares events from two geometrically separated ESP32 nodes. Correlated activity is more credible than a disturbance seen by only one node.
4. **Bedside context.** The MR60BHA2 reports presence and breathing/heart-rate trends when the subject is appropriately positioned, primarily during sleep.

The MR60BHA2 is not the Stage 2 fall detector. Its role is complementary context. Seeed specifies static-presence detection up to 6 m and vital-sign monitoring within approximately 1.5 m, with sleep-oriented positioning recommended. See the [MR60BHA2 setup documentation](https://wiki.seeedstudio.com/getting_started_with_mr60bha2_mmwave_kit/).

## 4. System architecture

```mermaid
flowchart LR
    AP["2.4 GHz Wi-Fi router / AP"]
    E1["ESP32-S3 node A\nCSI + edge DSP"]
    E2["ESP32-S3 node B\nCSI + edge DSP"]
    BHA["MR60BHA2\npresence + vital trends"]
    PI["Pi Zero 2 W\nfusion + event service"]
    UI["Local dashboard\nphone / tablet / computer"]

    AP -->|"Wi-Fi packets"| E1
    AP -->|"Wi-Fi packets"| E2
    E1 -->|"UDP features / optional CSI"| PI
    E2 -->|"UDP features / optional CSI"| PI
    BHA -->|"UART through node or local MQTT"| PI
    PI -->|"HTTP + WebSocket on LAN"| UI
```

This is a centrally aggregated sensing network. The ESP32 devices normally send data directly to the Pi over the existing Wi-Fi infrastructure. They do not need to forward application traffic through one another.

## 5. How detection works

### 5.1 Wi-Fi CSI acquisition

Channel State Information describes the amplitude and phase response of Wi-Fi subcarriers for a received packet. A moving body changes multipath propagation, creating temporal patterns that can be analyzed without capturing an image or recording speech.

Each ESP32 is assigned a unique `node_id` and installed at a different angle to the monitored area. The nodes use the same stable Wi-Fi environment and send timestamped feature or CSI packets to UDP port 5005 on the Pi.

### 5.2 Processing on the ESP32

The current RuView firmware implements an edge DSP path that calculates motion and vital-sign features. Its fall flag is based on phase acceleration, consecutive-frame confirmation, and a cooldown. The implementation is in [`edge_processing.c`](../firmware/esp32-csi-node/main/edge_processing.c).

Edge processing has three advantages:

- immediate response without waiting for a cloud service;
- lower LAN bandwidth when feature packets are used instead of continuous raw CSI;
- continued local detection logic if the dashboard client disconnects.

The ESP32 output is an event indicator, not proof that a fall occurred.

### 5.3 Two-node fusion on the Pi

RuView contains multistatic fusion that increases the weight of motion observed by multiple nodes and suppresses energy isolated to one viewpoint. The relevant implementation is [`multistatic.rs`](../v2/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs).

For HaloCare, Stage 2 adds or configures a room-level fall state machine around those signals:

1. Receive features from node A and node B in a common time window.
2. Normalize each node against its own empty-room baseline.
3. Raise confidence when both nodes observe a compatible impulse close in time.
4. Reduce confidence when only one node reports the event or its signal quality is poor.
5. Observe the following 10-30 seconds for reduced motion while presence remains likely.
6. Create a local alert with the contributing evidence and sensor-health status.
7. Apply a cooldown and require explicit reset or resolution in the dashboard.

Exact thresholds and time windows are calibration parameters. They must be measured in the deployment room and are not accuracy claims.

### 5.4 MR60BHA2 fusion

RuView firmware includes a UART parser for MR60BHA2 presence, heart rate, and breathing rate in [`mmwave_sensor.c`](../firmware/esp32-csi-node/main/mmwave_sensor.c). Parsed radar data can be combined with CSI data in the edge feature packet.

Two integration options are supported by the Stage 2 design:

- **Direct UART:** connect a compatible MR60BHA2 module interface to one ESP32-S3 and use the existing firmware parser.
- **Standalone kit:** retain the XIAO controller supplied with the Seeed kit and publish readings locally to the Pi using MQTT or another LAN-only bridge.

The standalone route is preferable when the purchased kit does not expose a convenient raw UART connection. In either arrangement, vital-sign values are contextual telemetry and must not be used as clinical measurements or as the sole reason to suppress a possible-fall alert.

## 6. Edge AI and the quantized model

RuView publishes a pretrained CSI encoder and presence head at [`ruvnet/wifi-densepose-pretrained`](https://huggingface.co/ruvnet/wifi-densepose-pretrained). The encoder produces a 128-dimensional representation of a CSI feature window. The published bundle includes:

| Format | Approximate weight size | Stage 2 status |
|---|---:|---|
| `model.safetensors` | 48 KB | Supported by the sensing-server model path |
| Native RVF / `model.rvf.jsonl` | Small host representation | Supported or converted by the sensing server |
| `model-q4.bin` | 8 KB, 4-bit quantized | Published, but a compatible runtime reader is not yet wired into this build |

For the first Stage 2 build, HaloCare should run the supported safetensors or RVF representation on the Pi Zero 2 W. The model is small enough that an AI HAT is unnecessary. The 8 KB Q4 version is a later optimization after its reader, dequantization/inference path, and output equivalence have been implemented and tested.

The quantized model is not a trained clinical fall or stroke classifier. It supplies compact CSI embeddings and a presence head. The fall decision continues to use edge motion features, two-node correlation, post-event immobility, room calibration, and later independent radar confirmation.

In principle, the Q4 model is small enough for an ESP32-S3 N16R8, but model size is not the same as a working embedded runtime. Executing it on the ESP32 requires a compatible INT4 inference implementation and validation against the supported host output.

## 7. Privacy-preserving design

HaloCare is privacy-preserving by design, but RF-derived occupancy and activity data are still sensitive personal data and must be protected accordingly.

### Data minimization

- No camera or microphone is required.
- Normal operation transmits compact features and events rather than images, audio, or continuous raw CSI archives.
- Raw CSI capture is disabled by default after installation and is enabled only for bounded calibration or troubleshooting sessions.
- The event store records the minimum useful information: timestamp, room, confidence, contributing node IDs, sensor health, and resolution status.
- Vital-sign trends use short rolling windows; unnecessary historical samples are deleted.

### Local-first operation

- Detection, fusion, model inference, storage, and dashboard serving run inside the home.
- Internet connectivity is not required for the normal sensing loop.
- No telemetry is uploaded by default.
- Any future remote-caregiver access must be opt-in and use a VPN or authenticated encrypted gateway rather than router port forwarding.

### Network and application security

- Place the ESP32 nodes and gateway on a dedicated WPA2/WPA3 IoT SSID where possible.
- Give the Pi a reserved local IP address.
- Set `RUVIEW_API_TOKEN` and a strong random value.
- Bind to `0.0.0.0` only when LAN access is required, and configure the Pi address or hostname as an allowed host.
- Restrict dashboard ports to the local subnet with the host firewall.
- Use unique device credentials for a product pilot; do not ship shared default passwords.
- Do not expose UDP, HTTP, WebSocket, MQTT, or SSH ports directly to the internet.

The sensing server defaults are HTTP 8080, WebSocket 8765, UDP 5005, and loopback-only binding. The server configuration is defined in [`main.rs`](../v2/crates/wifi-densepose-sensing-server/src/main.rs).

## 8. Dashboard

The Pi hosts the dashboard, but the browser normally runs on the caregiver's phone, tablet, or computer. This keeps the Pi Zero 2 W workload small.

The Stage 2 dashboard should display:

- overall state: normal, attention, possible fall, or sensor fault;
- last event and resolution status;
- node A and node B connectivity, RSSI, frame age, and calibration status;
- room presence and motion trend;
- MR60BHA2 presence, breathing trend, and heart-rate trend;
- clear labels stating that vital signs and event classifications are non-clinical;
- an acknowledge/reset control and an audit entry for the response;
- a visible degraded-mode warning when a sensor is offline.

The dashboard must never silently present a one-node result as a fully fused two-node result.

## 9. Physical installation

### ESP32 placement

- Install the two nodes on different sides or angles of the monitored room.
- Do not mount the antennas immediately beside each other or inside a metal enclosure.
- Keep antennas vertical and separated from switching power converters and dense wiring.
- Avoid placing both nodes on the same wall with nearly identical propagation paths.
- Record node coordinates and orientation as part of calibration.

### MR60BHA2 placement

- Use it primarily near a bed.
- Follow the vendor's sleep-oriented guidance and keep the chest within approximately 1.5 m for vital-sign monitoring.
- Do not aim through metal, thick furniture, or moving curtains/fans where avoidable.
- Treat presence coverage and vital-sign coverage as different operating ranges.

### Power

Use one certified, regulated 5 V/4 A supply for Stage 2 with a main switch, main fuse, and star-wired distribution. Each board receives its own short power and ground branch. Do not use a passive USB Y-cable. The Pi, router/access point, and sensors must all be backed up if operation during a mains outage is a requirement.

## 10. Calibration and verification

Every installation has different multipath behavior. Stage 2 therefore requires room-specific calibration.

### Commissioning sequence

1. Verify correct node IDs, firmware versions, target Pi address, and packet reception.
2. Capture an empty-room baseline with doors, fans, and normal appliances in representative states.
3. Capture normal activities: walking, sitting, lying down, getting into bed, and picking up objects.
4. Perform safe, supervised fall-like tests using a mannequin or controlled protocol with appropriate protection.
5. Test one-node outage, radar outage, Wi-Fi interruption, Pi reboot, and power restoration.
6. Adjust thresholds using a separated calibration set; do not tune on the same trials used to report results.
7. Run an extended idle and normal-activity soak before any occupied pilot.

### Acceptance evidence

The MVP review must report separately:

- **Measured:** results reproduced on the actual Stage 2 hardware in the target room.
- **Claimed:** manufacturer or upstream-project statements not reproduced by HaloCare.
- **Target:** desired requirements that have not yet been measured.

Required evidence includes raw event timestamps, ground-truth labels, missed events, false alerts, sensor uptime, packet loss, recovery behavior, firmware/model versions, and the calibration configuration. No sensitivity, specificity, latency, or medical-performance number should be published without this evidence.

## 11. Failure and safety behavior

- If one ESP32 fails, the system enters degraded single-node mode and lowers confidence.
- If both ESP32 nodes fail, fall sensing is unavailable and the dashboard raises a sensor fault.
- If MR60BHA2 fails, CSI fall monitoring continues, but vital-sign context is marked unavailable.
- If the Pi or local network fails, the ESP32 edge flags may still be computed but cannot be assumed delivered; the product must visibly indicate loss of service after recovery.
- If data is ambiguous, the system reports uncertainty instead of presenting a definitive diagnosis.
- A manual SOS button and local audible indicator are recommended before an elderly-care pilot.

## 12. Stage 3 reference architecture

Stage 3 expands Stage 2 into a multi-room pilot:

| Addition | Purpose |
|---|---|
| MR60FDA2 | Independent, ceiling-mounted fall indication from height/point-cloud change in a small high-risk room |
| Additional ESP32-S3 nodes | Coverage for bedroom, bathroom, living room, or hallway zones |
| Pi 4 or another 2+ GB ARM64 gateway | Headroom for containers, Home Assistant, database/history, and more simultaneous room services |
| MQTT broker | Normalized events and health telemetry from radar and room nodes |
| Wi-Fi infrastructure mesh or access points | Network coverage without making ESP32 packet relaying part of the safety-critical path |
| Room-scoped fusion | Prevent unrelated motion in one room from confirming an event in another |

Stage 3 should use a star-style application topology: every room node sends directly through the home Wi-Fi infrastructure to the central gateway. A consumer Wi-Fi mesh may extend network coverage, preferably with Ethernet backhaul and stable channels. A true ESP-WIFI-MESH relay chain is not recommended for the MVP because it adds routing dependencies, timing variability, and harder fault diagnosis.

The MR60FDA2 becomes the independent fall-confirmation modality in Stage 3. Its result should be combined with two-node CSI agreement and post-event immobility, while still reporting disagreement and uncertainty. It does not turn the system into a clinically validated detector.

## 13. Stage 2 delivery checklist

- [ ] Two ESP32-S3 N16R8 external-antenna boards assembled, each with one matched antenna.
- [ ] Unique node IDs provisioned and visible on the Pi.
- [ ] Pi Zero 2 W running a 64-bit Lite OS and release build.
- [ ] MR60BHA2 integration path selected: direct UART or standalone MQTT.
- [ ] 5 V/4 A regulated supply and fused star distribution installed.
- [ ] Empty-room and normal-activity calibration completed.
- [ ] Two-node fall-fusion state machine implemented and versioned.
- [ ] Supported safetensors/RVF model loaded, or model-free fallback explicitly recorded.
- [ ] Q4 model labeled pending until a compatible reader is verified.
- [ ] Dashboard token, allowed-host configuration, firewall, and retention policy configured.
- [ ] Sensor-offline and degraded-mode behavior tested.
- [ ] Safe test protocol and ground-truth event log completed.
- [ ] Product labeling states assistive, non-clinical operation and documents emergency limitations.

## 14. Repository references

- [RuView overview and pretrained-model status](../README.md)
- [ESP32 CSI firmware](../firmware/esp32-csi-node/)
- [MR60BHA2/LD2410 UART integration](../firmware/esp32-csi-node/main/mmwave_sensor.c)
- [ESP32 edge processing and fall features](../firmware/esp32-csi-node/main/edge_processing.c)
- [Multistatic fusion](../v2/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs)
- [Sensing server](../v2/crates/wifi-densepose-sensing-server/src/main.rs)
- [MR60BHA2 vendor guide](https://wiki.seeedstudio.com/getting_started_with_mr60bha2_mmwave_kit/)
- [Raspberry Pi Zero 2 W specifications](https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/)