Skip to content

Balance Meter — Sensor & Data-Flow Prototype Spec (v1)

Date: 2026-06-08 · Author: Gene Lang, PharmD — Director of Pharmacy Operations For: Faraz + Emil (engineering) · Matilda (clinical) · Jamie (product) Grounded in: Engineering_Reference/Hardware_Truth_Synthesis_2026-05-04 (sensors) + Fall_Risk/Balance_Meter_Canonical_Model_2026-05-20 (algorithm). What this is: per Jamie/Gene — reverify each sensor and which Mark it paths to, specify what each sensor measures, at what cadence, and how it's pulled, and map how all inputs flow → transform → calculate → hand to software. The prototype blueprint engineering builds against.

1 · Sensor inventory — reverified, with Mark path

(✅ present · ❌ absent · per the Hardware Truth Synthesis. Corrects loose assumptions floating in older docs.)

Sensor Mark I Mark II What it gives the Balance Meter
6-axis IMU (LSM6DSV320, 320 Hz accel+gyro) ✅ ✅ The workhorse. Gait (speed, cadence, asymmetry, step-timing variability, double-support, sway), sit-to-stand transitions, turns, activity (steps/active-min), free-fall + impact (fall candidate), posture/orientation
Barometric pressure ❌ ✅ Height-loss-to-floor → fall confirmation (~12–25 Pa drop); stairs/floors climbed
PPG (optical HR) ❌ ✅ (Enhanced set) Resting HR, HRV, orthostatic HR response (standing check), exertion HR
Wear-detection (optical green-LED+photodiode OR capacitive) ❌ ✅ On-skin confirmation → gates alerts + data validity
Microphone + speaker ✅ ✅ Mark II: the 9-intent fall-confirm voice ("Did you fall?"); (impact-sound corroboration optional)
GPS (GNSS) ✅ ✅ Location for SOS / outdoor context (not a balance signal)
Capacitive touch (AT42QT2030) ✅ ✅ UI/button input; Mark I uses it as a wear-state proxy (not a true wear-detect)
LTE-M + NTN satellite + BLE ✅ ✅ Connectivity (SOS path; BLE to phone)
Magnetometer (per Apr-5 chip BOM) ⚠ confirm ⚠ confirm Heading — would sharpen turn detection. Flag to confirm with Emil.

Two load-bearing corrections: - Fall detection is a Mark II product feature. Mark I firmware (v0.2) runs an IMU fall-candidate cascade (free-fall→impact→stillness→FALL_DETECTED 0x02) but no auto-SOS (manual confirm only) and no product-level fall detection. Barometer confirmation + the AI voice cascade are Mark II. - Heart / orthostatic / sleep are Mark II only (need PPG). Mark I is IMU-only → movement signals, the band "learning," ~60–70% of the full signal.

2 · Per-sensor measurement & cadence

Sensor Raw rate Computed on-device → what & how often Pulled how
IMU 320 Hz accel+gyro, continuous DSP per walking bout → gait feature vector; fall state machine runs always; activity aggregated per minute/day Features + events over BLE (never raw 320 Hz)
Barometer 1–5 Hz baseline; burst 10–25 Hz on impact trigger altitude-Δ inside the fall state machine; stairs aggregated daily Event-driven + daily summary
PPG windowed resting HR every few min at rest · HRV overnight · orthostatic HR captured on a detected stand event · exertion during activity Aggregated metrics
Wear-detect low-rate continuous on-skin true/false; gates all outputs State flag
Microphone event-triggered only (on a fall candidate → listen window) speech→intent (9 categories); no continuous recording (privacy) Event
GPS low-rate / on-demand fix on SOS or geofence On-demand

Principle: extract features on-device, sync summaries + events — not raw streams. That's what makes it battery-, privacy-, and bandwidth-viable at 6M users (ties to the AI-Foundation "cache/compute at the edge" rule).

3 · The data-flow pipeline (four stages)

