ESP32-C6 固件性能基准实测解读：ESPectre 四前端 × 双检测器的真实运行表现与通过标准

ESP32-C6 固件性能基准实测解读：ESPectre 四前端 × 双检测器的真实运行表现与通过标准

【免费下载链接】espectreWi-Fi CSI motion sensing for ESP32. C++ SDK, ESPHome, Native, and Matter frontends, browser tools, and a CLI for the full device lifecycle. GPLv3 and commercial licensing.项目地址: https://gitcode.com/GitHub_Trending/es/espectre

本篇技术指南围绕 docs/performance/ESP32-C6.md 这份由tools/benchmark_firmware.py自动生成的固件性能报告展开，系统解读 ESP32-C6 上 Native、ESPHome、Matter 三种 C++ 前端（各含 Lightweight 与 High Accuracy 两种检测器）以及 Micro-ESPectre（Lightweight）共 7 个组合的实测指标，并结合仓库源码说明每项指标的采集原理、判定阈值与复现方法。读完本文，你将掌握如何读懂这类运行期基准报告、如何在自己设备上复现同一套基准，以及报告中的二进制体积、CSI 占用率、堆稳定性、CPU 负载与检测时序等指标分别验证了什么。

报告生成信息速览：由tools/benchmark_firmware.py --chip c6 --port <serial-port>生成，Git 修订ed014256dbf6，运行开始于2026-09-05T03:33:32+02:00，选定监控时长 60 秒，总体结果 PASS，运行期间源指纹稳定（Source consistency: stable）。报告属于自动生成文件（<!-- Generated file. Do not edit manually. -->），内容由基准工具渲染，任何对源码的修改都应在下一轮基准中体现。

报告定位：这是一份"运行期"固件基准，不是仿真

报告头部的 "Benchmark mode: runtime" 表明：全部 7 个用例都是在真实硬件上完成构建（build）→ 烧录（flash）→ 部署/配网 → 运行监控（monitor）→ 通过 Direct v1 接口采样的完整流程。可以从 tools/lib/firmware_benchmark/models.py 的CASES定义看到基准矩阵的固定组成：

其中 Matter 前端只支持这两个 C++ 检测器组合，Micro-ESPectre 仅部署 Lightweight（Micro 是 MicroPython 运行时，只支持轻量检测器），这与报告头部 "Detector coverage" 的说明一致。报告还特别提示：--update或--resume保留的旧用例可能来自更早的运行，精确的用例来源应以每次运行单独生成的 artifacts 为准（见 tools/lib/firmware_benchmark/report.py 的 Snapshot scope 说明）。

需要说明的是：本报告衡量的是固件在真实 Wi-Fi 环境下的运行期行为（包率、CSI 占用率、堆、CPU 负载），而检测器在录制数据上的识别精度（Recall / FP Rate / F1）由另一份报告 docs/performance/README.md 给出，本文最后会横向引用其 ESP32-C6 数据作为补充。

摘要矩阵：7 个用例一目了然

报告第一个核心表格是 Summary 矩阵，聚合了每个用例最重要的 6 项结果指标：

几个值得注意的横向对比点：

• 二进制体积：Matter 前端最大（1.85 MiB），因为它内嵌 Matter 协议栈；ESPHome 前端最小（1.10 MiB）；同一前端的 Lightweight 与 High Accuracy 共用同一份固件镜像（检测器在运行时切换，而非编译期二选一），所以体积完全一致。
• CSI 占用率：Micro-ESPectre 最高（93.85%），ESPHome 次之（92.93%），Matter 最低（84.35%）；全部显著高于 70% 的"detector-ready"门槛（该门槛来源见下文 Pass Criteria 解读）。
• CPU 负载：三个 C++ 前端在 6.7%～9.9% 之间，High Accuracy 普遍比 Lightweight 高出 2～3 个百分点；Micro-ESPectre 达 70.23%，这与它是 MicroPython 解释执行、且为无 RTOS 的循环运行时直接相关。
• 最小空闲堆：Matter 前端约 155.8/153.6 KiB，Micro-ESPectre 约 96.9 KiB，其余前端在 218～221 KiB 量级。

详细指标分组解读：每个数值背后验证了什么

报告对每个用例给出完整指标表（"| Metric | Value |"）。下面以 Native Lightweight 与 Micro-ESPectre Lightweight 两个代表性用例为例，分组解读。完整数值请直接查阅 docs/performance/ESP32-C6.md 正文。

