mirror of
https://github.com/ruvnet/RuView
synced 2026-06-09 10:13:17 +00:00
39d18d1c998473badcdb0bca531fe8bdb1aa63b4
30 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
39d18d1c99 |
research(R6.2.1): 3D antenna placement — ceiling-only gives 0% coverage; mixed-height wins (#724)
Extends R6.2 from 2D ellipse to 3D ellipsoid + 3D target zones (bed at z=0.3-0.6, chair at z=0.5-1.2, standing at z=1.0-1.7 in a 5x5x2.5 m room). Counter-intuitive headline: | Strategy | Coverage | |-------------------------------------------|---------:| | Desk-height (0.8 m walls) | 22.2% | | Wall-mount (1.5 m walls) | 17.4% | | Ceiling-only (2.5 m grid) | 0.0% | <-- FAILS | Mixed walls + ceiling | 25.7% | <-- BEST Ceiling-only fails because both antennas at 2.5 m create a Fresnel ellipsoid sitting AT ceiling height (2.1-2.9 m vertically). Target zones at 0.3-1.7 m are below the envelope by 0.4-2.0 m. The 39 cm transverse radius is symmetric around LOS, so a flat horizontal link at any height misses targets at any OTHER height. This is the 3D version of R6.1's on-LOS-degeneracy finding. A horizontal link at any single height has its envelope concentrated at that height. Why mixed wins: best placement is Tx (5.0, 4.0, 0.8) + Rx (0.0, 4.0, 1.5). The diagonal-in-z link tilts the ellipsoid through multiple elevations. Covers chair AND standing AND bed simultaneously. Vertical link diversity is the 3D insight 2D analysis missed. Installation-guide updates: - Single pair: one low (0.8 m) + one high (1.5 m), opposite walls - 4-anchor: 2x low corners + 2x high opposite corners - 5-anchor knee: mix 0.8 / 1.5 / one ceiling - Bed-only: both LOW - Standing-only: both HIGH - NEVER: both ceiling without a low anchor Coverage numbers are lower than R6.2's 2D 51% because 3D volumetric coverage is inherently lower than 2D area coverage -- honest 3D physics. Composes: - R6.2 (2D) -- incomplete; height matters as much as horizontal - R6.2.2 (N-anchor) -- N=5 knee should distribute across heights - R6.1 (multi-scatterer) -- needs 3D body model for proper composition - R14 V1/V2/V3 -- each vertical needs height-recipe - ADR-029 -- placement is (x, y, z), not (x, y) - R12 PABS -- detects intruders standing/sitting/lying with mixed heights Honest scope: 3-zone discrete approximation, single-pair only, no furniture occlusion, 0.1 m resolution, greedy search. Coordination: ticks/tick-21.md, no PROGRESS.md edit. |
||
|
|
3d3d54d523 |
research(R3.1): physics-informed env prediction at raw-CSI level — NEGATIVE (architecture-error) (#723)
R3's 'next research lever' was: use R6.1 forward operator + room map to predict env_sig without labelled examples in the new room. R6.1 shipped (tick 18); this tick implements the prediction. Result: at raw-CSI level, all three approaches collapse to chance. | Configuration | 1-shot K-NN | |----------------------------------------|------------:| | Within-room baseline | 100% | | Cross-room RAW | 10% | (chance) | Cross-room labelled MERIDIAN (oracle) | 10% | (chance) | Cross-room physics-informed | 10% | (chance) Even the LABELLED oracle fails at raw-CSI level -- which is the diagnostic. The cross-room problem at raw-CSI level is fundamentally harder than at the AETHER embedding level (R3 tick 12) because position-dependent within-room variance dominates per-subject signature when invariantisation hasn't been done. Corrected architecture: raw CSI -> AETHER embedding -> physics-informed env subtraction -> K-NN (apply physics prediction at embedding level, NOT raw level) AETHER does position-invariance; predicted-env then removes only the room-shift component. THIS IS THE LOOP'S THIRD KIND OF NEGATIVE RESULT: 1. Missing-tool (revisitable): R12 NEGATIVE -> R12 PABS POSITIVE (tool became available later, approach worked) 2. Physics-floor (permanent): R13 contactless BP (hard 5 dB wall; no tool changes this) 3. Architecture-error (correctable): R3.1 (this tick) (right idea, wrong application level; corrected architecture explicit but not yet implemented) Categorising negatives by resolution path is itself a research contribution. Surfaces an architecture error BEFORE implementation. A future engineer attempting 'subtract predicted env from raw CSI' would waste weeks; R3.1 documents the failure path. Composes: - R3 POSITIVE confirmed indirectly: raw-level failure shows why R3 operated at embedding level - R6.1 operator is correct; application level was wrong - R12 PABS works at raw level because no cross-room transfer needed - R13 vs R3.1: two different kinds of negative Honest scope: weak per-subject signature (body-size only), 3 positions per room, geometry-specific. Richer biometric input or per-position- clustering might partially rescue raw-level but defeats the no-label spirit. Coordination: ticks/tick-20.md, no PROGRESS.md edit. |
||
|
|
9cd1b8ce2a |
research(R12 PABS): NEGATIVE -> POSITIVE — 1161x detection lift via R6.1 forward model (#722)
R12 (tick 5) was a NEGATIVE result: naive SVD-spectrum cosine distance detected structure changes at 0.69x the natural drift floor (= undetectable). R12 explicitly identified the revision: 'PABS over Fresnel basis'. R6.1 (tick 18) shipped the multi-scatterer Fresnel forward operator. This tick implements PABS on top of it. PABS = ||y_observed - y_predicted||^2 / ||y_observed||^2 Benchmark (5 m link, 2.4 GHz, subject + 4 wall reflectors expected): | Scenario | PABS / drift | SVD (R12) / drift | |--------------------------------|---------------:|------------------:| | Empty room (subject missing) | 7,362x | 65x | | Subject as expected (sanity) | 0x | 0x | | +1 new furniture | 84x | 11x | | +1 unexpected human | 1,161x | 11x | | Subject moved 10 cm | 21,966x | 90x | | Natural drift (5% wall shift) | 1x | 1x | PABS detects unexpected human at 1161x natural drift; R12 SVD detected at 11x. ~100x lift purely from physics-grounded prediction vs naive statistical eigenshift. R12 NEGATIVE -> POSITIVE. The meta-lesson: a research loop that catalogues NEGATIVE results creates a backlog of revisitable work that pays off when later tools become available. R12 -> R12 PABS is the worked example. R13 cannot be similarly revisited -- its 5 dB shortfall is a hard physics floor, not a missing model. The subject-moved-10cm caveat: PABS detects ANY mismatch between expected and observed scene. Real production PABS needs a pose-aware forward model that updates from pose_tracker.rs in real-time. The actual detection signal is PABS-after-pose-update. ~50-100 LOC Rust glue, catalogued as R12.1 follow-up. Composes: - R6.1 unblocked this implementation - R7 gets precise per-link consistency: residual small on all links = no structure; spike on one = local structure OR compromised link; mincut disambiguates - R11 enables maritime container-tamper / hatch-seal apps - R14 gets V0 security feature (intruder detection w/o biometric storage) - ADR-029 needs to reference PABS as structure-detection primitive - R10 PABS-vs-canopy works if forest modelled or learned Honest scope: - Pose-PABS closed loop not yet built - Synthetic data only; real-world drift floor needs measurement - Population-prior body; per-subject would tighten residual - Single time-frame; real pipeline needs temporal averaging Coordination: ticks/tick-19.md, no PROGRESS.md edit. |
||
|
|
bac6962689 |
research(R6.1): multi-scatterer Fresnel — discovers 4.7 dB penalty matching R13's 5-dB shortfall (#721)
Extends R6's point-scatterer to distributed-body model (6 scatterers: head + chest + 2 arms + 2 legs). Combined CSI = coherent sum of per-body-part contributions. Headline finding: 5 m link, 2.4 GHz, subject 25 cm off LOS, breathing at 0.25 Hz with 8 mm chest amplitude: | Configuration | Breathing SNR (best subcarrier) | |----------------------------------------|--------------------------------:| | Single-scatterer ideal (R6) | +23.7 dB | | Multi-scatterer realistic (R6.1) | +19.0 dB | | MULTI-SCATTERER PENALTY | +4.7 dB | This 4.7 dB penalty matches R13's 5-dB-shortfall finding to within 0.3 dB. R13 NEGATIVE concluded that pulse-contour recovery needs +25 dB SNR, only +20 dB is available. R6.1 says the 5-dB gap has a physical origin: static body parts add coherent-sum confusion that doesn't exist in the idealised single-scatterer model. The three threads now form a coherent physics story: - R6 = bound (idealised single-scatterer = +23.7 dB) - R6.1 = floor (realistic 6-scatterer = +19.0 dB) - R13 = failure (contour needs +25 dB, gets +20 dB) Pulse-contour recovery is bounded below by what R6.1 leaves achievable, which is 4.7 dB worse than R6's idealised limit, enough to make R13's contour recovery infeasible. Per-body-part contribution: chest = 27.6% of CSI energy (5x per-limb reflectivity). The chest IS the breathing signal; limbs are confound. Architectural implications: - Chest-centric placement targeting (R6.2.3 motivated) - Mask limbs in vital_signs pipeline (use pose pipeline ADR-079/101) - R14 V3 rescope to rate-only (no contour-shape recovery) - R12 PABS revision unblocked: R6.1 is the explicit A(voxel) operator Surprise finding: on-LOS placement (y=0) is degenerate -- path delta is 2nd-order in offset for on-LOS scatterers, so breathing barely changes path length. Real installations need subject OFF the LOS line. The R6.2 placement search should respect this. Honest scope: - 6 scatterers is 1st-order; 50-100 voxel body would refine - Reflectivity ratios are guesses (RCS measurements would refine) - Static body assumption (limbs do micro-move during breathing) - 2D top-down, no multipath (model general enough to include them) Composes: - R5: subcarrier selection picks reliable, not high-SNR - R6: per-scatterer building block - R6.2.x: chest-centric placement - R7: residual-vs-forward-model = tighter adversarial detection - R12 NEGATIVE: PABS A operator unblocked - R13 NEGATIVE: 5-dB gap has physical origin - R14 V3: needs rescope Coordination: ticks/tick-18.md, no PROGRESS.md edit. |
||
|
|
065521dc9e |
research(R6.2.2): N-anchor multistatic placement saturation — practical knee at N=5 (#720)
Extends R6.2 from single-pair to N-anchor placement search via union of all C(N,2) pairwise Fresnel ellipses. Greedy + K=8 random restarts. Saturation curve on 5x5 m bedroom (3 target zones: bed + chair + desk, 40 wall-candidates, 434 grid points, 2.4 GHz): | N | Pairs | Coverage | Marginal | |---|------:|---------:|---------:| | 2 | 1 | 35.7% | +35.7 pp | | 3 | 3 | 63.4% | +27.6 pp | | 4 | 6 | 86.2% | +22.8 pp | | 5 | 10 | 96.8% | +10.6 pp | <- knee | 6 | 15 | 100.0% | +3.2 pp | | 7 | 21 | 100.0% | +0.0 pp | Practical knee at N=5. Past this, diminishing returns. Three regimes: - Single-feature (presence): 2-3 anchors (36-63%) - Multi-feature (pose+vitals+count): 4-5 anchors (86-97%) - Mission-critical (medical): 6 anchors (100%) - Beyond 6: wasted Cost-optimisation: Cognitum Seed BOM is 9-15 USD. The 4->5 anchor jump buys +10.6 pp coverage; the 5->6 jump buys only +3.2 pp for the same cost. Consumer recommendation: 5 anchors. Commercial / medical: 6. Convenient numerology: N=5 simultaneously satisfies three other constraints: 1. R7 multi-link mincut: needs N >= 4 for single-anchor-compromise detection 2. ADR-105 federation Krum: f=1 byzantine tolerance requires K >= 5 3. R6.2.2 coverage knee: 5 hits practical saturation These all bound by similar inverse-square-of-geometry scaling, so the alignment is not coincidental. ADR-029 (multistatic) didn't specify anchor counts; R6.2.2 fills that gap with a benchmark-backed number. Honest scope: single 5x5m geometry tested, 2D still (R6.2.1 = 3D not yet built), free-space (multipath adds +5-15% beyond Fresnel), greedy with 8 restarts approximates global optimum to 1-2 pp. Composes with: - R6/R6.2 (direct generalisation) - R7 (mincut needs N>=4) - R1 (placement x precision = full geometry budget) - ADR-029 (architectural recommendation now has a number) - ADR-105 (Krum bound matches) - R10, R11, R14 (other geometries / use cases) Coordination: ticks/tick-17.md, no PROGRESS.md edit. |
||
|
|
719875ea1d |
research(R6.2): Fresnel-aware antenna placement — 93x sensing-coverage lift from physics alone (#719)
First deferred follow-up from R6. Productises R6's Fresnel forward model into a 2D placement-search CLI: given a room + target occupancy zones, recommend Tx/Rx positions that maximise first-Fresnel coverage. Benchmark on 5x5 m bedroom (bed 3 m^2 + chair 0.64 m^2, 2900 pairs evaluated at 2.4 GHz): - OPTIMAL: 51.1% coverage (Tx 1.25,0; Rx 4.75,5; diagonal 6.10 m link) - MEDIAN: 0.5% coverage - WORST: 0.0% coverage - 93x improvement, median to optimal Counter-intuitive insight: longer links cover MORE space. Fresnel envelope width = sqrt(d * lambda) / 2 grows with link length, so the 6.10 m diagonal beats wall-parallel 5.00 m links. Up to the R10 link-budget gate. Per-cog deployment recommendations: - cog-person-count: diagonal across longest axis - cog-pose: zone inside ~50% midpoint envelope - AETHER re-ID: Tx near doorway, Rx diagonal - cog-maritime-watch: vertical diagonal through cabin - cog-wildlife (future): Tx/Rx opposite trees, threading clearing midline Improvements come from physics, not algorithms - no model retraining needed. Existing customers can re-mount seeds today for 10-100x better sensing. Honest scope: 2D approximation, free-space, rectangular zones, single-pair only, perimeter-only candidates, no link-budget gate. CLI shape ready for productisation as 'wifi-densepose plan-antennas'. Also surfaces as a deferred MCP tool 'ruview_placement_recommend'. Composes with: - R6 (direct 2D extension) - R1 (placement x precision = full geometry budget) - R10 (sets the link-budget gate this ignores) - R11 (same recipe in steel cabins) - R14 (determines whether V1/V2/V3 see the right occupant) - ADR-105 (better placement = faster epsilon convergence) Next R6.2 follow-ups catalogued: R6.2.1 (3D), R6.2.2 (N-anchor union), R6.2.3 (pose-trajectory target zones). Coordination: ticks/tick-16.md, no PROGRESS.md edit. |
||
|
|
db64b4c671 |
research(R3): cross-room re-ID — MERIDIAN closes the env-shift gap + 4 privacy constraints (#715)
Synthesis of AETHER (ADR-024) + MERIDIAN (ADR-027) + privacy framing + identified next research lever (physics-informed env prediction). Simulation results (10 subjects, 3 rooms, 128-dim embeddings, env/person scale ratio 4.7x): | Configuration | 1-shot acc | |------------------------------------------|-----------:| | Within-room (matches AETHER ~95% target) | 100% | | Cross-room, raw cosine K-NN | 70% | | Cross-room, MERIDIAN 100% env removal | 100% | | Cross-room, MERIDIAN 70% env removal | 100% | | Chance | 10% | The 30 pp gap from within-room to raw cross-room is the angular contribution of env-shift that cosine similarity can't normalise away. MERIDIAN per-room centroid subtraction recovers it -- robust even at 70% effectiveness (realistic for limited labelled examples). Privacy framing: R14 baseline + 4 new constraints specific to biometric-class re-ID data: 1. No cross-installation linkage 2. Embedding storage requires explicit opt-in (biometric consent class) 3. Cryptographically verifiable forgetting 4. No re-ID across legal entities These rule out cross-building tracking, mass surveillance, long-term unlabelled storage, third-party sharing. They allow per-installation personalisation, household anomaly detection, multi-person pose association in the same room. R3 closes the loop on R14's empathic-appliance vision: re-ID is THE primitive that makes per-occupant features possible. Without R3, R14's verticals can't ship. Identifies next research lever: physics-informed env_sig prediction from R6's forward operator + room map = zero-shot cross-room transfer without labelled examples in the new room. Composes: - R5/R6: person+env decomposition in embedding space - R7: mincut = defence against re-ID spoofing - R9: RSSI K-NN showed env-locality dominance for the K-NN primitive - R14: 4 new constraints extend R14's framework to biometric class Honest scope: additive decomposition is first-order; real CSI env effects are multiplicative in subcarrier domain. Adversarial scenarios not simulated. Coordination: ticks/tick-12.md, no PROGRESS.md edit. |
||
|
|
bcfdf0a4d0 |
research(R13): NEGATIVE — contactless BP from CSI is physically inferior to a cuff (#713)
Critical-physics scrutiny of published 'contactless BP from WiFi CSI' claims (Yang 2022, Liu 2021, others). Four physics floors quantified; all four make CSI-based BP provably worse than a 20 dollar arm cuff. 1. PTT temporal resolution: need 0.5 ms for 1 mmHg precision; ESP32-S3 maxes at 1 ms (1000 Hz CSI) and typical deployment is 10 ms (100 Hz) = 20 mmHg precision floor. Achievable but requires sacrificing every other sensing pipeline. 2. Spatial separation: carotid-femoral distance 55 cm, Fresnel envelope at 5 m link is 40 cm. Single-link CSI cannot resolve the two sites independently. Multistatic with 4-6 anchors is severely ill-posed (same regime that defeated R12). 3. Pulse-contour SNR: pulse motion at chest is 0.3 mm; breathing is 8 mm (27x larger). After 4th-order bandpass we get +20 dB HR-band SNR; literature (Mukkamala 2015) says +25 dB minimum for waveform- shape recovery. **5 dB short.** 4. Vs 0 arm cuff: best published CSI BP is +/-10 mmHg with per-subject calibration; arm cuff is +/-2 mmHg uncalibrated. CSI is 5x worse AND requires calibration the user doesn't otherwise need. Verdict: do not ship BP as a primary RuView feature. The breathing/HR features we already ship work because their motion amplitudes are 30-100x larger than the pulse waveform. Adding BP would force 1 kHz CSI rate (degrading every other pipeline), require per-subject calibration (defeating no-setup story), and ship a feature that's worse than a 20 dollar device the user can buy. Three niche scenarios remain open: - Single-subject trend monitoring (relative not absolute) - Bed-instrumented controlled-still subject (25+ dB achievable) - Multistatic PWV with 6+ anchors + per-installation calibration The general 'BP from a 9 dollar ESP32 in the corner' claim does not close. Composes: - R1 (CRLB) confirms temporal-resolution floor for PTT - R6 (Fresnel) provides the spatial floor that defeats two-site PTT - R5 (saliency) explains why whole-chest observable but 0.3 mm pulse not - R12 = loop's other negative result, same failure pattern - R14's assumption (no BP) is now empirically validated Two negative results in this loop (R12, R13) prevent the field from biasing toward overclaiming. This is the most valuable kind of tick because it marks BP-from-CSI as off-roadmap with explicit numbers, so future contributors don't waste cycles attempting it. Coordination: ticks/tick-11.md, no PROGRESS.md edit. |
||
|
|
4072455d1e |
research(R11): maritime sensing — through-bulkhead impossible, through-seam works (#712)
Physics scrutiny of WiFi-band maritime sensing scenarios. Steel skin depth is 3.25 um at 2.4 GHz, making bulkheads utterly opaque. Saltwater attenuation is 853 dB/m. The 'through-bulkhead WiFi radar' framing common in conservation/maritime is wrong; the actual feasible category is 'through-seam' sensing exploiting slot diffraction through gaskets, hatch seals, and vent grilles. Composite link budget for 7 maritime scenarios (ESP32-S3 121 dB budget, 10 dB SNR margin): FEASIBLE: - Man-overboard surface @ 200 m: +25 dB - Cabin door, 2 mm seam: +31 dB - Cabin door, 5 mm seam: +39 dB - Container, 30 mm vent slot: +45 dB IMPOSSIBLE: - Closed 10 mm steel door: -938 dB - Submarine pressure hull: -929 dB - Head 30 cm underwater: -231 dB Five feasible verticals catalogued: man-overboard surface, through-seam crew vitals, container tamper detection, hatch-seal predictive maintenance, engine-room thermal anomaly via condensation. Composes with prior threads: - R6 Fresnel envelope + slot diffraction = narrower composite envelope - R10 link-budget primitives reused unmodified for air-side maritime - R7 multi-link consistency essential against superstructure jammers - R14 privacy framework transfers directly to crew-cabin monitoring Honest scope: best-case ignores vessel vibration (5-30 Hz, in-band with R10 gait frequencies), engine ignition noise, salt-spray, steel-surface multipath. Maritime gait-classification is harder than land. The romantic 'through-hull radar' is now explicitly debunked. The actual product roadmap is gasket-leakage sensing, surface detection, and predictive-maintenance audits. Coordination: ticks/tick-10.md, no PROGRESS.md edit. |
||
|
|
a1bbe2e8a6 |
research(R1): ToA CRLB — precision floor for WiFi multistatic localisation (#711)
Quantitative Cramer-Rao Lower Bound analysis for WiFi ranging via both Time-of-Arrival and phase-based methods, with multistatic 4-anchor position-error budget. Headline (20 MHz HT20, 20 dB SNR, 100 averaged frames): - ToA range CRLB: 4.1 cm - Phase (5 deg noise): 0.17 mm - Phase advantage: 240x (after ambiguity resolution) 4-anchor convex-hull room (GDOP 1.5): - ToA position precision: 25 cm (room-pose-quality floor) - Phase position precision: 1 mm (RTK-quality, ambiguity-resolved) This is the strongest architectural lever this loop has surfaced for ADR-029 (multistatic sensing). The current learning-based attention approach has no provable precision floor; an explicit ToA-then-phase pipeline sits within 2x of CRLB by Kay's theory. Composes cleanly with R6: - R6 gives the spatial sensitivity envelope (40 cm Fresnel at 2.4 GHz) - R1 gives the ranging precision within it (1 mm phase, 4 cm ToA averaged) - Independent, additive, together bound full multistatic geometry budget Closes a gap R10 created: foliage drops SNR, which directly worsens ToA CRLB. A 50 m foliage link at 5 dB SNR drops to ~1 m ToA precision. R10's 100 m sparse-foliage range is *detectable* not *localisable*. Honest scope: - CRLB is a lower bound; real estimators sit 1-2x above it - 5 deg phase noise assumes phase_align.rs is applied - Multipath degrades CRLB by 2-5x even with MUSIC super-resolution - Integer-ambiguity (cycle-slip) is unsolved per-subcarrier; needs multi-subcarrier wide-lane unwrap Coordination: ticks/tick-9.md, no PROGRESS.md edit. |
||
|
|
650612e5a2 |
research(R6): Fresnel-zone forward model — bedrock physics for CSI sensitivity (#710)
The workspace DSP (vital_signs, multistatic, pose_tracker, tomography) implicitly assumes a forward model that maps scatterer geometry to per-subcarrier phase shifts. Nobody had written it down. This tick makes it explicit. Closed-form first-Fresnel-zone radius + point-scatterer path-delta + per-subcarrier phase prediction over 802.11n/ac 20 MHz channels (52 subcarriers, 312.5 kHz spacing). Pure NumPy demo + JSON output for downstream consumers. Headline numbers: - 5 m link first-Fresnel radius @ midpoint: 40 cm (2.4 GHz), 27 cm (5 GHz) - Inside zone-1: phase spread <0.5 deg across 52 subcarriers (band-flat) - Outside zone-1: phase spread up to 16 deg (band-dispersed) This unifies R5 + R6: R5's experimentally measured band-spread top subcarriers is exactly what the Fresnel forward model predicts for zone-1 occupancy. Closes the loop on three earlier threads: - R7 (mincut adversarial) gets a precise definition of 'physically inconsistent' instead of a learned classifier - R10 (foliage range) needs to retract 100 m sparse estimate to ~70 m to account for Fresnel-zone obstruction - R12 (eigenshift negative result) gets its revision basis: PABS over Fresnel-grounded forward operator Honest scope: point-scatterer only, first Fresnel only, frequency-flat reflectivity, LOS-only (no multipath). The scalar version is the right first-order approximation; volume-integral / multi-zone / multipath extensions catalogued as R6.1+R6.2 follow-ups. Coordination: ticks/tick-8.md, no PROGRESS.md edit. |
||
|
|
2e742305ba |
research(R10): through-foliage wildlife sensing — physics feasibility + per-species gait taxonomy
ITU-R P.833-9 vegetation-attenuation model + ESP32-S3 link-budget solver produce bounded sensing range estimates per frequency and foliage density. Plus a biomechanics-grounded gait-frequency taxonomy spanning bears (0.5 Hz) to mice (15 Hz). Headline ranges (121 dB link budget, 10 dB SNR margin): freq sparse moderate dense 2.4 GHz 99.6 m 12.0 m 4.1 m 5 GHz 19.9 m 5.2 m 2.1 m The 2.4 GHz / sparse cell (~100 m) is the practical sweet spot — 10x camera-trap coverage, always-on rather than PIR-triggered. Honest scope called out explicitly: this is feasibility math, not field measurements. Animal cooperation, foliage flutter, regulatory limits, and BSSID-fingerprint degradation in remote forest are all real follow-up problems. Vertical applications (10-20 year horizon) catalogued: - Endangered-species population census - Wildlife corridor verification - Invasive-species early warning - Anti-poaching (human gait well-separated from wildlife) - Livestock-on-rangeland tracking - Agricultural pest control Cross-connects to: - R5 (saliency is task-specific — per-species classifier needs own saliency map, same lesson as R12) - R8 (wildlife sensing wants CSI not RSSI for per-subcarrier shape) - R9 (fingerprint K-NN primitive transfers to per-individual ID) - R7 (multi-link consistency for corridor coverage) Pure-NumPy, no framework deps. ITU model + binary search solver. Coordination: tick avoided PROGRESS.md to prevent races (horizon- tracker M3+ track concurrent at the time). Files: * examples/research-sota/r10_foliage_attenuation.py * examples/research-sota/r10_foliage_results.json * docs/research/sota-2026-05-22/R10-through-foliage-wildlife.md * docs/research/sota-2026-05-22/ticks/tick-6.md |
||
|
|
6b35896847 |
research(R12): RF weather mapping eigenshift — negative-ish, with clearly-actionable revision path (#707)
Tests the simplest possible algorithm for RF-weather change detection: SVD on per-frame CSI matrix, top-10 singular values, cosine distance between spectra over time. Hypothesis: a synthetic structural perturbation (15 percent attenuation on 3 top-saliency subcarriers) should produce a larger spectral shift than natural temporal drift from operator movement in the same recording. Result honestly: it does not. The perturbation distance (0.00024) is *smaller* than the control distance (0.00035) — signal/drift ratio 0.69x. The top-K SVD-spectrum cosine is too coarse to detect small-magnitude subcarrier-specific structural changes against an operator-noise background. Three concrete fixes identified for follow-up ticks: 1. Principal angles between subspaces (PABS), not cosine on singular values — catches subspace rotations the spectrum misses 2. Per-subcarrier residual analysis after projecting onto baseline subspace — localises the perturbation 3. Multi-day baseline — knocks down operator-noise floor by 50-100x Useful cross-validations the negative result produces: * R5 task-specific saliency (count-task) does not generalise to structure-detection saliency. Same data, different relevant features. Publishable distinction. * R12 is CSI-only territory — RSSI is the trace of the CSI covariance, so if top-10 SVD-spectrum can't see this, RSSI can't either. Bounds R8 commercial-enablement story to counting only. * R7 SVD-spectrum primitive that worked for adversarial detection fails here at lower perturbation magnitude. Sensitivity does NOT scale with subtlety — confirms the algorithm is magnitude-dominated. Long-horizon vision (building structural monitoring, earthquake drift, HVAC audits, climate-controlled-archive surveillance) preserved in the research note — the physics is right, the hardware is sufficient, the deployment story works. Just need PABS + multi-day data. Coordination note: this tick avoided PROGRESS.md edits entirely because horizon-tracker is concurrently editing it. Tick-5 summary written to ticks/tick-5.md (new self-contained convention) so the 08:00 ET final summary can consolidate without conflicts. Files: * examples/research-sota/r12_rf_weather_eigenshift.py * examples/research-sota/r12_rf_weather_results.json * docs/research/sota-2026-05-22/R12-rf-weather-mapping.md * docs/research/sota-2026-05-22/ticks/tick-5.md |
||
|
|
2783f40bd1 |
feat(tools/ruview-mcp): M2 — wire real inference via cog health (#706)
* research(R9): RSSI fingerprint K-NN — 2.18x lift (MODERATE); surfaces counting-vs-localization asymmetry Hypothesis: if temporal proximity correlates with RSSI-feature proximity in the existing single-session data, RSSI fingerprinting is viable. If K-NN of each query is random in time, RSSI sequences are too noisy for fingerprint localization. Test: 1077 samples, 20-dim RSSI proxy (band-mean across 56 subcarriers), cosine-NN with K=5, measure fraction of K-NN within plus/minus 60s of each query timestamp. Compare to random baseline. Result (honest): 5-NN within +/-60s 0.169 Random baseline 0.077 Lift over random 2.18x (verdict: MODERATE) Per-query stdev 0.183 Below the >=3x STRONG-fingerprint threshold but well above 1x random. Real signal, but weaker than R8 counting result on the same data. Important asymmetry surfaced (publishable distinction): Task RSSI vs CSI retention Verdict ------- ----- ----- Counting 94.82% (R8) RSSI works well Localization ~2x random (R9) RSSI struggles in this regime This is consistent with R5's band-spread observation: the count signal integrates across the band, but localization may require per-subcarrier shape that the band-mean discards. Three actionable explanations for the MODERATE result: 1. 20-frame windows (~2s) too short for stable fingerprint while operator moves — longer windows might lift to 3-4x. 2. Within-room fingerprint space too narrow — multi-room data would show categorical lift jump (5-10x). 3. Band-mean discards the per-subcarrier shape needed for localization. Once multi-room data lands (#645), this test should be re-run; if hypothesis (2) is right, the lift will jump categorically. Files: * examples/research-sota/r9_rssi_fingerprint_knn.py * examples/research-sota/r9_rssi_fingerprint_results.json * docs/research/sota-2026-05-22/R9-rssi-fingerprint-knn.md * docs/research/sota-2026-05-22/PROGRESS.md updated * feat(tools/ruview-mcp): M2 — wire real inference via cog health subcommand ruview_pose_infer and ruview_count_infer now run the cog binary's `health` subcommand (ADR-100 contract) which performs real Candle forward-pass inference on a synthetic CSI window and emits a structured health.ok JSON event containing backend, confidence (pose) or count/confidence/p95_range (count). The MCP tools parse this event and return typed inference results. This satisfies the ADR-104 acceptance gate: "ruview_pose_infer returns a finite output for a synthetic CSI window" when the cog binary is installed. On machines without the binary, both tools still fail-open with {ok:false, warn:true} and actionable install hints. Also updates PROGRESS.md with cross-links: R7 (Stoer-Wagner) and R8 (RSSI-only 94.82% retained) marked done with cron-originated findings distilled into the research vectors section. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
bb92419ccb |
research(R7): Stoer-Wagner mincut detects adversarial CSI nodes 3/3 in synthetic (#704)
Premise: in a multi-node CSI mesh, all nodes see the same physical
scene through slightly different multipath. Their per-window CSI
vectors cluster tightly under cosine similarity. An adversarial node
(replay / shift / noise injection) sits *outside* that cluster. The
Stoer-Wagner minimum cut on the inter-node similarity graph isolates
it cleanly when the cut is sharp.
Demo synthesises 4 honest nodes (one real CSI window from the paired
data + per-node Gaussian noise 6 dB below signal) and 1 adversarial
node under three attack modes. Cosine-similarity matrix, then
Stoer-Wagner mincut, then check whether partition_B is the singleton
{4} — the adversarial node.
Attack Mincut value Partition_B Isolated?
------- ------------ ----------- ---------
replay 3.4513 {4} YES
shift 3.5724 {4} YES
noise 2.5586 {4} YES
Detection rate: 3/3 = 100%.
Architectural payoff: this is the primitive that fills the stub at
. ADR-103 v0.2.0
can wire it in directly. The mincut value also becomes a continuous
'mesh trustworthiness' metric for the cog-gateway dashboard.
Honest scope: the demo uses sloppy attackers. Adaptive attackers who
have read this note can almost certainly evade by adding calibrated
noise that keeps cosine similarity above the cluster floor. The next
research step is the Stackelberg-game extension. See the
'Honest scope of this result' section in the research note.
Connections:
* R5 — top-8 saliency subcarriers are the priority list for a
more-targeted per-subcarrier consistency check.
* R8 — same primitive likely works at lower SNR with RSSI-only
metrics; cluster structure is preserved by the band integral.
Files:
* examples/research-sota/r7_multilink_consistency.py — pure-NumPy
Stoer-Wagner mincut + synthetic-adversary harness.
* examples/research-sota/r7_multilink_consistency_results.json —
full result JSON for cross-tick reproducibility.
* docs/research/sota-2026-05-22/R7-multilink-consistency.md — note.
* docs/research/sota-2026-05-22/PROGRESS.md — updated index + Done.
|
||
|
|
d9ca9b3684 |
research(R8): RSSI-only person count retains 95% of full-CSI accuracy (#703)
Builds directly on R5's band-spread observation. If the count-task
signal is spread across the WiFi band (R5: max/mean ratio 2.85× across
56 subcarriers), then RSSI — which is the integral of |H_k|^2 across
the band — keeps most of the information. The naive prior (RSSI throws
away 98% of CSI bytes) is misleading; the relevant metric is how much
of the *signal* is in the integral, not how many bytes are in the
representation.
Tested by aggregating each existing [56 × 20] CSI window down to a
[20]-vector RSSI proxy (mean across subcarriers per frame), training a
tiny MLP (Linear 20→32→8, 656 params, 5 KB) with vanilla NumPy SGD for
200 epochs on the same random 80/20 split as cog-person-count v0.0.2.
Result:
Full CSI v0.0.2 62.3% accuracy
RSSI-only (this) 59.1% accuracy = 94.82% retained
Per-class is also markedly more *balanced* (RSSI: 59.5 / 58.6 ; full
CSI: 86.2 / 34.3) — the tiny model on a low-dim input can't cheat by
leaning on class 0 the way v0.0.2's larger model does at inference.
What this enables on a 10-year horizon: phones, laptops, smart
speakers, smart TVs, smart lights — anything with WiFi reports RSSI
and anything with a CPU can run a 656-param MLP. Person counting
becomes a federated property of any room with WiFi, not a property of
the ESP32-S3 fleet.
What this doesn't prove (called out explicitly in the research note):
- Single room, single operator, single 30-min recording
- 2-class problem (label distribution is {0, 1})
- Single random draw — needs K-fold + multi-room replication
Three follow-up experiments queued in R8-rssi-only-count.md §'What's
next on this thread':
- Multi-room replication once #645 lands
- 3-class extension (0 / 1 / 2+) — measure the info-rate cliff
- Run on a non-ESP32 RSSI source (e.g. iw event on Linux laptop)
Files:
* examples/research-sota/r8_rssi_only_count.py — pure-NumPy, no
framework deps. Trains + evals in 0.72 s on CPU.
* examples/research-sota/r8_rssi_only_results.json — full JSON dump
for cross-tick reproducibility.
* docs/research/sota-2026-05-22/R8-rssi-only-count.md — method,
measured numbers, interpretation, what doesn't work yet.
* docs/research/sota-2026-05-22/PROGRESS.md — updated index + Done
log.
Coordination note: horizon-tracker is working on tools/ruview-mcp/
+ tools/ruview-cli/ + ADR-104 — this commit deliberately stays out
of those paths.
|
||
|
|
a85d4e31e4 |
research(sota): kick off SOTA research loop + first R5 saliency measurement (#702)
Sets up docs/research/sota-2026-05-22/ as the autonomous-research output dir, with PROGRESS.md as the canonical 15-vector research agenda spanning spatial intelligence, RF features, RSSI-only, and exotic/long-horizon verticals. Cron d6e5c473 (*/10 * * * *) picks threads from this file and self-terminates at 2026-05-22 08:00 ET. First concrete contribution this tick — R5 subcarrier saliency: * examples/research-sota/r5_subcarrier_saliency.py: pure-numpy port of the count cog's Conv1d encoder + count head, computes per- subcarrier input×gradient saliency via central-difference. 128 samples × 56 subcarriers × 2 forward passes/subcarrier ≈ ~3 s on CPU, no GPU or framework dependency. * docs/research/sota-2026-05-22/R5-subcarrier-saliency.md: research note with motivation, method, novelty argument, and the first measured ranking. Top-8 subcarriers for cog-person-count v0.0.2: [41, 52, 30, 31, 10, 35, 2, 38]. Max/mean ratio 2.85x. * v2/crates/cog-person-count/cog/artifacts/saliency.json: machine- readable per-subcarrier saliency + top-K lists, so future-tick experiments (retrain at K=8/16/32) consume it without re-running. Key insight from the first measurement: top-8 saliency is *band- spread* (indices span 2-52), not concentrated. This directly raises R8's (RSSI-only) feasibility ceiling, because RSSI is a band- aggregate — it retains the integral of a band-spread signal. First- order estimate: RSSI-only should hit ~60% of full-CSI accuracy for the count task. R7 (adversarial defence) inherits a concrete defender- priority list: corroborate these 8 subcarriers across nodes. This commit is the first of many short, focused contributions over the next ~12 hours. PROGRESS.md is the canonical pointer for the next tick to pick up the next thread. |
||
|
|
6a2b2bdcbf |
fix(three.js): graceful banner when X Bot.fbx 404s on gh-pages (#651)
Demos 04 and 05 work fine locally — operator has assets/X Bot.fbx
present. On the gh-pages deploy the FBX is intentionally absent
(Mixamo license boundary, .gitignored) and the previous onError
handler just logged 'FBX load failed' to the console and left a
stuck '⚠ Load failed — see console' message in the overlay.
Replaces both onError handlers with an in-page card that:
- Explains why the asset is missing (license boundary, not a bug)
- Tells you exactly how to run it locally (Mixamo download path,
where to drop the file, the serve-demo.py command)
- Links to Mixamo + the repo source + back to the gallery
- Lets the ADR-097 helpers scene keep rendering behind it
- Logs at warn (not error) — no more uncaught console.error noise
The success branch is untouched, so local development is identical
to before.
|
||
|
|
d67d9872c1 |
feat(pages): deploy three.js demos to gh-pages/three.js/ (#649)
Adds a new GitHub Pages workflow that publishes the ADR-097 three.js demo gallery alongside the existing observatory/, pose-fusion/, pointcloud/, and nvsim/ deployments. Uses keep_files: true so the other deployments are preserved. What ships: * `examples/three.js/index.html` — new landing page that lists all 5 demos with screenshots, "standalone" vs "needs FBX" badges, and an honest note explaining the Mixamo X Bot.fbx license boundary (demos 04 and 05 need a local download from mixamo.com; demos 01-03 run standalone in any modern browser). * `.github/workflows/threejs-pages.yml` — staged copy of demos/, screenshots/, README.md, and the new index.html into `_site/three.js/`. Drops an `assets/README.txt` placeholder explaining the FBX-not-shipped policy. Triggered on changes to examples/three.js/** or the workflow itself. * README.md — adds the live link to the existing demo row (`▶ three.js Demos (5)`) plus a one-line callout describing the gallery and the FBX caveat. After this PR merges, the workflow runs and publishes: https://ruvnet.github.io/RuView/three.js/ |
||
|
|
27a6edba8b |
feat(examples/three.js): cinematic skinned realtime pose demo + folder reorg (#584)
* feat(examples/three.js): cinematic skinned realtime pose demo + ESP32 CSI bridge
Five-stage example progression exploring three.js helpers (ADR-097 surface) as
a viewer for live RuView sensor data:
1. helpers-demo.html — clean ADR-097 helper reference (GridHelper,
PolarGridHelper, BoxHelper, AxesHelper),
file://-safe, no backend
2. helpers-cinematic.html — same scene + UnrealBloomPass + pseudo-CSI
sonar pings + tomography sweep + procedural
cyber floor + ambient drift particles
3. helpers-skinned.html — replaces sphere skeleton with Mixamo X Bot
via GLTFLoader from threejs.org CDN, plays
bundled animations with additive blending
4. helpers-skinned-fbx.html — same but loads a local Mixamo FBX (needs
serve-demo.py — file:// can't fetch local
siblings). Drop X Bot.fbx alongside.
5. helpers-skinned-realtime.html — webcam → MediaPipe Pose Heavy →
poseWorldLandmarks → direct quaternion
retargeting onto the Mixamo skeleton.
Real ESP32-S3 CSI streamed over WebSocket
from ruvultra (Tailscale, port 8766).
Supporting:
- serve-demo.py threaded HTTP server with no-cache headers
(fixes net::ERR_EMPTY_RESPONSE on the FBX path)
- ruvultra-csi-bridge.py ESP32 RuView firmware tick → WebSocket bridge,
runs as systemd-run unit on ruvultra
Bugs found + fixed along the way (all documented in code comments):
- FBX exports yield TWO parallel Bone trees with identical names; only the
SkinnedMesh.skeleton.bones one drives visible deformation. model.traverse
finds orphans.
- Mixamo FBX nests a zero-length wrapper bone above the real bone, same name.
bone.children[0].getWorldPosition == bone.getWorldPosition → restDir is
(0,0,0) → setFromUnitVectors collapses to identity. Walk past same-named
same-position wrappers when computing tail.
- AnimationMixer.update() with a "stopped" action still mutates bones unless
enabled=false is set.
Retargeting layer in helpers-skinned-realtime.html:
- 12 bones direct quaternion retarget (arms × 2, legs × 2, spine × 3, neck)
- Hips root rotation from shoulder/hip line basis (torso twist + lean)
- Neck aims at ear-midpoint (kp 7+8), not nose (kp 0), to remove the
forward bias of the protruding-nose anchor
- One Euro Filter per landmark per axis (Casiez 2012) — adaptive low-pass
- Visibility-weighted per-bone slerp gain — occluded limbs relax to rest
- URL toggles: ?mirror= ?yflip= ?zflip= ?cnn=0/1/2 ?csi=ws://...
Live CSI integration:
- Bridge parses adaptive_ctrl tick lines (motion/presence/rssi/yield)
- Browser fans single ESP32 reading across 4 UI nodes with phase-shifted
wobble (0.88–1.00 × sin(t·0.55 + offsetᵢ))
- EMA α=0.06 (~3 sec time constant), HUD update throttled 3 Hz
Co-Authored-By: claude-flow <ruv@ruv.net>
* refactor(examples/three.js): organize into demos/screenshots/server/assets + add README
Flatten the 13-file flat layout into purposeful subfolders so the demo
collection has a clean top-level entry point (README.md) and the file roles
are obvious from a directory listing.
Layout:
demos/ 01..05 — numbered for the progression (helpers → cinematic →
skinned → skinned-fbx → skinned-realtime)
screenshots/ one PNG per demo, matching the demo's filename prefix
server/ serve-demo.py + ruvultra-csi-bridge.py
assets/ X Bot.fbx (gitignored, used by demos 04 and 05)
Touched files (beyond the renames):
- 04-skinned-fbx.html, 05-skinned-realtime.html: MODEL_URL now resolves
'../assets/X%20Bot.fbx' instead of './X%20Bot.fbx'
- server/serve-demo.py: chdir() walks 3 levels up to repo root (was 2), and
the URL banner now lists all 5 demos
- .gitignore: comment refresh — points at assets/ and screenshots/
- 05-skinned-realtime.html also picks up in-flight fps-tune work from this
branch (Holistic script, SMOOTH_K URL param, slerp gain scaling) since
those edits and the rename hit the same file
Verified end-to-end:
- python examples/three.js/server/serve-demo.py
- all 5 demos return 200, X Bot.fbx returns 200 from new asset/ path
- demos 04 + 05 render the X Bot mesh; 0 JS errors via browser eval
- screenshots reproduced match the originals
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
f49c722764 |
chore(repo): rename rust-port/wifi-densepose-rs → v2/ (flatten to one level) (#427)
The Rust port lived two directories deep (rust-port/wifi-densepose-rs/) without any sibling under rust-port/ that warranted the extra level. Move the whole workspace up to v2/ to match v1/ (Python) at the same depth and shorten every cd / build command across the repo. git mv preserves history for all tracked files. 60 files updated for path references (CI workflows, ADRs, docs, scripts, READMEs, internal .claude-flow state). Two manual fixes for relative-cd paths in CLAUDE.md and ADR-043 that became wrong after the depth change (cd ../.. → cd ..). Validated: - cargo check --workspace --no-default-features → clean (after target/ nuke; the gitignored target/ was carried by the OS rename and had hard-coded old paths in build scripts) - cargo test --workspace --no-default-features → 1,539 passed, 0 failed, 8 ignored (same totals as pre-rename) - ESP32-S3 on COM7 → still streaming live CSI (cb #40300, RSSI -64 dBm) After-merge follow-up: contributors should `rm -rf v2/target` once and let cargo regenerate from the new path. |
||
|
|
a4bd2308b7 |
feat: ADR-069 ESP32 CSI → Cognitum Seed RVF pipeline (v0.5.4-esp32)
Hardware-validated pipeline connecting ESP32-S3 CSI sensing to Cognitum Seed (Pi Zero 2 W) edge intelligence appliance via 8-dim feature vectors. Firmware: - New 48-byte feature vector packet (magic 0xC5110003) at 1 Hz with normalized presence, motion, breathing, heart rate, phase variance, person count, fall detection, and RSSI - Compressed frame magic reassigned 0xC5110003 → 0xC5110005 - Guard against uninitialized s_top_k read when count=0 Bridge (scripts/seed_csi_bridge.py): - UDP→HTTPS ingest with bearer token, hash-based vector IDs - --validate (kNN), --stats, --compact, --allowed-sources modes - NaN/inf rejection, retry logic, SEED_TOKEN env var support Validated on live hardware: - 941 vectors ingested, 100% kNN exact match - Witness chain SHA-256 verified (1,325 entries) - 1,463 Rust tests passed, Python proof VERDICT: PASS Research: 26 docs covering Arena Physica, Maxwell's equations in WiFi sensing, SOTA survey 2025-2026, GOAP implementation plan Security: removed hardcoded credentials, added NVS patterns to .gitignore, source IP filtering, NaN validation Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
4713a30402 |
docs: add README for happiness-vector example
Quick start guide, 8-dim vector schema, multi-node swarm setup, Seed query tool usage, privacy considerations, and file index. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
2b8a7cc458 |
feat: happiness scoring pipeline + ESP32 swarm with Cognitum Seed (#285)
* feat: happiness scoring pipeline with ESP32 swarm + Cognitum Seed coordinator ADR-065: Hotel guest happiness scoring from WiFi CSI physiological proxies. ADR-066: ESP32 swarm with Cognitum Seed as coordinator for multi-zone analytics. Firmware: - swarm_bridge.c/h: FreeRTOS task on Core 0, HTTP client with Bearer auth, registers with Seed, sends heartbeats (30s) and happiness vectors (5s) - nvs_config: seed_url, seed_token, zone_name, swarm intervals - provision.py: --seed-url, --seed-token, --zone CLI args - esp32-hello-world: capability discovery firmware for 4MB ESP32-S3 variant WASM edge modules: - exo_happiness_score.rs: 8-dim happiness vector from gait speed, stride regularity, movement fluidity, breathing calm, posture, dwell time (events 690-694, 11 tests, ESP32-optimized buffers + event decimation) - ghost_hunter.rs standalone binary: 5.7 KB WASM, feature-gated default pipeline RuView Live: - --mode happiness dashboard with bar visualization - --seed flag for Cognitum Seed bridge (urllib, background POST) - HappinessScorer + SeedBridge classes (stdlib only, no deps) Examples: - seed_query.py: CLI tool (status, search, witness, monitor, report) - provision_swarm.sh: batch provisioning for multi-node deployment - happiness_vector_schema.json: 8-dim vector format documentation Verified live: ESP32 on COM5 (4MB flash) registered with Seed at 10.1.10.236, vectors flowing, witness chain growing (epoch 455, chain 1108). Co-Authored-By: claude-flow <ruv@ruv.net> * ci: raise firmware binary size gate to 1100 KB for HTTP client stack The swarm bridge (ADR-066) adds esp_http_client for Seed communication, which pulls in the HTTP/TLS stack (~150 KB). Binary grew from ~978 KB to ~1077 KB. Raise the gate from 950 KB to 1100 KB. Still fits comfortably in both 4MB (1856 KB OTA slot, 43% free) and 8MB flash variants. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
7eba8c7286 |
feat: 10-in-1 medical vitals suite from single mmWave sensor
examples/medical/vitals_suite.py — all 10 capabilities: 1. Heart rate (continuous) 2. Breathing rate (continuous) 3. Blood pressure estimation (HRV-based) 4. HRV stress analysis (SDNN, RMSSD, pNN50) 5. Sleep stage classification (awake/light/deep/REM) 6. Apnea event detection (BR=0 for >10s, AHI scoring) 7. Cough detection (BR spike > 2.5x baseline) 8. Snoring detection (periodic high-amplitude BR) 9. Activity state (resting/active/exercising) 10. Meditation quality scorer (BR regularity + HR + HRV) Uses Welford online stats, zero-crossing analysis, and variability-based state classification. Single $15 sensor. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
a7d417837f |
feat: RuView Live v2 — RuVector signal processing integration
Ported 5 RuVector/RuvSense algorithms from Rust to Python: - WelfordStats (field_model.rs): online mean/variance/z-score - VitalAnomalyDetector (vitals/anomaly.rs): Welford z-score apnea/tachy/brady - LongitudinalTracker (ruvsense/longitudinal.rs): drift detection over time - CoherenceScorer (ruvsense/coherence.rs): signal quality with decay - HRVAnalyzer (vitals/heartrate.rs): SDNN, RMSSD, pNN50, LF/HF spectral Live verified: detected HR anomaly (2.5sd drop) and BR drift (2.2sd rise) from real mmWave + CSI data. Full session baselines tracked for 3 metrics. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
4239dfa35a |
feat: RuView Live unified dashboard + improved examples README
ruview_live.py: single-file dashboard that auto-detects CSI and mmWave sensors, displays fused vitals (HR, BR, BP, stress/HRV), environment (light, RSSI, RF fingerprint), presence, and events. Tested live: CSI 1000 frames/60s (17 Hz), light trending 7.4→6.0 lux, RSSI -57 to -72 dBm. Handles graceful degradation when sensors are unavailable. README: updated with unified dashboard as primary entry point, hardware table with capabilities, expanded quick start. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
24ea88cbe0 |
feat: 4 sensing examples — sleep apnea, stress, room environment
examples/sleep/apnea_screener.py — detects breathing cessation events (>10s), computes AHI score, classifies OSA severity. examples/stress/hrv_stress_monitor.py — real-time SDNN/RMSSD from mmWave HR, stress level with visual bar. examples/environment/room_monitor.py — dual-sensor (CSI + mmWave) room awareness: occupancy, light, RF fingerprint, activity events. examples/README.md — index with hardware table and quick start. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
ef582b4429 |
docs: medical examples README + link from root README
- examples/medical/README.md: full guide for BP estimator, hardware requirements, sample output, accuracy table, AHA categories, disclaimer, RuView integration explanation - README.md: added Medical Examples to documentation table Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
8318f9c677 |
feat: contactless blood pressure estimation via mmWave HRV (examples/medical)
Reads real-time heart rate from MR60BHA2 60 GHz mmWave sensor and estimates BP trends using HR/HRV correlation model: - Mean HR → baseline SBP/DBP - SDNN (HRV) → sympathetic/parasympathetic adjustment - LF/HF spectral ratio → fine adjustment (with numpy) - Optional calibration with a real BP reading Verified on real hardware: 125/83 mmHg estimate from 35 HR samples over 60 seconds at 84 bpm mean HR with 91ms SDNN. NOT A MEDICAL DEVICE — research/wellness tracking only. Co-Authored-By: claude-flow <ruv@ruv.net> |