flowchart TD
  subgraph BAND["① BAND · on-device (real-time, works offline)"]
    IMU["IMU 320Hz accel+gyro"]:::s
    BARO["Barometer · Mark II"]:::s2
    PPG["PPG · Mark II"]:::s2
    WEAR["Wear-detect · Mark II"]:::s2
    MIC["Microphone"]:::s
    DSP["On-device DSP<br/>gait features · fall state machine · HR features"]:::proc
    IMU-->DSP; BARO-->DSP; PPG-->DSP; WEAR-->DSP; MIC-->DSP
  end
  DSP -->|"features + events (BLE)"| AGG
  subgraph PHONE["② PHONE companion"]
    AGG["Aggregate → daily metrics + cache"]:::proc
    QX["Questionnaire (STEADI) + meds<br/>→ Layer 1 inputs"]:::in
    UI["Member UI · band + insights"]:::out
  end
  AGG -->|"de-identified"| L1
  QX --> L1
  subgraph CLOUD["③ CLOUD"]
    L1["Layer 1 baseline = sensitivity gauge"]:::proc
    NORM["Personal 30-day normal (per metric)"]:::proc
    L2["Layer 2 deviation vs own normal<br/>· delta-gate tightened by Layer 1"]:::proc
    BANDOUT["Band: Steady / Some Change / Worth a Look"]:::out
    LEARN["Learning loop → validate → clinical sign-off"]:::proc
    L1-->L2; NORM-->L2; L2-->BANDOUT; BANDOUT-->LEARN
  end
  BANDOUT --> MEMBER; BANDOUT --> PHARM; BANDOUT --> CARE
  subgraph OUT["④ OUTPUTS"]
    MEMBER["Member · qualitative band, no number"]:::out
    PHARM["Pharmacist clinical view · numeric + breakdown"]:::out
    CARE["Caregiver digest"]:::out
  end
  DSP -.->|"fall event · real-time, on-device"| SOS["SOS cascade (voice → contacts → 911)"]:::alert

  classDef s fill:#E6F2EA,stroke:#3F7A52,color:#1E4D30
  classDef s2 fill:#F3E8EF,stroke:#741E4F,color:#741E4F
  classDef proc fill:#fff,stroke:#8F3968,color:#241C1A
  classDef in fill:#FBF0DC,stroke:#B67A2A,color:#7A4E12
  classDef out fill:#EDE7F3,stroke:#5B3A8F,color:#3A2363
  classDef alert fill:#F6D9DC,stroke:#B23A48,color:#7A1F2B

The rule that governs the pipeline: fall detection is on-device and offline-safe (latency + reliability); the barometer band is computed in the cloud (it needs the personal-normal model + the Layer-1 sensitivity); member output is always qualitative (the deterministic rail, no number).

4 · The calculation chain (raw → band)

Signal computation detail (sampling, windowing, gait-event/bout detection, sit-to-stand method) lives in Product_Specs/Fall_Barometer_Gait_Biomechanics_Signal_Pipeline_2026-06-30.md — the "on-device IMU gait-feature extraction" prototype named as the single most important unbuilt piece in §7 below now has a cited technical grounding (incl. why wrist-worn gait sensing is a harder problem than the foot/waist-sensor literature this repo previously leaned on).

  1. Raw IMU → gait features (on-device, per bout): speed · cadence · asymmetry · step-time variability · double-support · sway; sit-to-stand transition time; turn smoothness.
  2. Features → daily metrics (phone) → 30-day personal baseline (cloud).
  3. Layer 1 baseline (STEADI questionnaire + meds + conditions) = the sensitivity gauge: it scales the gait-drift threshold (~18%→10% Some Change / ~25%→16% Worth a Look) and tightens the comparison window (30 d → 7–14 d for ~2 wks after a med change).
  4. Layer 2 deviation: today's gait vs the personal normal → if it clears the Layer-1-tightened delta gate, the band shifts. (Med change ≠ a score bump — it temporarily raises sensitivity.)
  5. Mark II corroboration: resting HR/HRV trends + the orthostatic stand-check response sharpen confidence.
  6. Fall detection (parallel lane): free-fall → impact → altitude drop (Mark II) → stillness/orientation → voice confirm (9-intent) → SOS resolution.

5 · Capability by Mark (the prototype path)

Mark I (the pilot) Mark II
Sensors IMU + mic + GPS + cap-touch + barometer + PPG + wear-detect
Balance Meter movement features + Layer 1 baseline; band "learning" (~60–70% signal) full calibrated band + heart/orthostatic + sleep
Falls IMU fall-candidate, manual confirm fall detection + barometer confirm + auto-SOS
Member sees profile + movement + "learning" the full live band + heart + sleep

6 · What to prototype now (the build list)

  • On-device IMU gait-feature extraction — the core DSP (firmware/embedded). The single most important prototype.
  • Layer 1 baseline calculator (STEADI + meds → sensitivity) — pure software, buildable today, no hardware. Validate against the 754-senior cohort.
  • Personal-baseline + deviation engine — software; the delta-gate logic.
  • Fall state machine — firmware v0.2 exists; extend (barometer + voice for Mark II).
  • Calibration — the delta-gate cutoffs are mechanism-locked, numbers pending the pilot.

7 · Hand-off to software (the contracts)

  • The medication object + FHIR + event schema (from AI_Foundation_Sprint_A-B_Specs).
  • On-device → phone → cloud feature packets + the BLE event grammar (0x02 FALL_DETECTED · 0x03/0x04 cancels · 0x05 candidate · 0x06 recovered — already defined).
  • The de-ID gateway + the deterministic clinical-line rail before any member output.

8 · Open / to confirm

  • Magnetometer presence (Apr-5 chip BOM) for turn/heading.
  • PPG in the Mark II minimum vs Enhanced set.
  • On-device compute budget for the gait DSP (Emil).
  • Calibration data from the pilot (the delta-gate numbers).
  • Sit-to-stand & turns: confirm these are derivable passively from natural movement (no prompted test — the safety rule holds).

Next: render the §3 data-flow diagram, and (with Emil) pin the on-device vs cloud split per signal + the compute budget. Companions: Hardware Truth Synthesis · Canonical Model · AI_Foundation Sprint A–B specs.