1. 构建与部署阶段（构建/烧录/监控时长、镜像与分区）

Native Lightweight 为例：Build 28.3s、Flash 12.8s、Monitor 2m 36.1s；固件二进制 1,387,600 bytes（1355.1 KiB），应用分区使用 1,387,600 bytes、剩余 578,480 bytes（564.9 KiB）。Matter 前端构建最久（4m 27.4s）且有独立 Deploy 阶段（9.7s）。Micro-ESPectre 特殊之处在于同时上报 Firmware binary（1,531,872 bytes，1496.0 KiB）与Deployed Python source（169,086 bytes，165.1 KiB），因为它是 MicroPython 部署方式——固件里还包含 Python 源码。

分区剩余比例的意义：在 ESP32-C6 上为未来的 OTA 双分区方案留出空间。报告渲染逻辑在 tools/lib/firmware_benchmark/report.py 的format_summary_partition_free中实现，先换算 MiB 再附百分比。

2. 网络与 CSI 采集质量（包率、CSI 占用率、Direct 控制）

这是运行期基准的核心，直接决定 Wi-Fi 感知的上层数据质量：

• Packet rate（已准入 CSI 包率）：Native Lightweight 88.75 pps 均值（72～96，标准差 6.01）；ESPHome 92.77 pps（86～98，标准差仅 2.04，最稳定）；Matter 87.45 pps；Micro 93.83 pps（92～96，标准差 1.19）。注意这是准入后的包率（csi_admitted_pps），见 tools/lib/firmware_benchmark/analysis.py 中analyze_direct_evidence对csi_admitted_pps字段的解析。
• CSI occupancy（占用率）：Lightweight 88.83%、High Accuracy 86.53%（Native）。它由 tools/lib/temporal_csi_sampler.py 与 src/cpp/core/temporal_csi_sampler.h 共同定义的固定网格准入机制衡量：以目标速率把时间窗口切成槽位，每个槽位至多准入一个 CSI 包，占用率即"已占用槽位数 / 总槽位数"。C++ 与 Python 两端常量一致（TEMPORAL_CSI_MINIMUM_COVERAGE_NUMERATOR = 7U、DENOMINATOR = 10U），保证固件与主机端回放口径统一。
• Direct control attempts：所有 C++ 前端均为120/120 succeeded、censored failures 0，Direct diagnostics samples 60/60 expected——验证通过 Direct v1 HTTP 接口的控制面与诊断面在整个计分窗口内始终可用。
• Status cadence：1.00 s 均值、最大间隔 1.01～1.02 s，Status gaps over tolerance 为 0——诊断采样节奏稳定，无超限间隙（C++ 前端容差 500 ms，见 tools/lib/firmware_benchmark/settings.py 的RUNTIME_STATUS_GAP_TOLERANCE_MS）。
• Motion samples：各前端均收到 234～235 个运动事件，远高于最低要求的 5 个（MIN_MOTION_SAMPLES = 5），证明 Direct SSE 事件流真实有效。

3. 资源稳定性（堆与堆稳定性）

• Heap stability：报告比较启动宽限后的两个连续 10 秒窗口的中位数（HEAP_STABILITY_WINDOW_SECONDS = 10），要求最终窗口中位数较前一窗口下降不超过 5%（HEAP_STABILITY_MAX_DECLINE_PERCENT = 5.0）。本例中 Native Lightweight 为 +0 bytes / +0.00%，Micro 为 +0 bytes，Matter 为 -21 bytes / -0.01%，均无泄漏或持续增长迹象。
• Minimum free heap / Last largest heap block：堆水位与最大连续块，用于判断是否存在严重碎片化；Matter 前端最小空闲堆 153.6～155.8 KiB，在三个 C++ 前端中最低但稳定。

4. 检测器运行时开销（检测时序）

• Runtime load（CPU 负载）：由设备侧累计的空闲/忙碌统计得到，Lightweight 6.73%～6.91%，High Accuracy 9.20%～9.93%，差异与检测器每包/每帧计算量一致。
• Detection average / minimum / maximum：Lightweight 检测均值约 766～919 us，High Accuracy 约 3101～3907 us，最小值普遍在 0～28 us（命中快速路径），最大值在 1.3～7.2 ms 之间；这些时序来自RuntimeMetrics.detection_*字段，见 tools/lib/firmware_benchmark/models.py。
• Loop average / maximum：主循环平均 714～1782 us；Matter Lightweight 的 Loop maximum 高达 123609 us，与其协议栈偶发长任务相关，但不影响整体通过判定（通过判定不基于单次循环峰值）。

5. Matter 前端的配网验证（BSSID 证据链）

Matter 用例的指标表包含一组 BSSID 配网证据字段：Frontend setup final BSSID requested / applied through Direct / already associated / reassociation exercised / association verified全部为 yes。这些字段由 tools/lib/firmware_benchmark/report.py 的_bssid_provisioning_evidence从transport_evidence["bssid_provisioning"]渲染，用于证明 Matter 前端在通过 CHIP Tool 完成 BLE + Wi-Fi 配网后，能够经由 Direct 接口对目标 BSSID 完成请求—应用—重关联—验证的完整链路。ESPHome 用例中already associated为 no 而reassociation exercised为 yes，说明其走了实际的重关联路径；Native 用例为 already associated=yes，说明设备在采样前已关联目标 AP，重关联被实际执行（reassociation exercised=yes）以验证链路。

Pass Criteria：一套可编程的判定契约

报告的通过标准不是人工主观判断，而是由 tools/lib/firmware_benchmark/report.py 的render_report根据本次运行的用例集合程序化生成的，每条都对应源码中的常量或分析函数。ESP32-C6 报告逐条列出，核心条款包括：

• 所有必需的构建、烧录、部署全部成功；
• Native、ESPHome、Matter、Micro-ESPectre 在整个计分窗口内协商Direct v1并采样规范化诊断数据；
• Native 与 ESPHome 使用规范化固件默认值、烧录时清除全部设备数据、并通过Improv Serial配网；
• Matter 清除全部设备数据、通过版本兼容的 CHIP Tool 控制器经 BLE 与 Wi-Fi 完成配网并到达其 Direct 端点；
• 各前端上报 Lightweight 检测、配置的内部受管流量、运行期变更前100 pps 目标（对应 tools/lib/firmware_benchmark/settings.py 的MINIMUM_BENCHMARK_CSI_TARGET_PPS = 100）；
• Native 保持未配置 MQTT（隔离 MQTT 变量，验证 Direct 路径独立性）；
• 传感前端通过 Direct SSE 收到至少 5 个规范化运动事件（MIN_MOTION_SAMPLES）；
• 启动宽限后空闲堆提供两个完整的连续 10 秒窗口，且最终窗口中位数相对前一窗口下降不超过 5%；
• 计分窗口内设备 uptime 不发生重启（对应 tools/lib/firmware_benchmark/analysis.py 中device_reboots检测）；
• Direct 诊断节奏保持在运行期间隙容差内，运动事件保持实时；
• 全部 7 个运行期用例的CSI 占用率均值 ≥ 70% 的 admitted-slot detector-ready 下限——该值由MINIMUM_OCCUPANCY_PERCENT = 100.0 * MINIMUM_COVERAGE_NUMERATOR / MINIMUM_COVERAGE_DENOMINATOR计算，即100 * 7 / 10 = 70%，与 C++ 端 src/cpp/core/temporal_csi_sampler.h 的 7/10 常量一一对应；
• 检测器时序数据存在（detector timing is present）；
• Direct 发送失败与意外拒绝连接数不增长（当前端暴露相应计数器时）；
• Micro-ESPectre 运行期启动器在整个 Direct 采集期间保持活跃。

如何在你的 ESP32-C6 上复现这套基准

前置准备：Wi-Fi 与可选 Matter 配置

基准需要真实 Wi-Fi 环境，运行前必须提供 SSID/密码。仓库提供了模板 tools/benchmark_firmware.local.env.example，复制为tools/benchmark_firmware.local.env后填写：

ESPECTRE_BENCHMARK_WIFI_SSID="Your Wi-Fi SSID" ESPECTRE_BENCHMARK_WIFI_PASSWORD="Your Wi-Fi password" ESPECTRE_BENCHMARK_WIFI_BSSID="" ESPECTRE_BENCHMARK_WIFI_CHANNEL=0 # ESPECTRE_BENCHMARK_CHIP_TOOL="/path/to/chip-tool" # ESPECTRE_BENCHMARK_DIRECT_TIMED_NONPERSISTENT=0 # ESPECTRE_BENCHMARK_CHIP_TOOL_REVISION="connectedhomeip git revision" # ESPECTRE_BENCHMARK_MATTER_COMMISSIONING_TIMEOUT_SECONDS=180 # ESPECTRE_BENCHMARK_MATTER_COMMISSIONING_ATTEMPTS=2

