⌁ BLE LAB硬件定位下载记录模板 ↗
硬件工程师工作页 · 无适配器场景

没有适配器,
先把量具侧链路查清。

用手机做蓝牙对照,用串口和板端日志拆开链路。
先找到命令或回复在哪一步消失,再讨论更换硬件。

没有 BL654 / E104 也能开始建议方案 · 下列实验尚未执行
可执行的检查与交付清单

沿证据找断点,不凭现象判硬件。

下载定位方案 ↓

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

先定位量具侧,再向适配器现场索取证据。不需要先拿到 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 工具说明 ↗

抓包工具可能没跟上建连,记录也可能不完整;“没抓到”不能单独当作“没发送”。先跟踪一台能复现的对象,与两端日志结合。Nordic 抓包控制与限制 ↗

结合这次 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 文档 ↗:按具体料号核对原理图和规格。模块电源规格不能直接代替整只 USB 适配器的测试点规格。

Ezurio:BL654 的独立蓝牙栈及串口表现 ↗:排查时区分主机串口接口和产品内部蓝牙栈。

Intel:USB 3.0 对 2.4GHz 的射频干扰 ↗:部分 USB 3 设备及线缆可能影响 2.4GHz,可作为现场对照方向;不是本次已确认的原因。

返回 PoC查看 1Hz / 4Hz 实测与完整报告 ↗工程师交付下载单台稳定性记录模板 CSV ↓