Skip to content

Eigenvalue occupancy is compiled out of the shipped server; all counting is one scalar threshold #1940

Description

@proffesor-for-testing

Eigenvalue occupancy is compiled out of the shipped server; all counting is one scalar threshold

Repo: ruvnet/RuView · Severity: High (design) · Measured: 2026-09-15
No fix proposed — this needs a decision, and the Windows build is in flight.

What ships

wifi-densepose-signal/Cargo.toml:

[features]
default = ["eigenvalue"]           # requires BLAS via ndarray-linalg

wifi-densepose-sensing-server/Cargo.toml:60:

# `--no-default-features` at the workspace root can produce a Windows-friendly
# build without vcpkg/openblas (issue #366, #415).
wifi-densepose-signal = { …, default-features = false }

Nothing in the workspace re-enables it. So the compiled estimate_occupancy is the stub:

#[cfg(not(feature = "eigenvalue"))]
pub fn estimate_occupancy(&self, _recent_frames: &[Vec<f64>]) -> Result<usize, FieldModelError> {
    Err(FieldModelError::NotCalibrated)   // ignores its input, always errors
}

Consequence

Every calibrated occupancy result comes from the perturbation-energy fallback. Confirmed:
inference_method was field_model_perturbation_energy_v1 in 100% of frames across every
capture
. The entire live person-detection is:

if perturbation.total_energy > empty_threshold { 1 } else { 0 }

One scalar against one frozen threshold. baseline_eigenvalue_count is computed, stored in
the receipt, published to the app — and never used for any decision.

This is visibly unstable: the same empty room read absent 604/604, then present 613/613
twenty minutes later, unchanged model and node.

Local experiment (bench only, not proposed)

openblas-static fails to build on macOS/ARM (its cblat3.f Fortran test target).
openblas-system with Homebrew OpenBLAS 0.3.33 builds in ~1 min, the real
estimate_occupancy compiles and runs, and the sensing-server suite is unchanged.

So the blocker is the static BLAS build, not the feature. A system-BLAS backend or a
platform-conditional feature would sidestep it.

Decision needed

Windows support is the stated reason the feature is off, and a Tauri Windows desktop just
merged (ruview-mobile#28) with windows-server/ruview-server-manifest.json. So this now
needs a deliberate choice rather than a flag flip:

  1. platform-conditional feature (eigenvalue on macOS/Linux, fallback on Windows), or
  2. a BLAS-free eigenvalue path, or
  3. accept threshold-only counting — and stop publishing baseline_eigenvalue_count,
    which currently implies a capability the build does not have.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions