# 没有适配器时，硬件工程师如何定位稳定性

**先定位量具侧，再向适配器现场索取证据。**不需要先拿到 BL654，工程师也可以检查量具供电、测量 MCU、UART、休眠与手机作为中心设备时的蓝牙响应。但手机单台通过、8 台分别通过，甚至手机多连接通过，都不能代替原 PC + BL654 的 8 台并发验证。

**本页是建议的定位方案，以下实验尚未执行。**当前没有同步供电波形、板端 UART 或空口记录，不能将供电、干扰、休眠或模块转发当成已经确认的根因。

## 三条最短定位路径

| 手上有什么 | 先做什么 | 能得到什么 | 不能证明什么 |
|---|---|---|---|
| 只有手机与量具 | 用现有 Android 采集 App，或支持自定义 GATT 的工具，连接单台，按 1Hz、4Hz 查询；8 台逐台对照 | 手机条件下哪一台会缺回、断开或唤醒失败 | 不能证明 PC 与原适配器无问题；8 台分别通过不是 8 台并发通过 |
| 另有测试点与仪器 | 被动监听蓝牙模块与测量 MCU 的 UART，同步观察供电与复位；有受支持的测试接口时再做直接有线查询 | 命令是否到了 MCU，回复有没有产生、有没有送给模块 | 只有串口记录仍不能判定整条蓝牙链路；不能用任意接口直接注入命令 |
| 现场有人有原适配器 | 请对方固定 8 台、版本、频率与位置，运行原 PoC；工程师远程分析日志 | 原 PC + 适配器的异常分类，并与板端证据对齐 | 没有适配器端或空口证据时，不能直接判适配器硬件故障 |

## 第一步：手机单台检查

- 每台贴实物编号，记录 MAC、量具回包编号、硬件和固件版本。默认回包编号可能重复，以 MAC 与实物标签共同识别。
- 确认量具处于测量工作状态，其他手机和采集程序已断开。固定手机、程序、位置、距离和方向，手机 App 前台运行。
- 确认通知开启，先检查一条查询能返回测量数据，再正式计数：1Hz 5 分钟，4Hz 连续两轮各 5 分钟。
- 记录计划次数、真实发送时间、原始通知、缺回、迟到和断开。1Hz 每台计划 300 次；4Hz 每轮每台计划 1200 次。
- 8 台分别执行相同流程，判断异常是否反复跟随某台量具。通过与失败的原始记录都保留。

沿用已验证测量命令：`CMA:G-DATA\r\n`，ASCII，含回车换行。使用原 GATT 服务及通知配置。工具如果不能可靠按 4Hz 定时发送，就标为“手动功能验证”，不能写成“4Hz 稳定性验证”。

接收等待可设 5 秒，但查询周期仍保持 250ms。不要为了测试随意发送 AT 配置、改变广播参数或刷写固件；手机 App 和系统也可能引入调度问题，手机异常不能直接等同于量具硬件故障。

## 第二步：用 UART 和供电把问题拆开

| 检查项 | 怎么做 | 必须留下什么证据 | 怎样解读 |
|---|---|---|---|
| 模块与 MCU 串口 | 逻辑分析仪高阻被动监听两个方向，先核对引脚、电平、波特率与帧格式 | 同一异常前后的原始字节、查询到达时间、回复生成与返回时间 | 查询到了 MCU 而无回复，优先查测量、休眠、解析与供电；回复给了模块，再查模块及后续链路 |
| MCU 直接有线查询 | 仅在原理图和固件支持的测试接口上，隔离可能的总线争用后，用 USB 转串口工具按相同协议查询 | 实际接线、固件版本、TX/RX 原文、发送间隔、每轮计数 | 有线也不稳，优先查 MCU、UART 和供电；有线稳而手机蓝牙不稳，再查模块转发与无线通路 |
| 供电与复位 | 测量具蓝牙模块及 MCU 的电源测试点，覆盖启动、查询、无线活动和唤醒；记录复位或启动原因 | 示波器波形、测点、探头方式、时基、器件允许范围及异常时刻 | 供电跌落、复位与缺回同步可形成线索；不能只凭换电池后改善就定因 |
| 休眠与数据新鲜度 | 分别测试一直唤醒、静置、再唤醒；轻移量具等可辨识动作检查测量值更新 | 休眠配置、屏幕状态、动作标记、唤醒后首个有效回数时间 | 蓝牙在线不代表测量 MCU 正在工作；数值重复也不一定是旧数据 |

