企业官网建设流程全解析

RuView sensing-server 日志 engine_error_count 持续增长怎么定位原因？

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView

如果你在运行 RuView 的 sensing-server（wifi-densepose-sensing-server），发现状态端点里的engine_error_count一直在涨，甚至同时看到"demoted": true，想知道到底是哪一类融合失败在发生、该改什么配置，可以按下面的路径排查。这套排查依据的是仓库文档 docs/trust-and-engine-errors.md 及其引用的源码（engine_bridge.rs、main.rs、multistatic.rs）。

先记住一个关键区分：engine_error_count和demoted是两套完全独立跟踪的机制。

• 某个 sensing tick 的治理信任周期（governed trust cycle）整体失败（Result::Err(EngineError)），该 tick 不发布任何结果，计数器 +1，这是engine_error_count；
• 周期成功但以更低的隐私等级发布（Result::Ok(TrustedOutput { demoted: true, .. })），只置位demoted标志，不动计数器。

所以可能同时出现高计数 +demoted: false、demoted: true+ 计数为 0、或两者并存，不能把两者混成一件事排查。

第一步：用状态端点确认计数在涨

GET /health/ready与GET /api/v1/status由同一个 handler 服务，返回trust块（文档给出的示例结构）：

{ "status": "ready", "trust": { "last_witness": "…64 hex chars or null…", "effective_class": "Anonymous | Restricted | …", "demoted": false, "recalibration_recommended": false, "engine_error_count": 0, "raw_outputs_suppressed": false } }

快速查看当前信任状态：

curl -s http://localhost:3000/api/v1/status | jq .trust

这里有一个明确的诊断边界：engine_error_count只是一个累计总数，API 和EngineBridge状态里都没有按错误类型的拆分，也没有错误时间线或按节点的拆分。也就是说，从/health/ready你无法判断这 20,000 个错误是TimestampMismatch还是DimensionMismatch；demoted也没有附带到底是哪些contradiction_flags触发。demoted本身不粘滞——每个成功的周期都会重新计算，如果你看到它持续为true，说明触发条件（通常是超过 guard 的时钟漂移，或几何/校准分歧）本身是持续的，而不是某个状态"卡住"了。

第二步：在日志里找唯一带原因的错误行

文档明确说：目前最接近真实诊断手段的就是限频后的日志行。错误日志按 10 秒一条tracing::warn!限频（ENGINE_ERROR_WARN_INTERVAL，engine_bridge.rs），计数每个周期都发生、只是日志行被节流，所以 20 Hz 的循环持续失败也不会刷屏。

在 sensing-server 的 stderr/日志中搜索governed trust cycle failed：

# 在 sensing-server 的输出日志里 grep（日志文件路径按你的部署方式而定） grep "governed trust cycle failed" <sensing-server 日志文件>

日志消息包含EngineError的Display文本，对TimestampMismatch和DimensionMismatch会带具体数值。文档给出的两个示例文本：

• Timestamp spread 87000 us exceeds guard interval 60000 us
• Dimension mismatch: node 2 has 114 subcarriers, expected 56

拿到这行文本，就能把问题归到下面四种错误变体之一（MultistaticError恰好只有这四种）：

据此排查方向是明确的：InsufficientNodes去查在线节点数；TimestampMismatch属于节点间时钟对齐问题（最常见，下面第三步展开）；DimensionMismatch查各节点采集配置。

第三步：持续性的 TimestampMismatch 用 guard 环境变量处理

如果日志里持续出现TimestampMismatch，文档给出的真实修复是环境变量覆盖，而不是重启或等待。硬 guard 默认 60 ms 是为对齐良好的节点设置的；文档引用的部署案例（issue #1049）中，WiFi/ESP-NOW 同步的 ESP32 节点实测漂移 10–150 ms，60 ms 默认值吸收不了，导致每个周期都降级。可用的覆盖项（定义在multistatic_guard_config_from_env，见 main.rs）：

• WDP_GUARD_INTERVAL_US— 直接覆盖硬 guard，例如WDP_GUARD_INTERVAL_US=200000即 200 ms guard；
• WDP_SOFT_GUARD_US— 可选覆盖软（容忍矛盾）guard，始终被钳制在硬 guard 之下；
• WDP_TDM_SLOTS+WDP_TDM_SLOT_US— 从你实际的 TDM 调度推导 guard 而不是直接指定。

优先级规则（WDP_GUARD_INTERVAL_US未设置、为 0 或无法解析时会被忽略并回落到基础配置）：WDP_GUARD_INTERVAL_US对硬 guard总是压过 TDM 推导值；若 TDM 推导的软 band 超过新的硬 guard，则会被钳到hard - 1。

按部署方式带上环境变量启动：

# 例：把硬 guard 提到 200 ms 再启动 sensing-server（其余启动参数照你现有方式） WDP_GUARD_INTERVAL_US=200000 wifi-densepose-sensing-server ...

guard 设多大没有固定答案，文档只说明应"抬到实测离散度之上"（lift the guard past its measured spread）——从日志行的spread_us读数选一个留有余量的值即可。

验证修复与确认计数回落

engine_error_count没有任何重置机制：它是EngineBridge上的普通u64，只在EngineBridge::new初始化为 0，之后只会自增，没有任何方法、管理端点或定时器会减少或清零它。把它归零的唯一方式是重启 sensing-server 进程。所以确认修复是否生效的标准做法是：

1. 应用上面的配置（如 guard 覆盖）后重启 sensing-server；
2. 周期性查询curl -s http://localhost:3000/api/v1/status | jq .trust，看重启后engine_error_count是否还继续爬升、demoted是否回落到false；
3. 同时在日志中确认governed trust cycle failed不再出现。

文档也指出一个容易误判的点：demoted不需要任何重置动作，它每个成功周期重新计算，触发条件消失后下一个干净周期就自动报false。

两个诊断上的诚实边界

• --convert-model与engine_error_count/demoted之间没有代码路径关联：前者只负责把姿态模型权重文件（Hugging Facesafetensors或jsonlmanifest）转成本项目的 RVF 容器格式供--model加载；后者来自多静态 CSI 融合，与加载哪个姿态模型无关。如果你的部署同时遇到两类症状，文档的建议是独立于模型分别排查engine_error_count和日志错误文本——修复在传感器融合侧，不在模型侧。
• 状态端点只告诉你"有错误在发生"和总数，告诉你"为什么"的只有日志行。API 侧目前不按错误类型、不按节点拆分，这是文档明确指出的现状，不要期待/health/ready给出根因。

排查路径总结：/api/v1/status确认计数增长 → grep 日志governed trust cycle failed拿到具体错误文本 → 按四种变体归因 → 时钟漂移类用WDP_GUARD_INTERVAL_US等环境变量覆盖 guard → 重启进程验证计数不再增长。相关实现可进一步阅读 engine_bridge.rs 中observe_cycle的计数逻辑与 multistatic.rs 中MultistaticConfig::default()（60 ms / 20 ms）的定义。

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView