Skip to content

Rx360 Wearable Firmware — v0.2 State Machine Spec

Date: 2026-04-27 Source: Engineering state diagram (rx360_state_diagram_v0.2.png in this folder) Audience: Product strategy (Peyman, Elliot, Gene), clinical advisor (Matilda), pharmacy operations (Patrice), engineering reference Classification: Internal — engineering reference, lexicon-disciplined

Why this doc exists

The state diagram captures the real firmware behavior on the wearable as of v0.2. It's substantively richer than what's in the Feature-Dream brief or the recent Patrice + Matilda deck. This doc:

  1. Formalizes the diagram into prose so non-engineering readers can follow it
  2. Cross-references against the wellness lexicon to confirm we're lane-disciplined
  3. Names which features exist on the device today vs. which are still spec-only
  4. Surfaces the engineering details that should propagate into product/marketing artifacts

Hard rule reminder: Mark I (RxSIDEKICK) has no fall detection. The fall pipeline below is Mark II / RxBALANCE (v0.2 prototype). The SOS path and medication nudge run on both.

Architecture summary

The wearable runs three parallel state machines plus passive inputs:

Machine Trigger Driven by Mark
SOS path Button press Local hardware Mark I + II
Medication nudge Phone BLE write Companion app Mark I + II
Fall detection IMU cascade Sensor algorithm Mark II only
Passive inputs Cap touch / charge / battery Always-on monitors Both

The three machines run independently; a long-press during a medication nudge can break out into the SOS path, but otherwise they don't interfere. Battery <5% triggers SOS Reservation Mode — audio reminders suppressed, SOS path preserved end-to-end.

1. SOS path (button-driven)

Idle entry conditions

  • Band is worn (cap-touch confirms wrist-on)
  • No active medication nudge or fall event in flight

Button gestures from IDLE

Gesture Duration Action
Short press <300 ms Wake / ack — single green flash, no further action
Long press 3 s Pre-warn haptic at +2 s + chime, then enters SOS GUARD state
Very-long press OR boot-combo (security) Factory reset path — warning haptic buildup → wipe bonds + patterns + reboot, OR factory reset + crash dumps → reboot

SOS GUARD state (post-3-s long press)

  • LED2 fast blink — visible "we heard you, decide now" feedback
  • 3 outcomes:
  • Single press (any button) → CONFIRM → enter SOS pipeline
  • Timeout (3 s) → SOS proceeds automatically (no-cancel default)
  • Long press during SOS guard → CANCEL → return to IDLE

SOS pipeline (after CONFIRM or guard timeout)

  ACQUIRING_GNSS
    target: ≤2 s on OK
    real:   up to 45 s
        ↓
  TX_CELLULAR
    LTE-M, 10 s timeout
        ↓ (on cell fail)
  TX_SATELLITE
    NTN (3GPP Non-Terrestrial Network), 30 s timeout
        ↓
  WAITING_ACK
    15 s timeout
        ↓
   3 outcomes:
   • ACK received   → SOS_CONFIRMED (LED steady, strong haptic)
   • Timeout        → Retry w/ backoff: 30 / 60 / 120 / 240 s, max 3 attempts
   • All retries fail → FAILED

Lexicon implications for the SOS path

  • "Helps connect you to emergency contacts" — borrowed verbatim from Apple's wellness phrasing
  • The retry/backoff math is important to acknowledge in the limitation disclaimer: "RxBALANCE cannot guarantee message delivery in all conditions. Retries with backoff up to 3 attempts."
  • Satellite is NTN, not Iridium — engineering reality is the new 3GPP standard, not the legacy Iridium spec referenced in earlier briefs. Marketing/spec docs need to reflect this.

2. Medication nudge (phone BLE-driven)

Trigger

Phone (companion app) sends a BLE write to the band — this is the only way a medication nudge fires. The band itself does not schedule reminders; scheduling lives in the companion app, which means pharmacist verification of the medication schedule (Hard Rule #4) gates whether the band ever rings.

Gesture grammar on a live nudge

Gesture Action BLE notify back to phone
Short press CONFIRM dose taken type 1 — flash log, dose-confirmed
Double press SNOOZE re-nudge timer armed
Long press Breaks out → enters SOS GUARD (SOS path takes over)
No response (timeout) phone-side reschedule logic decides

Why this matters for the product story

  • The three-gesture grammar (short / double / long) is richer than the "dose-confirmation button" we've been describing in marketing. We should describe the snooze and the long-press-to-SOS escape as features, not implementation details.
  • BLE event coding is the spec-level interface for caregiver-app integration — when the caregiver app surfaces "Mom dismissed at 9:15", that comes from the BLE notify.
  • Confirmation feedback closes the loop — the band lights up after the press, the app shows "confirmed at 9:15", caregiver sees it in the daily digest. This is the pharmacist-verified-data → device-confirmed-event → caregiver-visibility loop that nobody else has.

3. Fall detection (v0.2)

Hardware

  • IMU: LSM6DSV320 (320 Hz accelerometer + gyroscope, low-power tier)
  • Acceleration threshold: < 312 mg sustained ~5 samples → triggers candidate state

Pipeline

  IDLE (passive monitoring)
        ↓
  EVENT_FALL_CANDIDATE
    BLE notify (event code 0x05)
    "We saw something — observing further"
        ↓
  1 s observation window
    Gyro stillness tracking
        ↓
  Branch on movement:
   • User moved   → EVENT_FALL_RECOVERED  (event 0x06) → return to IDLE
   • Still still  → EVENT_FALL_DETECTED   (event 0x02)
        ↓
  30 s SOS guard window opens
    (button-guard window = 5 s)
        ↓
  Outcomes during guard:
   • Single / double press     → CANCEL  (event 0x04)
   • Timeout (no input)        → notes: "no auto-SOS v0.2"  (manual confirmation flow only)
   • Cancel from phone via BLE → SOS Status (active service) cancel (event 0x03)

CRITICAL — "no auto-SOS v0.2"

v0.2 firmware does not auto-trigger SOS from fall detection. A detected fall opens the 30-s guard window, alerts the phone via BLE, and surfaces a UI/haptic prompt. SOS only fires if the user (or caregiver via phone) explicitly confirms.

This is a lexicon win — it lets us truthfully say: - "RxBALANCE helps detect a hard fall and alerts your circle of trust." ✓ - We do not claim "RxBALANCE calls 911 automatically when you fall." (which would push toward 24/7-monitored-PERS regulatory territory)

Apple parallel

Apple Watch fall detection uses a similar guard-window pattern (60 s on Apple, 30 s on us). Mirroring Apple's UX timing is intentional and lexicon-safe.

BLE event code map (engineering interface for caregiver app integration)

Code Event Caregiver-app surface
0x02 FALL_DETECTED Push notification, daily-digest entry
0x03 SOS Status — active service cancel from phone Acknowledgment receipt
0x04 Cancel from band (button) Daily-digest entry; no push
0x05 FALL_CANDIDATE (silent — internal flag for consecutive-event analytics)
0x06 FALL_RECOVERED Daily-digest entry; no push

4. Passive inputs

Cap touch (AT42QT2030)

  • Wrist-on detection — band wakes when you put it on (haptic buzz)
  • Wrist-off detection — band can suppress notifications when removed

Charge connect / disconnect

  • Battery events
  • LED feedback patterns

Battery thresholds

Level Mode Behavior
Normal Full operation All paths active
<5% SOS Reservation Mode Audio reminders suppressed, SOS path preserved, low-battery haptic warning

Why Reservation Mode matters

The wearable can reach end-of-day with low battery and still successfully alert if the user falls or presses SOS. Audio nudges are sacrificed first because they're recoverable (the user can take the dose late), but the safety path stays alive. This is a strong product story for caregiver confidence.

Cross-references — what this implies for other artifacts

Feature-Dream brief (Wearable_App_Feature_Dream_2026-04-26.md)

Feature Current state Update needed
Tier 1 #4 "SOS + Iridium satellite" Says Iridium Change to NTN (3GPP Non-Terrestrial Network)
Tier 3 #50 "Iridium-only mode" Frames Iridium as future feature Reframe — current path is LTE-M + NTN fallback; "Iridium-only mode" not in roadmap
New must-have Not present Add: SOS guard window UX (3 s post-press, 30 s post-fall) — user-cancellation grace period
New must-have Not present Add: Battery <5% Reservation Mode — SOS preserved when audio suppressed
Tier 1 #2 "Dose-confirmation button" Single-action description Expand to three-gesture grammar — short=confirm, double=snooze, long=SOS escape
Tier 2 / Mark II Generic fall detection Add: BLE event-code map for caregiver-app integration
Tier 1 / Mark II Implicit Add: 30 s post-fall guard with no auto-SOS — keeps us in wellness lane

Patrice + Matilda deck (Research_Synthesis_Deck_2026-04-26.pptx)

Slide Issue Fix
Slide 11 (Mark I MVP) Lists "SOS + Iridium satellite" Change to "SOS + NTN satellite" (or just "SOS + cellular/satellite fallback")
Slide 13 (two-surface) Algorithm-level — no firmware detail Optional: add a sentence noting the v0.2 firmware does not auto-trigger SOS from fall — keeps wellness positioning

Mark II algorithm spec (MarkII_Fall_Detection_Algorithm_v1.md)

  • Update with hardware-confirmed IMU model: LSM6DSV320 at 320 Hz
  • Add candidate-detection threshold: <312 mg sustained ~5 samples
  • Add observation-window detail: 1 s gyro stillness track

Wellness Lexicon (Rx360_Wellness_Lexicon_and_Claims_Audit_v1.md)

  • Confirm the new event-name vocabulary (EVENT_FALL_DETECTED, EVENT_FALL_RECOVERED, etc.) is internal-only and does not surface in consumer copy
  • Confirm "v0.2: no auto-SOS from fall" is preserved in customer-facing claims as "helps detect a fall and alerts your circle" (no "calls help on its own")

Open questions for engineering / product

  1. NTN provider. Which NTN partner? 3GPP NTN is multi-vendor (AST SpaceMobile, Lynk, Iridium GO via NTN-compatible gateways, etc.). Affects coverage claims and pricing.
  2. GNSS time-to-first-fix variance. Spec says target ≤2 s, real up to 45 s. Field testing should validate distribution. SOS-pipeline-time UX claim depends on this.
  3. Cap-touch on/off behavior during medication nudge. If the user takes the band off mid-nudge, should the band auto-snooze or alert the phone via BLE?
  4. Reservation Mode threshold tuning. Is 5 % the right cutoff? Field-test with real-world battery decay curves.
  5. BLE event 0x05 (FALL_CANDIDATE) silent treatment. Is silent the right default, or should the caregiver app still surface a faint indicator? Could be valuable for analytics ("Mom had 3 candidates this week that resolved as recovered — worth checking in").
  6. Auto-SOS from fall in v0.3+. v0.2 explicitly omits auto-SOS. v0.3 roadmap question: does opt-in auto-SOS get added, and if so, does that change our regulatory posture?
  7. Three-attempt SOS retry budget. 30/60/120/240 s — does field testing validate this, or does battery/connectivity data argue for different intervals?

What the diagram does NOT show (but matters for the full product story)

  • Pharmacist-verification gate (Hard Rule #4). Lives upstream in the companion app — the band only fires nudges scheduled by a pharmacist-verified medication entry. Critical to the structural moat; not in this state machine because the band is downstream of that decision.
  • Caregiver-app surface. The BLE notifies feed an app that runs on the caregiver's phone, not the wearer's. The caregiver-first UX pattern from field research lives there.
  • Subscription / billing model. Out of firmware scope.
  • Form factor / physical design. Hardware-side, not behavior-side.

Versioning

  • v0.1 (earlier): SOS pipeline + medication nudge only. No fall detection. Source: MarkII_Fall_Detection_Algorithm_v1.md scaffold.
  • v0.2 (current — this doc): Adds fall detection candidate→detected→recovered cascade with 30 s SOS guard, no auto-SOS.
  • v0.3 (planned): TBD — likely adds auto-SOS opt-in for fall + post-fall vital-signs sampling integration.

File companions

File Purpose
rx360_state_diagram_v0.2.png Source diagram (this folder)
MarkII_Fall_Detection_Algorithm_v1.md Algorithm-side spec scaffold (Gene-authored 4/17)
../Fall_Risk/Research_2026-04-26/Apple_Watch_Fall_API_Deep_Dive.md Apple Watch parallel + 30 s vs 60 s guard-window precedent
../Fall_Risk/Research_2026-04-26/Apple_Lexicon_Wellness_vs_Medical.md Lexicon discipline that "v0.2 no auto-SOS" supports
Wearable_App_Feature_Dream_2026-04-26.md Marketing/strategic feature framing — needs updating per this doc
Research_Synthesis_Deck_2026-04-26.pptx Patrice + Matilda briefing — slide 11 needs update

— End of v0.2 spec —