简介基于Visual C的蓝牙HCI通信程序源代码面向初学蓝牙编程或希望深入理解蓝牙协议栈的开发者解决在Windows环境下通过HCI接口实现主机与蓝牙控制器之间数据交互的问题。压缩包共25个文件以.h头文件和.cpp源文件为主体分别用于接口声明与核心逻辑实现辅以工程配置、界面资源与说明文档整体体积仅69KB结构清晰便于按模块查阅。目前已有591人学习参考适合作为蓝牙入门实践的参考资料。代码覆盖蓝牙适配器初始化与参数配置、HCI命令发送及事件响应、数据包封装与收发、通信错误处理、安全配对机制以及基于SDP的蓝牙服务发现等关键环节同时借助Windows蓝牙API实现设备查找、连接与数据传输。读者可借此掌握VC环境下蓝牙应用开发的基本流程理解HCI层在协议栈中的位置与运作方式也能为后续扩展自定义蓝牙服务或低功耗蓝牙应用积累基础。1. 蓝牙VC开发绕不开的BluetoothHCI这个标题在讲什么用 Visual C 做过蓝牙串口或 SPP 项目的人应该碰到过这种场景代码没变换一个 USB 蓝牙适配器就连接失败或者想在做连接之前拿到周边设备的 RSSI却被系统上层的蓝牙 API 挡在外面。稍微往底层探就会发现绝大多数射频行为都由蓝牙控制器完成而 Host 与 Controller 之间的对话接口就是 HCI。这个标题里的“BluetoothHCI 蓝牙VC源代码”核心就是绕过 RFCOMM/GATT 那层封装用 VC 自己构造 HCI 命令包、解析 HCI 事件包。它适合驱动调试、协议分析、产测工具开发也适合想做蓝牙测距但不想依赖手机 SDK 的开发者。下文直接给出可在 Visual Studio 里编译的最小实现。2. HCI层在蓝牙协议栈中的角色与VC访问路径2.1 Host与Controller之间到底隔了什么现代蓝牙协议栈在逻辑上分成 Host 和 Controller 两半。Host 侧运行 L2CAP、RFCOMM、GATT 等协议负责服务发现、连接建立和数据封装Controller 侧负责物理信道、跳频、扫描、寻呼、链路连接和收发时序。二者之间的分界线就是 HCI规范里把这条分界线做成命令和事件的接口。标题里提到的 BloothHCI 源代码本质上就是在 Host 侧自己实现这个接口然后通过一个传输通道把命令发给 Controller再接收 Controller 上报的事件。很多 VC 工程师习惯用 Winsock 的 AF_BTH 或 Windows 的 RFCOMM API这些接口拿不到 HCI 事件也无法直接控制底层扫描参数。当你需要知道某个经典蓝牙设备的 RSSI或者要让模块进入低功耗监听模式时高层 API 往往没有暴露对应能力。HCI 层则把射频控制权全部交出来代价是字节流要自己编自己拆调试也从方便的函数调用变成十六进制打印。2.2 HCI三类数据包和命令帧结构一个 HCI 包以 1 字节包类型开头。经典蓝牙和蓝牙 LE 在这一层的格式基本一致常见包类型如下表包类型Packet Indicator用途HCI Command0x01Host 下发命令给 ControllerHCI ACL Data0x02承载 L2CAP 及应用数据HCI Synchronous0x03SCO/eSCO 语音数据HCI Event0x04Controller 返回事件给 Host这里主要关注 0x01 和 0x04。HCI Command 包的结构为包类型(1) OpCode(2) 参数总长度(1) 参数(0-255)。OpCode 是高 6 位 OGF 和低 10 位 OCF 拼起来的 16 位小端整数。以 HCI_Reset 为例OGF0x03Controller BasebandOCF0x0003OpCode 就是 0x0C03写入串口时字节序为 03 0C。参数长度为 0所以整帧只有 4 字节// HCI Command: Reset, OpCode0x0C03, Parameter Length0 BYTE hci_reset_cmd[] { 0x01, 0x03, 0x0C, 0x00 };Controller 收到后返回 Command Complete 事件事件码 0x0E紧接着是参数长度、Num_HCI_Command_Packets、命令 OpCode 和状态。正确解析后的结果应该是// HCI Event: Event Code0x0E, Param Len4 // Num Packets1, Opcode0x0C03, Status0 BYTE hci_reset_evt[] { 0x04, 0x0E, 0x04, 0x01, 0x03, 0x0C, 0x00 };这里最容易出错的是 OpCode 的小端顺序看到 03 0C 时不要按文档写成 0x030C。这层细节也正是“BluetoothHCI 源码”里最值得先看的部分。2.3 VC环境下做HCI调试的通道选择在 Windows 上原生访问 HCI 设备并不统一不同蓝牙适配器的驱动对用户态开放的接口差异很大。我一般会换一种更可控的方式让蓝牙模块工作在 HCI over UART 模式通过 USB 转 TTL 接进 PCVisual Studio 里用 CreateFile 打开 COM 口按 H4 协议发送 HCI 帧。这样不依赖厂商私有 SDK代码在嵌入式平台和 PC 上都能跑。连接通道确认后先不用写完整代码直接用串口助手发送01 03 0C 00如果模块回04 0E 04 01 03 0C 00说明 HCI 链路没问题。如果没回先查 RX/TX 是否接反再看模块是否真的处于 HCI 模式。很多双模模块上电默认是透传或 AT 指令模式需要拉高特定 GPIO 进入 HCI这一点必须在模块手册里确认。3. 用VC写HCI命令帧与事件解析的最小源码3.1 先把HCI字段装进字节数组一个能跑的Reset最小可用的 VC 工程不需要 MFC也不用第三方库Win32 控制台项目就够。核心步骤只有三步打开串口、配置 DCB、写入 HCI 帧。下面这段代码可以直接用来验证 HCI_Reset#include windows.h #include stdio.h HANDLE hCom CreateFileA(COM3, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (hCom INVALID_HANDLE_VALUE) { printf(Open COM3 failed: %u\n, GetLastError()); return 1; } DCB dcb { sizeof(dcb) }; GetCommState(hCom, dcb); dcb.BaudRate 115200; // 以模块手册为准 dcb.ByteSize 8; dcb.Parity NOPARITY; dcb.StopBits ONESTOPBIT; dcb.fOutxCtsFlow FALSE; // 不确定时先关闭硬件流控 dcb.fRtsControl RTS_CONTROL_DISABLE; SetCommState(hCom, dcb); BYTE reset[] { 0x01, 0x03, 0x0C, 0x00 }; DWORD written 0; if (!WriteFile(hCom, reset, sizeof(reset), written, NULL)) { printf(WriteFile failed: %u\n, GetLastError()); }这段代码里最需要改的不是帧内容而是 DCB 参数。HCI over UART 的 H4 传输固定为 8 数据位、无校验、1 停止位但波特率因模块而异老式经典蓝牙模块多数是 9600 或 57600BLE 4.0 以上模块常见 115200。直接把CreateFileA里的COM3替换成实际端口就可以跑第一轮命令行测试。3.2 读返回事件识别0x04后的结构发送 Reset 后要立刻读事件最直接的读法是先读 1 字节拿到包类型再读 1 字节拿到参数总长度最后按长度读完剩余部分。对应伪代码如下BYTE buf[256] { 0 }; DWORD got 0; ReadFile(hCom, buf, 1, got, NULL); // Packet Indicator if (buf[0] ! 0x04) return; // 不是 Event Packet 就不处理 ReadFile(hCom, buf, 1, got, NULL); BYTE plen buf[0]; // Parameter Length ReadFile(hCom, buf, plen, got, NULL); // Event Code 参数这个读法在低速、小包、命令简单时能用但不严谨。ReadFile返回的字节数可能小于你要求的长度尤其当模块通过 USB 转 TTL 接入时HCI 事件可能被驱动拆成两三次到达。正确做法是写一个ReadExact循环像接收完整帧一样处理。3.3 封装成C类并处理粘包多点几次命令后就会遇到串口最常见的“粘包”上一次事件的尾部和下一次事件的头部同时出现在缓冲区里。解决办法是每次收到字节后先存入内部缓冲区然后按包类型和长度字段判断是否已经凑够一包凑够了再交给上层解析。放在 VC 里可以很自然地封装成类class HciTransport { public: bool Open(const char* port, DWORD baud); bool Send(BYTE* cmd, size_t len); int ReadEvent(BYTE* out, int maxOut); private: HANDLE hCom_; BYTE frameBuf_[256]; int frameLen_; };Send负责写串口ReadEvent负责从 frameBuf_ 里截取完整事件包。类内部只需要维护两个状态已经收到多少字节、当前包的预期总长度。这种写法比每次临时分配缓冲区更容易排查“事件解析错位”问题也方便后续扩展到 HCI_LE_Meta 事件这类等长不固定的场景。3.4 在Visual Studio里快速验证在 Visual Studio 中新建一个空控制台工程把上述代码粘贴进 main按 F5 调试。断点打在ReadEvent返回后打开“内存”窗口查看收到的字节能直观确认04 0E 04 01 03 0C 00这套结构。如果要换 COM 口直接在代码里改CreateFileA的端口名即可。这一步很容易忽略的是串口助手的“发送新行”选项。很多串口工具默认在帧尾追加0A导致 HCI 包变成01 03 0C 00 0A模块可能能解析但后续调试时事件边界会被破坏。建议所有测试都用十六进制发送并关闭追加换行。4. HCI over UART 的串口参数、流控与常见坑4.1 为什么事件会漂移DCB必调参数HCI over UART 没有额外的 CRC也不做波特率自动协商模块固件写死什么参数就得按什么参数收。很多“看起来像 HCI 帧没写对”的现场其实都是流控不匹配。我在多款蓝牙模块上默认使用下面这组参数参数建议值备注BaudRate115200以模块手册为准ByteSize8固定ParityNOPARITY固定StopBitsONESTOPBIT固定fOutxCtsFlow根据模块是否启用 CTS不确定时先 FALSEfRtsControlRTS_CONTROL_DISABLE/HANDSHAKE与上一项配合如果模块默认开了硬件流控而代码没有Controller 可能不会丢字节但会在 RTS 信号拉低时停止发送导致事件迟迟不到。反之代码开了硬件流控而模块没接 CTS/RTS机会出现命令一直未得到响应。调试初期我会先把流控全部关闭等命令通路确认正常后再按需打开。4.2 解析不到Command Complete时的排查顺序当 VC 程序一直等不到04 0E不要急着改代码。先从物理链路开始往回推。用一段最原始的循环把收到的每个字节都打出来比任何断点都直观BYTE c; DWORD n; while (true) { if (ReadFile(hCom, c, 1, n, NULL) n 1) { printf(%02X , c); fflush(stdout); } }如果打印结果里没有任何字节先检查 RX/TX 是否接反再确认模块是否处于 HCI 模式。如果打印出大量FF或随机字符多半是波特率不匹配。如果收到04 0E但参数少一截则是 ReadFile 没有按完整长度读取需要改用 3.3 节的累积读取逻辑。这里还有一个经典蓝牙与 BLE 的差异点经典蓝牙模块的 Command Complete 事件里OpCode 直接对应命令包里的 OpCodeBLE 命令则经常返回04 0E 04 01 XX XX 00但是很多双模模块会先返回一个 Command Status04 13随后再返回 Connection Complete 等异步事件。看到两个事件码都别急着认为出错先看 Status 字节是不是 0。4.3 版本差异经典蓝牙与BLE HCI的不同处理HCI 规范里 OGF0x01 是 Link Control 组经典蓝牙的 Inquiry 命令在这一组OGF0x08 是 LE Controller 组BLE 扫描和连接命令都在这里。标题里只写了 Bluetooth 和 VC说明源码很可能要同时兼容经典和 LE这时不能把事件表按固定数组一次性写完建议按 OGF 分派解析函数。BLE 5.0 之后还新增了HCI_LE_Extended_Create_Connection、Periodic Advertising 等事件事件码和参数布局比经典蓝牙复杂得多。遇到这类命令时我会把ReadEvent收到的原始事件先落盘一份再对照 Core Spec 的对应版本逐字节核对。固件版本和 HCI 规范版本不一致是低层开发最好用的调试点之一。5. 用HCI_Inquiry_Result_with_RSSI做一个蓝牙测距起点5.1 让HCI进入Inquiry状态拿到 RSSI 最直接的方式是经典蓝牙的 Inquiry 过程。HCI_Inquiry 命令的参数有 3 字节 LAP、1 字节扫描时长、1 字节响应数量上限。使用 GIAC 的 LAP0x9E8B33扫描时长设为 5 秒命令包如下BYTE inquiry[] { 0x01, // Command Packet 0x01, 0x04, // OpCode: OGF0x01, OCF0x0001 0x05, // Parameter Length 0x33, 0x8B, 0x9E, // LAP: GIAC 0x05, // Inquiry_Length: 5 秒 0x00 // Num_Responses: 0 表示不限 }; WriteFile(hCom, inquiry, sizeof(inquiry), written, NULL);命令发出后Controller 会周期性上报HCI_Inquiry_Result0x02或带 RSSI 的HCI_Inquiry_Result_with_RSSI0x22。支持哪个取决于固件建议两个事件码都保留解析入口。5.2 从RSSI事件里提取dBm并做距离粗估当收到 0x22 事件时RSSI 字段位于事件参数末尾是一个有符号单字节数。最简单的方式是把该字节直接接射为 dBm 输出// evt 指向 0x22 事件参数区rssi 位于末尾 signed char rssi (signed char)evt[evtLen - 1]; printf(RSSI %d dBm\n, rssi);单次 RSSI 抖动很大要用于测距至少先做 20 组滑动平均再套路径损耗模型distance 10^((TxPower - RSSI) / (10 * N))。其中 N 是环境衰减因子室内通常取 2 到 4需要自己在固定距离上标定。注意有些适配器返回的 RSSI 是相对本机接收灵敏度的偏移值不能直接当绝对功率统一用同一台机器、同一根天线做对比排序更可靠。把每一条 RSSI 和串口接收时间戳写入 CSV再结合实测距离拟合 N 值就能得到可用的近距测距参考。本文还有配套的精品资源点击获取
简介基于Visual C的蓝牙HCI通信程序源代码面向初学蓝牙编程或希望深入理解蓝牙协议栈的开发者解决在Windows环境下通过HCI接口实现主机与蓝牙控制器之间数据交互的问题。压缩包共25个文件以.h头文件和.cpp源文件为主体分别用于接口声明与核心逻辑实现辅以工程配置、界面资源与说明文档整体体积仅69KB结构清晰便于按模块查阅。目前已有591人学习参考适合作为蓝牙入门实践的参考资料。代码覆盖蓝牙适配器初始化与参数配置、HCI命令发送及事件响应、数据包封装与收发、通信错误处理、安全配对机制以及基于SDP的蓝牙服务发现等关键环节同时借助Windows蓝牙API实现设备查找、连接与数据传输。读者可借此掌握VC环境下蓝牙应用开发的基本流程理解HCI层在协议栈中的位置与运作方式也能为后续扩展自定义蓝牙服务或低功耗蓝牙应用积累基础。1. 蓝牙VC开发绕不开的BluetoothHCI这个标题在讲什么用 Visual C 做过蓝牙串口或 SPP 项目的人应该碰到过这种场景代码没变换一个 USB 蓝牙适配器就连接失败或者想在做连接之前拿到周边设备的 RSSI却被系统上层的蓝牙 API 挡在外面。稍微往底层探就会发现绝大多数射频行为都由蓝牙控制器完成而 Host 与 Controller 之间的对话接口就是 HCI。这个标题里的“BluetoothHCI 蓝牙VC源代码”核心就是绕过 RFCOMM/GATT 那层封装用 VC 自己构造 HCI 命令包、解析 HCI 事件包。它适合驱动调试、协议分析、产测工具开发也适合想做蓝牙测距但不想依赖手机 SDK 的开发者。下文直接给出可在 Visual Studio 里编译的最小实现。2. HCI层在蓝牙协议栈中的角色与VC访问路径2.1 Host与Controller之间到底隔了什么现代蓝牙协议栈在逻辑上分成 Host 和 Controller 两半。Host 侧运行 L2CAP、RFCOMM、GATT 等协议负责服务发现、连接建立和数据封装Controller 侧负责物理信道、跳频、扫描、寻呼、链路连接和收发时序。二者之间的分界线就是 HCI规范里把这条分界线做成命令和事件的接口。标题里提到的 BloothHCI 源代码本质上就是在 Host 侧自己实现这个接口然后通过一个传输通道把命令发给 Controller再接收 Controller 上报的事件。很多 VC 工程师习惯用 Winsock 的 AF_BTH 或 Windows 的 RFCOMM API这些接口拿不到 HCI 事件也无法直接控制底层扫描参数。当你需要知道某个经典蓝牙设备的 RSSI或者要让模块进入低功耗监听模式时高层 API 往往没有暴露对应能力。HCI 层则把射频控制权全部交出来代价是字节流要自己编自己拆调试也从方便的函数调用变成十六进制打印。2.2 HCI三类数据包和命令帧结构一个 HCI 包以 1 字节包类型开头。经典蓝牙和蓝牙 LE 在这一层的格式基本一致常见包类型如下表包类型Packet Indicator用途HCI Command0x01Host 下发命令给 ControllerHCI ACL Data0x02承载 L2CAP 及应用数据HCI Synchronous0x03SCO/eSCO 语音数据HCI Event0x04Controller 返回事件给 Host这里主要关注 0x01 和 0x04。HCI Command 包的结构为包类型(1) OpCode(2) 参数总长度(1) 参数(0-255)。OpCode 是高 6 位 OGF 和低 10 位 OCF 拼起来的 16 位小端整数。以 HCI_Reset 为例OGF0x03Controller BasebandOCF0x0003OpCode 就是 0x0C03写入串口时字节序为 03 0C。参数长度为 0所以整帧只有 4 字节// HCI Command: Reset, OpCode0x0C03, Parameter Length0 BYTE hci_reset_cmd[] { 0x01, 0x03, 0x0C, 0x00 };Controller 收到后返回 Command Complete 事件事件码 0x0E紧接着是参数长度、Num_HCI_Command_Packets、命令 OpCode 和状态。正确解析后的结果应该是// HCI Event: Event Code0x0E, Param Len4 // Num Packets1, Opcode0x0C03, Status0 BYTE hci_reset_evt[] { 0x04, 0x0E, 0x04, 0x01, 0x03, 0x0C, 0x00 };这里最容易出错的是 OpCode 的小端顺序看到 03 0C 时不要按文档写成 0x030C。这层细节也正是“BluetoothHCI 源码”里最值得先看的部分。2.3 VC环境下做HCI调试的通道选择在 Windows 上原生访问 HCI 设备并不统一不同蓝牙适配器的驱动对用户态开放的接口差异很大。我一般会换一种更可控的方式让蓝牙模块工作在 HCI over UART 模式通过 USB 转 TTL 接进 PCVisual Studio 里用 CreateFile 打开 COM 口按 H4 协议发送 HCI 帧。这样不依赖厂商私有 SDK代码在嵌入式平台和 PC 上都能跑。连接通道确认后先不用写完整代码直接用串口助手发送01 03 0C 00如果模块回04 0E 04 01 03 0C 00说明 HCI 链路没问题。如果没回先查 RX/TX 是否接反再看模块是否真的处于 HCI 模式。很多双模模块上电默认是透传或 AT 指令模式需要拉高特定 GPIO 进入 HCI这一点必须在模块手册里确认。3. 用VC写HCI命令帧与事件解析的最小源码3.1 先把HCI字段装进字节数组一个能跑的Reset最小可用的 VC 工程不需要 MFC也不用第三方库Win32 控制台项目就够。核心步骤只有三步打开串口、配置 DCB、写入 HCI 帧。下面这段代码可以直接用来验证 HCI_Reset#include windows.h #include stdio.h HANDLE hCom CreateFileA(COM3, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (hCom INVALID_HANDLE_VALUE) { printf(Open COM3 failed: %u\n, GetLastError()); return 1; } DCB dcb { sizeof(dcb) }; GetCommState(hCom, dcb); dcb.BaudRate 115200; // 以模块手册为准 dcb.ByteSize 8; dcb.Parity NOPARITY; dcb.StopBits ONESTOPBIT; dcb.fOutxCtsFlow FALSE; // 不确定时先关闭硬件流控 dcb.fRtsControl RTS_CONTROL_DISABLE; SetCommState(hCom, dcb); BYTE reset[] { 0x01, 0x03, 0x0C, 0x00 }; DWORD written 0; if (!WriteFile(hCom, reset, sizeof(reset), written, NULL)) { printf(WriteFile failed: %u\n, GetLastError()); }这段代码里最需要改的不是帧内容而是 DCB 参数。HCI over UART 的 H4 传输固定为 8 数据位、无校验、1 停止位但波特率因模块而异老式经典蓝牙模块多数是 9600 或 57600BLE 4.0 以上模块常见 115200。直接把CreateFileA里的COM3替换成实际端口就可以跑第一轮命令行测试。3.2 读返回事件识别0x04后的结构发送 Reset 后要立刻读事件最直接的读法是先读 1 字节拿到包类型再读 1 字节拿到参数总长度最后按长度读完剩余部分。对应伪代码如下BYTE buf[256] { 0 }; DWORD got 0; ReadFile(hCom, buf, 1, got, NULL); // Packet Indicator if (buf[0] ! 0x04) return; // 不是 Event Packet 就不处理 ReadFile(hCom, buf, 1, got, NULL); BYTE plen buf[0]; // Parameter Length ReadFile(hCom, buf, plen, got, NULL); // Event Code 参数这个读法在低速、小包、命令简单时能用但不严谨。ReadFile返回的字节数可能小于你要求的长度尤其当模块通过 USB 转 TTL 接入时HCI 事件可能被驱动拆成两三次到达。正确做法是写一个ReadExact循环像接收完整帧一样处理。3.3 封装成C类并处理粘包多点几次命令后就会遇到串口最常见的“粘包”上一次事件的尾部和下一次事件的头部同时出现在缓冲区里。解决办法是每次收到字节后先存入内部缓冲区然后按包类型和长度字段判断是否已经凑够一包凑够了再交给上层解析。放在 VC 里可以很自然地封装成类class HciTransport { public: bool Open(const char* port, DWORD baud); bool Send(BYTE* cmd, size_t len); int ReadEvent(BYTE* out, int maxOut); private: HANDLE hCom_; BYTE frameBuf_[256]; int frameLen_; };Send负责写串口ReadEvent负责从 frameBuf_ 里截取完整事件包。类内部只需要维护两个状态已经收到多少字节、当前包的预期总长度。这种写法比每次临时分配缓冲区更容易排查“事件解析错位”问题也方便后续扩展到 HCI_LE_Meta 事件这类等长不固定的场景。3.4 在Visual Studio里快速验证在 Visual Studio 中新建一个空控制台工程把上述代码粘贴进 main按 F5 调试。断点打在ReadEvent返回后打开“内存”窗口查看收到的字节能直观确认04 0E 04 01 03 0C 00这套结构。如果要换 COM 口直接在代码里改CreateFileA的端口名即可。这一步很容易忽略的是串口助手的“发送新行”选项。很多串口工具默认在帧尾追加0A导致 HCI 包变成01 03 0C 00 0A模块可能能解析但后续调试时事件边界会被破坏。建议所有测试都用十六进制发送并关闭追加换行。4. HCI over UART 的串口参数、流控与常见坑4.1 为什么事件会漂移DCB必调参数HCI over UART 没有额外的 CRC也不做波特率自动协商模块固件写死什么参数就得按什么参数收。很多“看起来像 HCI 帧没写对”的现场其实都是流控不匹配。我在多款蓝牙模块上默认使用下面这组参数参数建议值备注BaudRate115200以模块手册为准ByteSize8固定ParityNOPARITY固定StopBitsONESTOPBIT固定fOutxCtsFlow根据模块是否启用 CTS不确定时先 FALSEfRtsControlRTS_CONTROL_DISABLE/HANDSHAKE与上一项配合如果模块默认开了硬件流控而代码没有Controller 可能不会丢字节但会在 RTS 信号拉低时停止发送导致事件迟迟不到。反之代码开了硬件流控而模块没接 CTS/RTS机会出现命令一直未得到响应。调试初期我会先把流控全部关闭等命令通路确认正常后再按需打开。4.2 解析不到Command Complete时的排查顺序当 VC 程序一直等不到04 0E不要急着改代码。先从物理链路开始往回推。用一段最原始的循环把收到的每个字节都打出来比任何断点都直观BYTE c; DWORD n; while (true) { if (ReadFile(hCom, c, 1, n, NULL) n 1) { printf(%02X , c); fflush(stdout); } }如果打印结果里没有任何字节先检查 RX/TX 是否接反再确认模块是否处于 HCI 模式。如果打印出大量FF或随机字符多半是波特率不匹配。如果收到04 0E但参数少一截则是 ReadFile 没有按完整长度读取需要改用 3.3 节的累积读取逻辑。这里还有一个经典蓝牙与 BLE 的差异点经典蓝牙模块的 Command Complete 事件里OpCode 直接对应命令包里的 OpCodeBLE 命令则经常返回04 0E 04 01 XX XX 00但是很多双模模块会先返回一个 Command Status04 13随后再返回 Connection Complete 等异步事件。看到两个事件码都别急着认为出错先看 Status 字节是不是 0。4.3 版本差异经典蓝牙与BLE HCI的不同处理HCI 规范里 OGF0x01 是 Link Control 组经典蓝牙的 Inquiry 命令在这一组OGF0x08 是 LE Controller 组BLE 扫描和连接命令都在这里。标题里只写了 Bluetooth 和 VC说明源码很可能要同时兼容经典和 LE这时不能把事件表按固定数组一次性写完建议按 OGF 分派解析函数。BLE 5.0 之后还新增了HCI_LE_Extended_Create_Connection、Periodic Advertising 等事件事件码和参数布局比经典蓝牙复杂得多。遇到这类命令时我会把ReadEvent收到的原始事件先落盘一份再对照 Core Spec 的对应版本逐字节核对。固件版本和 HCI 规范版本不一致是低层开发最好用的调试点之一。5. 用HCI_Inquiry_Result_with_RSSI做一个蓝牙测距起点5.1 让HCI进入Inquiry状态拿到 RSSI 最直接的方式是经典蓝牙的 Inquiry 过程。HCI_Inquiry 命令的参数有 3 字节 LAP、1 字节扫描时长、1 字节响应数量上限。使用 GIAC 的 LAP0x9E8B33扫描时长设为 5 秒命令包如下BYTE inquiry[] { 0x01, // Command Packet 0x01, 0x04, // OpCode: OGF0x01, OCF0x0001 0x05, // Parameter Length 0x33, 0x8B, 0x9E, // LAP: GIAC 0x05, // Inquiry_Length: 5 秒 0x00 // Num_Responses: 0 表示不限 }; WriteFile(hCom, inquiry, sizeof(inquiry), written, NULL);命令发出后Controller 会周期性上报HCI_Inquiry_Result0x02或带 RSSI 的HCI_Inquiry_Result_with_RSSI0x22。支持哪个取决于固件建议两个事件码都保留解析入口。5.2 从RSSI事件里提取dBm并做距离粗估当收到 0x22 事件时RSSI 字段位于事件参数末尾是一个有符号单字节数。最简单的方式是把该字节直接接射为 dBm 输出// evt 指向 0x22 事件参数区rssi 位于末尾 signed char rssi (signed char)evt[evtLen - 1]; printf(RSSI %d dBm\n, rssi);单次 RSSI 抖动很大要用于测距至少先做 20 组滑动平均再套路径损耗模型distance 10^((TxPower - RSSI) / (10 * N))。其中 N 是环境衰减因子室内通常取 2 到 4需要自己在固定距离上标定。注意有些适配器返回的 RSSI 是相对本机接收灵敏度的偏移值不能直接当绝对功率统一用同一台机器、同一根天线做对比排序更可靠。把每一条 RSSI 和串口接收时间戳写入 CSV再结合实测距离拟合 N 值就能得到可用的近距测距参考。本文还有配套的精品资源点击获取