引脚、电平和电压阈值必须以实际原理图及器件规格为准，不套用通用“3.3V”数值。没有测试点或无法安全监听时，先让供应商 / 固件工程师提供调试日志；不要在正在工作的 UART 上接入第二个主动发送端。

## 沿数据链找到消失的位置

**手机 / PC 计划并提交 → 模块收到 GATT 查询 → MCU 收到 UART 命令 → MCU 产生测量回复 → 模块提交通知 → 手机 / PC 收到并解析。**

| 已观察到的证据 | 优先检查 | 不能跳到的结论 |
|---|---|---|
| 主机记录调度超期，查询根本未提交 | 主机调度、程序停顿、驱动调用耗时，让对应端提供日志 | 不是量具漏回，不能让硬件补一条未收到的命令 |
| 主机写入成功，板端没有查询记录 | 中间链路尚未定位，补模块接收日志或空口证据 | 驱动接受 / 发送完成不等于测量 MCU 收到命令 |
| 模块收到查询，UART 没送给 MCU | 模块转发、串口配置、连接、缓冲、流控（如使用） | 不能直接归因于天线或测量算法 |
| MCU 收到完整查询，却未产生回复 | 测量任务、休眠唤醒、解析状态、供电及复位 | 蓝牙在线不能证明测量 MCU 正常 |
| MCU 回给模块了，中心端没收到 | 模块接收、通知提交结果、连接状态、空口和中心端回调 | 还不能只凭这一点认定射频丢包 |
| 原始通知已经到达，业务统计没计入 | 分帧解析、超时归类、清理时机、请求对应逻辑 | 优先查数据处理，不先更换量具硬件 |

**先对齐时间再比较。**PC、手机、逻辑分析仪的时钟不能直接相减。用同一次可辨识动作、同步触发或明确标记对齐，并记录时钟来源与偏差。协议无请求序号时，对应关系只能估计；有条件可在可控调试固件里加单调计数及接收 / 发送标记，单独记录该固件版本。

## 不依赖原适配器的对照实验

| 对照 | 保持什么不变 | 只改变什么 | 需要判断什么 |
|---|---|---|---|
| 量具 A → B → A | 同一手机、程序、位置、频率和供电条件 | 量具 | 异常是否可重复跟随某台；同时记录固件、设置、电池差异 |
| 裸放 → 包装 → 裸放 | 距离、方向、量具与手机位置、供电 | 包装 / 遮挡 | 回数与缺回是否可重复变化；此前取出泡沫不是严格对照，不能先认定泡沫是原因 |
| 原供电与稳定供电对照 | 固件、负载、摆放与查询节奏 | 产品允许的供电方式 | 波形与缺回是否相关；接口接触、电池和电源管理需分开看 |
| 有线 → 手机蓝牙 → 有线 | 同一量具、命令、频率和计数 | 受支持的查询路径 | 是否只有蓝牙路径异常，再定位模块转发及无线链路 |

一次只变一个因素，测试后回切确认，不只记录“换了以后好了”。RSSI 仅作辅助，不能单独判定稳定性，更不能将广播 RSSI 当成持续连接的实时信号质量。

## 没有适配器，如何向现场取证