注意两点约束（见 tools/lib/firmware_benchmark/settings.py 的require_benchmark_prerequisites）：SSID 与密码为必填；若设置了ESPECTRE_BENCHMARK_WIFI_CHANNEL，则必须同时设置ESPECTRE_BENCHMARK_WIFI_BSSID，以便基准钉住并验证单个接入点。运行 Matter 用例还需要ESPECTRE_BENCHMARK_CHIP_TOOL指向可用的 CHIP Tool。

运行完整基准

python tools/benchmark_firmware.py --chip c6 --port /dev/ttyUSB0

--chip c6是必选参数（可用芯片集合SUPPORTED_CHIPS由 ESPHome 配置与 Native 目标的交集推导），--port指向串口。全部 7 个用例按 Native → ESPHome → Matter → Micro-ESPectre 顺序执行；任一用例失败会立即终止并保留部分报告（BenchmarkCaseFailed处理逻辑，见 tools/benchmark_firmware.py）。

常用进阶参数

其中--update/--resume涉及旧用例的来源问题——这正是报告头部 Snapshot scope 特别提示使用 per-run artifacts 追溯精确来源的原因。默认 artifacts 目录位于data/untracked/firmware_benchmarks/下，每个运行目录包含各用例的build/deploy/flash/monitor日志（.log）、逐行事件流（.jsonl）、analysis.json（结构化指标）与manifest.json（运行元数据与源指纹）。

运行期间工具会两次计算仓库状态（repository_state()）：对比 Git 修订与BENCHMARK_SOURCE_PATHS（含src/cpp、src/python/espectre_cli、src/python/micro_espectre、tools/benchmark_firmware.py、tools/lib/firmware_benchmark等）的源指纹。若运行中修订发生变化，结果会被标记 FAIL（"benchmark source provenance is invalid"）；仅源文件变化则输出 WARNING 但结果仍有效——这保证了报告的可追溯性。

横向补充：ESP32-C6 检测器精度（数据报告）

运行期基准回答"固件跑得稳不稳"，识别精度则由 docs/performance/README.md（数据来源data/dataset_info.json，评估视图HT20/HT-LTF）回答。其中 ESP32-C6 在正常 Wi-Fi 信号下的结果：

• Lightweight：Recall 100.0%、Precision 98.9%、FP Rate 0.6%、F1-Score 99.4%、有效误报 1 次；
• High Accuracy：Recall 100.0%、Precision 100.0%、FP Rate 0.0%、F1-Score 100.0%、有效误报 0 次。

弱 Wi-Fi 信号（reserved selection + holdout 录音）下：Lightweight Recall 99.7%、FP Rate 0.6%；High Accuracy Recall 99.7%、FP Rate 0.0%，均满足弱信号下 High Accuracy 的 Recall>90%、FP<10% 要求。两份报告互补使用：精度报告回答"检测器算法好不好"，本固件报告回答"在真实芯片与真实 Wi-Fi 环境中，检测所需的 CSI 数据流是否完整、稳定、及时"。

阅读建议与结论

• 若关注资源占用，优先看 Summary 矩阵的 Binary size、Min free heap 与 CPU load 三列；
• 若关注感知数据质量，重点看 Packet rate 与 CSI occupancy，并对照 70% 的 detector-ready 门槛；
• 若关注长期稳定性，看 Heap stability 两窗口中位数差值与 Device uptime restarts；
• 若关注配网与控制链路，看 Direct control attempts、Direct diagnostics samples 与 BSSID 证据链字段。

本报告的全部判定均由 tools/lib/firmware_benchmark 下的模型、分析、报告三件套程序化完成，任意指标低于契约即触发对应 failure reason 并输出到报告与 artifacts，因此这份 ESP32-C6 报告既是开发自检工具，也是一份可审计、可复现、可追溯到具体 Git 修订的固件质量证据。

【免费下载链接】espectreWi-Fi CSI motion sensing for ESP32. C++ SDK, ESPHome, Native, and Matter frontends, browser tools, and a CLI for the full device lifecycle. GPLv3 and commercial licensing.项目地址: https://gitcode.com/GitHub_Trending/es/espectre