| 现场持有适配器的人提供 | 硬件工程师对应分析 |
|---|---|
| 适配器型号、USB 序列号、固件 / 驱动版本与哈希 | 确保比较的是同一条软件与硬件路线 |
| 固定 8 台 MAC、实物编号、批次、固件、供电与唤醒状态 | 不能临时换入健康量具掩盖失败；核对异常是否跟随设备 |
| 原 PoC 的 events、summary、原始通知独立核对结果；保留失败轮次 | 将未发送、已发缺回、迟到、掉线分别计数 |
| 计划 / 实际发送时间、写入返回、通知回调、掉线原因；USB 断开与重新枚举事件（如发生） | 判断异常是在主机提交之前、连接层，还是回数通路 |
| 适配器接法、位置、距离、方向、包装、附近 USB 3 设备及无线环境 | 将环境作为待验证变量；位置与供电同时变化时不能直接定因 |
| 一次约定的标记或动作、板端 UART / 供电 / 复位记录 | 关联同一异常窗口，定位命令或回复在哪一层消失 |

如需空口抓包，让现场准备兼容的专用抓包硬件。Nordic 的 nRF Sniffer 使用兼容 Nordic 设备及抓包固件捕获空口数据；它是额外取证能力，不是“只靠手机就能完成”。不要将正在测试的生产适配器临时改成抓包器。[Nordic 工具说明](https://docs.nordicsemi.com/r/bundle/nrfutil/page/nrfutil-ble-sniffer/wireshark_sniffer_overview.html)

抓包工具可能没跟上建连，记录也可能不完整；“没抓到”不能单独当作“没发送”。先跟踪一台能复现的对象，与两端日志结合。[Nordic 抓包控制与限制](https://docs.nordicsemi.com/r/bundle/nrfutil/page/nrfutil-ble-sniffer/wireshark_sniffer_usage.html)

## 结合这次 PoC，先查哪几件事

| 本次真实记录 | 当前能判断 | 硬件侧下一份关键证据 |
|---|---|---|
| 8 台 1Hz：2400／2400，零掉线 | 该次 5 分钟完整通过，不是长期板级可靠性证明 | 每台手机 / 有线基线与供电记录 |
| 前次 8 台 4Hz：2 次未发、2 条缺回 | C6、D9 未发属于主机调度；F9:A0、F5:D4 缺回的断点仍未知 | 缺回时模块是否收到查询、MCU 是否收到并回复 |
| 5 秒等待下两轮各 9600／9600 | 本次未重现异常；回复未超过原 2 秒，不能仅归功于延长等待 | 控制条件后重复及长期记录，尤其是异常时同步日志 |
| 此前换掉两台后改善 | 有设备构成或状态线索，未确认硬件损坏 | 原两台与正常台，用同一手机及受支持有线接口做 A/B/A 对照 |

## 工程师的最小交付

- 一台一份记录：MAC、实物编号、硬件 / 固件、中心设备、测试频率、实际时长、计划 / 发送 / 回复、未发 / 缺回 / 迟到 / 断开。
- 接线及摆放照片、手机 / 串口原始日志；有仪器时附电源波形、复位日志和抓包，保留异常前后窗口，不只给通过率截图。
- 结论写清边界，例如“手机单台 4Hz 复现，UART 查询到达 MCU 后无回复”或“有线和手机单台通过，原适配器并发待现场验证”。
- 持续运行、休眠恢复、批次验证的时长与阈值由项目冻结为验收条件，不是本页声称已经达到的指标。

**没有原适配器时，能先把量具侧问题定位清楚；PC + BL654 的并发容量和稳定性必须由现场端共同验证。**

## 官方参考

[Ezurio 451-00004 文档](https://www.ezurio.com/support/part/451-00004)：按具体料号核对原理图和规格。模块电源规格不能直接代替整只 USB 适配器的测试点规格。

[Ezurio：BL654 的独立蓝牙栈及串口表现](https://www.ezurio.com/support/faqs/bl654-dongle-not-presenting-bluetooth-adapter)：排查时区分主机串口接口和产品内部蓝牙栈。

[Intel：USB 3.0 对 2.4GHz 的射频干扰](https://www.intel.com/content/www/us/en/content-details/841692/usb-3-0-radio-frequency-interference-impact-on-2-4-ghz-wireless-devices-white-paper.html)：部分 USB 3 设备及线缆可能影响 2.4GHz，可作为现场对照方向；不是本次已确认的原因。