最近在调一个室内定位的小项目需要在ESP32上做蓝牙beacon测距。本来想直接用现成的库但考虑到后续要和自己的业务逻辑深度绑定最后还是决定在ESP-IDF原生环境下从零搞一套。这一篇就把整个过程中踩过的坑、调通的代码、以及RSSI测距从原理到实测的经验完整记录下来给同样准备在ESP32上做蓝牙beacon开发的朋友一个参考。这篇内容不是泛泛讲概念而是完整的实战记录。你会看到怎么在VS Code里搭建ESP-IDF开发环境用ESP-IDF Extension避免各种环境变量的坑、怎么写一个能扫描beacon并估算距离的工程、如何用对数距离路径损耗模型把RSSI换算成距离以及我在不同环境下实测出的衰减因子和校正值。无论你是刚开始接触ESP32开发还是已经在用ESP-IDF但没碰过BLE这篇文章都能帮你省下不少排查时间。1. 蓝牙beacon测距的整体思路与方案选型1.1 为什么用BLE beacon而不是其他方式一个常见的疑问是iOS的iBeacon和Android的Eddystone不是现成的方案吗为什么还要自己在ESP32上做简单梳理一下需求背景。当时这个项目的场景是在室内环境中通过多个固定节点beacon发射端和一个移动节点ESP32接收端之间的位置关系做初步定位。beacon发射端可以是低功耗的BLE广播设备比如市面上二三十块钱一个的iBeacon基站也可以直接用闲置的ESP32刷一个广播程序。接收端需要能灵活处理扫描结果、边扫描边计算并且要把数据喂给上层的定位算法。如果用手机上现成的SDK其实连扫描都省了但问题是手机端的SDK封装太黑盒拿到的基本是已经算好的距离或者直接给了坐标中间RSSI怎么处理、滤波怎么做完全看不到。而ESP32做接收端整个扫描回调、RSSI解析、距离估算的链路都在自己手里想怎么调整就怎么调整也能配合传感器数据做融合。另外一个原因是我手上就有一批ESP32模块NodeMCU-32S和ESP32-WROOM-32都有与其再花几百块买专用测试设备不如直接用现有硬件起步。1.2 RSSI测距的核心原理与理论模型蓝牙beacon测距本质上测的不是“距离”而是“信号强度”。beacon不断向外广播BLE数据包接收端ESP32在扫描时会拿到每个广播包的RSSI值也就是接收信号强度指示单位是dBm它的大小和收发双方的距离之间存在一种可建模的关系。这种关系在很多资料里被称为对数距离路径损耗模型Log-distance Path Loss Model公式是RSSI A - 10 * n * log10(d)公式里的参数分别代表A距离发射端1米处测得的RSSI平均值单位dBmn环境衰减因子反映信号穿过障碍物时的衰减程度没有遮挡的开放空间n约等于2室内有墙有家具的环境可能到2.5到4d接收端与发射端的距离单位米反过来已知RSSI求距离就变成了d 10^((A - RSSI) / (10 * n))这个公式看起来简单但实际用起来有太多值得注意的地方。首先是A值不是一个固定的数它取决于beacon的发射功率和设备的天线设计。有些beacon发射功率是0dBm有些是-12dBm同样1米距离收到的RSSI完全不同。其次是n值它直接受到环境的影响同一个房间和隔着一堵墙算出来的n完全不同。这还没算上人体遮挡、多径效应带来的波动。从工程角度看真正靠谱的做法不是套用网上的某个固定公式而是要做两件事第一用实测来标定当前环境下的A和n值第二对原始RSSI做滤波处理先用滑动窗口把抖动压下来再套用公式计算。这一点我在后面的调参部分会展开讲。1.3 技术方案对比ESP-IDF、Arduino和蓝牙协议栈选型在选型过程中我其实对着几个方案犹豫了很久。如果你只是在电脑旁边做个简单测试Arduino BLE库比如NimBLE-Arduino也能轻松完成扫描代码量少很多。但问题在于Arduino的蓝牙栈封装太友好很多底层的扫描参数被隐藏了。比如在Arduino环境中你能控制的扫描窗口、扫描间隔参数非常有限这对RSSI采样频率和功耗控制都有影响。更关键的是这个项目后续计划要做OTA升级、要接JSON配置协议、要和已有的ESP-IDF代码模块共享任务调度如果走Arduino后面混用两套框架会非常别扭。所以最终选择了ESP-IDF原生开发。ESP-IDF从4.x开始BLE相关的API已经趋于稳定用的是基于Bluedroid和NimBLE两种底层协议栈的接口。我这次用的是Bluedroid方案它的优点是资料多、API稳定网上踩坑记录也全遇到问题好排查。NimBLE的优势在资源占用小、功耗低但资料相对少一些。如果只是做beacon扫描Bluedroid的常规扫描API完全够用了。在VS Code里可以调用指令idf.py set-target esp32 menuconfig - Component config - Bluetooth - Bluedroid创建工程时默认的蓝牙配置是关闭的记得在menuconfig里把蓝牙打开。2. 开发环境准备与工程创建2.1 VS Code和ESP-IDF Extension的安装细节工欲善其事必先利其器。这里先说一下开发环境的搭建。网上讲如何安装VS Code、如何装扩展的教程很多我不再复述所有界面步骤只点出几个容易踩坑的地方。第一装ESP-IDF Extension的时候不要在系统全局环境变量里手动去配IDF_PATH。新版扩展安装时会自动下载ESP-IDF工具链并且把路径信息放在扩展的自身配置里。如果你手动在.bashrc或者系统环境变量里加了旧版本IDF的路径反而会造成版本冲突。我在刚入手时踩过一次这个坑表现是点击扩展的“ESP-IDF: Show Examples Projects”时一直找不到IDF工具最后发现是环境变量指向了另一个旧版IDF目录扩展和命令行工具用的是两套环境。第二VSCode里跑idf.py命令时VS Code内置终端默认用的是PowerShell或bash但ESP-IDF的工具链在Windows上要使用idf_cmd_init.bat来初始化环境。新版扩展已经封装了这步骤点击底部状态栏的火花图标ESP-IDF: Build your project就可以直接编译不过在VS Code的集成终端里手动输入idf.py build偶尔会遇到“idf.py不是内部或外部命令”的情况原因是终端会话没有加载IDF的环境变量。遇到这种情况要么重启扩展要么用扩展自带的命令面板执行不要在集终端里硬拼环境变量。第三Windows上建议关闭路径中的空格问题。你的工作目录最好别叫“My Project”之类的名字ESP-IDF的构建系统在Windows下对空格路径支持有历史遗留问题尽量使用纯英文、无空格的路径比如D:\esp32_project\ble_beacon_demo。2.2 创建工程从模板到最小可编译代码创建工程时我直接从示例工程里复制了一份因为ESP-IDF官方自带了一个ble_eddystone示例路径在examples/bluetooth/bluedroid/ble/ble_eddystone。这个示例的主要功能是解析Eddystone协议的广播数据我们可以改成解析通用beacon广播。复制之后工程的核心目录结构如下ble_beacon_demo/ |-- main/ | |-- CMakeLists.txt | |-- main.c | |-- ble_scan.c | |-- ble_scan.h | |-- rssi_calc.c | |-- rssi_calc.h | -- filter.c |-- CMakeLists.txt |-- sdkconfig.defaults |-- sdkconfig -- partitions.csv其中最核心的就是main.c中建立BLE扫描任务的部分。为了让RSSI的采样尽量密集需要把扫描窗口开大一点。在ESP-IDF中扫描窗口和扫描间隔的单位是毫秒窗口设置为扫描间隔的整数倍以内如果窗口等于间隔就是连续扫描。实际的代码逻辑我放在下一节展开先记住一个关键点beacon是不断广播的广播间隔一般在100ms到1秒之间。接收端扫描窗口设得越小越容易错过某些beacon的广播周期导致RSSI采样的时间不连续。所以要做测距的话扫描窗口不要设太小我实测下来设置为200ms比较合适既不影响性能扫描到的广播包数量也够多。3. 核心代码实现与RSSI测距逻辑解析3.1 BLE扫描初始化与回调处理在ESP-IDF中做BLE扫描第一步要做协议栈初始化和注册回调。这段代码是整个beacon测距的地基。很多初学ESP-IDF蓝牙开发的人在第一步就卡住因为不太清楚初始化顺序先贴一段实际能编译通过的最小初始化代码// ble_scan.c 关键代码片段 #include esp_bt.h #include esp_bt_main.h #include esp_gap_ble_api.h static void gap_event_handler(esp_gap_ble_cb_event_t event, esp_ble_gap_cb_param_t *param) { switch (event) { case ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT: { // 参数设置完成后开始扫描 esp_ble_gap_start_scanning(0); // 0表示持续扫描 break; } case ESP_GAP_BLE_SCAN_RESULT_EVT: { esp_ble_gap_cb_param_t *scan_result (esp_ble_gap_cb_param_t *)param; if (scan_result-scan_rst.search_evt ESP_GAP_SEARCH_INQ_RES_EVT) { // 每收到一个广播包都会走到这里 handle_scan_result(scan_result-scan_rst); } break; } default: break; } } void ble_scan_init(void) { ESP_ERROR_CHECK(esp_bt_controller_mem_release(ESP_BT_MODE_CLASSIC_BT)); esp_bt_controller_config_t bt_cfg BT_CONTROLLER_INIT_CONFIG_DEFAULT(); esp_err_t ret esp_bt_controller_init(bt_cfg); if (ret ! ESP_OK) { ESP_LOGE(TAG, Bluetooth controller initialize failed: %s, esp_err_to_name(ret)); return; } ret esp_bt_controller_enable(ESP_BT_MODE_BLE); if (ret ! ESP_OK) { ESP_LOGE(TAG, Bluetooth controller enable failed: %s, esp_err_to_name(ret)); return; } ret esp_bluedroid_init(); if (ret ! ESP_OK) { ESP_LOGE(TAG, Bluedroid init failed: %s, esp_err_to_name(ret)); return; } ret esp_bluedroid_enable(); if (ret ! ESP_OK) { ESP_LOGE(TAG, Bluedroid enable failed: %s, esp_err_to_name(ret)); return; } // 注册GAP回调 ESP_ERROR_CHECK(esp_ble_gap_register_callback(gap_event_handler)); // 设置扫描参数 esp_ble_scan_params_t scan_params { .scan_type BLE_SCAN_TYPE_ACTIVE, // 主动扫描能拿到广播和扫描响应 .own_addr_type BLE_ADDR_TYPE_PUBLIC, .scan_filter_policy BLE_SCAN_FILTER_ALLOW_ALL, .scan_interval 0x50, // 200ms单位是0.625ms .scan_window 0x50, // 200ms等于间隔时表示连续扫描 .scan_duplicate BLE_SCAN_DUPLICATE_DISABLE // 关闭去重拿到所有广播包 }; esp_ble_gap_set_scan_params(scan_params); }有几个细节值得注意。一是esp_bt_controller_mem_release(ESP_BT_MODE_CLASSIC_BT)这行因为只用BLE不用经典蓝牙提前释放掉经典蓝牙占用的内存让BLE有更多内存可用这在内存紧张的ESP32上很关键。二是监控扫描参数的宏定义scan_interval和scan_window不是毫秒值而是0.625ms的倍数。0x50换算成毫秒就是0x50 * 0.625 50 * 0.625 31.25ms吗等等0x50是十六进制8080 * 0.625 50ms这样计算才对。我当时用0x50设置的其实是50ms的扫描窗口不是200ms。用200ms的话应该是0x140也就是320 * 0.625 200ms。这一点特别容易搞错刚开始用0x50发现扫描次数比较少后来改成0x140后数据密度明显上来了。这里必须严谨十六进制的0x50是8080乘0.625等于50ms。第三是scan_duplicate参数设置为BLE_SCAN_DUPLICATE_DISABLE这个也容易被忽略。默认情况下控制器会对相同的广播地址和相同的数据内容做去重在很多BLE应用里这是合理的但做RSSI测距时我们希望拿到每个周期内尽量多的广播包样本用来做统计滤波。关闭去重之后同一个beacon在一段时间内出现的次数会明显增加。不过代价是系统负载变大如果场景里beacon特别多建议设置去重但保存一定时间的RSSI历史折中处理。初始化完BLE之后要记得在调度器里跑一个任务否则整个蓝牙栈的事件无法正常回调。最简单的方式是调用ESP_BLE_GAP_CONFIG_STATIC_RAND_ADDR?不需要那么复杂用esp_bluedroid_enable之后事件是在底层任务里分发的不需要额外创建任务。但是main函数里如果直接退出app_main系统可能会因为任务调度问题导致蓝牙异常一般做法是创建一个循环任务常驻或者直接调用vTaskDelay挂起。3.2 过滤beacon并提取RSSI数据当扫描回调触发我们拿到的数据结构是esp_ble_gap_cb_param_t里的scan_rst字段。它包含广播地址、RSSI、广播数据长度和广播数据本身。beacon数据通常封装在广播包的Manufacturer Specific Data字段里。iBeacon格式是这样组织的2字节Company ID0x004C代表Apple2字节Type0x0215表示iBeacon16字节UUID2字节Major2字节Minor1字节TX Power距离1米处的参考RSSI在代码里判断是不是我要找的beacon我一般是先检查广播数据长度再检查特定偏移位置的数值是否符合iBeacon或者Eddystone的结构。下面的代码展示了如何从广播数据中提取iBeacon信息// 判断是否是iBeacon广播 bool parse_ibeacon_data(uint8_t *adv_data, uint8_t adv_len, ibeacon_info_t *info) { if (adv_data NULL || info NULL || adv_len 25) { return false; } // 跳过第一个AD结构检查Manufacturer Specific Data // 格式: [length][type][company_id][type][uuid...] uint8_t index 0; if (index adv_len) { uint8_t field_len adv_data[index]; // 第一个AD结构的长度 uint8_t field_type adv_data[index 1]; // AD类型 if ((field_type 0xFF) (field_len 21)) { // 0xFF是Manufacturer Specific // 检查iBeacon标识 if (adv_data[index 2] 0x4C adv_data[index 3] 0x00 adv_data[index 4] 0x02 adv_data[index 5] 0x15) { memcpy(info-uuid, adv_data[index 6], 16); info-major (adv_data[index 22] 8) | adv_data[index 23]; info-minor (adv_data[index 24] 8) | adv_data[index 25]; info-tx_power (int8_t)adv_data[index 26]; return true; } } } return false; }我一开始用的判断方式是直接对比MAC地址因为这个项目里beacon数量不多MAC地址是固定的。但实际开发中发现有些便宜的beacon设备支持手机App修改MAC地址或者开启随机地址功能导致MAC地址在重启后会变化。所以后来改成了通过UUID和Major/Minor来过滤目标beacon这样即使MAC变了还是能识别出是我们自己的beacon。RSSI的处理也很关键。扫描结果里的rssi值是一个带符号的整数单位是dBm比如-76表示信号强度为-76dBm。不同的beacon因为发射功率和天线设计不同相同距离下的RSSI差异可能很大。所以在做距离估算之前需要先对不同beacon分别标定参数。还有一个细节esp_ble_gap_cb_param_t的scan_rst里有个字段叫rssi但它只是该广播包瞬间的接收信号强度。如果同一个beacon在一秒钟内出现10次就用这10个RSSI值算一个平均值这样比直接用单次值稳定得多。3.3 RSSI滤波与距离换算的完整实现关于RSSI滤波我在项目中尝试了两种方法滑动窗口平均值滤波和一阶低通滤波。滑动窗口滤波的逻辑比较简单维护一个环形缓冲区窗口大小设为10每来一个新的RSSI值就替换掉最旧的值然后计算窗口内所有数的平均值。这个方法的优点是实现简单缺点是如果移动速度比较快算出的距离变化有明显滞后。窗口越大越平滑但响应越慢。一阶低通滤波则是这样typedef struct { float filtered_value; float alpha; } lowpass_filter_t; void lowpass_filter_init(lowpass_filter_t *filter, float alpha) { filter-filtered_value 0.0f; filter-alpha alpha; // alpha建议0.3~0.5 } float lowpass_filter_update(lowpass_filter_t *filter, float raw_value) { if (filter-filtered_value 0.0f) { filter-filtered_value raw_value; } else { filter-filtered_value filter-alpha * raw_value (1 - filter-alpha) * filter-filtered_value; } return filter-filtered_value; }alpha值越大对新数据的响应越快但波动也越大。我实测下来alpha取0.4左右比较合适在平滑性和响应速度之间能取得一个较好的平衡。滤波完成之后套用对数距离路径损耗模型float rssi_to_distance(float rssi, float tx_power, float n) { // tx_power 就是公式里的A1米处的参考RSSI // n 是环境衰减因子 if (rssi 0) { return -1.0f; // 无效信号强度 } return powf(10.0f, (tx_power - rssi) / (10.0f * n)); }别小看这个函数A和n的取值会直接导致距离计算结果的巨大差异。我举个例子测得的RSSI为-70dBm如果A取-60、n取2计算结果是10^((-6070)/(102)) 10^0.5 3.16米。如果n取3结果就是10^((-6070)/(103)) 10^0.333 2.15米。同样一个RSSI值n值从2变到3估算结果差了整整1米。所以这个模块的核心不是代码本身而是标定过程。后面的实操部分我会专门讲怎么在现场把A和n标定出来。4. 实测校准与调参过程4.1 现场标定方案采集RSSI样本并拟合参数标定A和n最直接的方法是在实际部署环境里测一组数据。把beacon放在固定位置然后拿着ESP32依次在1米、2米、3米、5米、8米处停留每个点记录30秒的RSSI值并取平均值。这样会得到一张表距离米实测RSSI均值dBm1-592-703-765-838-91接着就是反推参数。从1米处的RSSI均值可以直接得到A的值也就是-59dBm。n值则需要用其他距离点的数据反推。根据公式可以变换出n (A - RSSI) / (10 * log10(d))拿2米那组数据算出来n (-59 - (-70)) / (10 * log10(2)) 11 / 3.01 ≈ 3.65。再用3米那组数据算一下n 17 / (10 * 0.477) ≈ 3.56。两个n值比较接近说明当前环境的衰减特性比较一致。取平均值n 3.6作为最终参数。如果不方便手动计算也可以把多组数据放到电子表格里做线性拟合。因为公式可以改写成RSSI -10 * n * log10(d) A把10*log10(d)作为自变量xRSSI作为因变量y线性回归的斜率就是-10n截距就是A。这样做会更精确尤其是数据点多的时候。我当时在现场遇到的最大干扰来自旁边不时的行人走动和金属货架。刚测完1米处的均值还挺稳定到8米处就明显感觉RSSI波动变大一会儿-85一会儿-95。这种波动正是室内环境多径效应的典型表现信号在墙壁、地面、货架之间来回反射叠加后形成干涉。所以每一个距离点的采样时间不能太短至少30秒以上才能把这种随机波动平均掉。4.2 实测算例ESP32作为接收端的完整实测记录这里放一次完整测量的日志片段。为了方便观察我把每个beacon的距离计算结果周期性地打印出来。日志输出大概长这样I (5650) ble_beacon: [BLE] Scan result, RSSI: -71 dBm, MAC: 24:0a:c4:00:12:34 I (5660) ble_beacon: [INFO] RSSI after filter: -70.3 I (5660) ble_beacon: [INFO] Distance estimate: 2.68m我在室内走廊明明标的是3米实测算出来大概2.68米这个偏差在接受范围内。但如果只看单次RSSI有时算出来只有1.8米有时又飙到4米波动非常大。这正是因为RSSI的单次采样噪声太大必须依赖滤波后的结果。为了观测周跳现象我做过一个对比实验同一位置同一距离用窗口大小为5的滑动平均值滤波距离估算值在2.3米到3.1米之间跳动窗口加大到20后距离值稳定在2.7米到2.9米。窗口越大越稳定但实时性变差测试者在走动时距离变化响应的滞后也越明显。这个取舍要根据应用场景来如果是静止测距参考窗口大一点无所谓如果是运动姿态估计窗口就不能太大。在实际工程里我还加了距离置信度判定。如果连续几次计算出的距离结果在某个阈值范围内跳变就认为当前估算值可信如果持续跳变超过1.5米就认为当前区域多径干扰太大直接丢弃这组数据或者切换到其他beacon的测量结果。4.3 不同距离段的误差统计与改进方向把实测数据整理成表格能发现一个明显的规律距离越远估算误差越大。实际距离米估算中位数米误差%备注11.1212波动较小22.189比较稳定32.864.7表现最好54.519.8开始有波动86.8015明显低估这里有个很有意思的现象8米处的估算值普遍低于实际值。原因是RSSI在较远的距离上受多径效应影响更严重有时候反射波叠加让信号强度反而变强导致公式算出来的距离偏小。这种系统性偏差很难单纯通过调整A和n来完全修正。一个可行的改进方向是分段标定比如在3米内用一组参数3米到8米用另一组参数分段逼近。更进一步的方案是做指纹库。预先在场地里选好多个参考点每个点记录一组beacon的RSSI向量之后通过比对当前RSSI向量和指纹库中的记录来判断位置。这种方法在复杂室内环境下的精度比单纯测距高一个量级但需要前期做大量数据采集工作。如果后续项目有时间我打算把指纹库方案也纳入升级计划毕竟beacon测距只是定位系统的一个中间环节。5. 常见问题与排查技巧实录5.1 扫描不到beacon三步排查法beacon扫描不到是这个项目里大家问得最多的一个问题。遇到这种情况不用慌按照下面三步排查就好。第一步先确认beacon是不是真的在广播。用手机安装一个BLE扫描工具nRF Connect或LightBlue扫一下如果手机也扫不到说明beacon没在工作检查beacon的电池或者广播配置。如果手机能扫到但ESP32扫不到进入第二步。第二步检查ESP-IDF的menuconfig蓝牙配置。很多人在创建新工程时忘了开启BLE。在menuconfig里进入Component config - Bluetooth把Bluetooth设置为Enabled同时把Bluedroid设置为Enabled。保存退出之后重新编译烧录。这里最经典的报错是ESP_ERROR_CHECK failed: esp_err_t 0xffffffff (ESP_FAIL) at 0x400d5b0c这个报错往往就是蓝牙没有正确开启。第三步检查代码里的扫描参数。scan_interval和scan_window的设置如果太极端也会导致扫描不到数据。比如把scan_window设成小于50ms很可能频繁错过beacon的广播周期。beacon广播间隔一般是100ms到200ms扫描窗口至少要覆盖一个广播周期的一半概率才行。我自己的经验值是扫描间隔设200ms扫描窗口也设200ms也就是0x140等于连续扫描。5.2 RSSI值波动剧烈如何处理RSSI波动是算距离的人必须接受的一个现实它的随机性比很多人预想的要大得多。同一点上的RSSI标准差可能达到5到6dBm换算成距离就是近1米的偏差。所以不要去想着消除波动而是要想办法降低波动对最终结果的影响。我常用的方案是两级滤波。第一级在采集层做滑动窗口平均窗口大小10到20第二级在距离计算层再做一次低通滤波把计算出的距离值用一阶低通过滤一遍。这样做下来最终的距离输出曲线会平滑很多人站在固定位置不动时显示的距离基本能稳定在±0.5米的范围内。另外一点是尽量使用定向天线或者调整ESP32的天线方向让主天线朝向beacon方向。ESP32的PCB天线是倒F型外部环境对它的影响很大如果ESP32紧贴在金属表面上RSSI会被显著拉低。这个在布板或固定设备时就要考虑最好让天线区域悬空周围不要有大块金属和人体紧贴。5.3 VS Code和ESP-IDF常见的编译/烧录问题编译有问题也要在这里集中整理一下。老是在VS Code扩展里碰到“The path for ESP-IDF is not valid: /tools/idf.py not found”这个错误在Windows上尤其常见。解决思路是去扩展设置里确认ESP-IDF工具路径是否配置到正确的安装目录。比如扩展安装在D:\Espressif你要确认idf.py实际路径是不是D:\Espressif\frameworks\esp-idf-v5.1\tools\idf.py。如果不确定可以直接在文件系统搜索idf.py然后手动把路径指过去。还需要提醒一个坑在Windows中如果使用ESP-IDF 5.x版本在烧录时偶尔会报串口打不开或者Permission denied。多半不是ESP32硬件问题而是USB转串口芯片的驱动没装好。市面上常见的ESP32开发板用的串口芯片有两种CP2102和CH340。CP2102用官方驱动基本没问题CH340在Windows上如果装了兼容驱动很容易出现识别但无法打开的情况。最好的方式是去芯片厂商官网下载对应版本驱动不要用Windows自动更新的驱动。如果是烧录到一半卡住不动很大的可能是开发板上的EN按键被按住或者自动下载电路供电不足。把波特率调低到115200再试如果还是卡住短按一下EN键强制复位再烧录。6. 经验总结与后续扩展思路beacon测距这个功能从原理到实际落地难度不在代码而在参数标定和抗干扰处理。只要认真做了现场标定、合理设置滤波策略ESP32配合ESP-IDF很容易实现2到5米范围内的m级精度。我在实际测试中还发现一个值得后续尝试的优化方向多beacon数据融合。单一beacon测距波动大但如果有三个以上的beacon同时可见分别测算距离后可以用三边定位法估算出接收端的二维位置。这样即使在某个方向上测距误差稍大其余方向的约束也能把整体精度拉回来。ESP32的BLE扫描本身就能同时记录多个beacon的RSSI数据所以实现三边定位只是算法层面的工作量硬件不需要改动。另外如果要做成低功耗产品可以把扫描任务改成周期性唤醒模式比如每隔500ms扫描200ms其他时间进入modem sleep。ESP32的功耗随着扫描密度和CPU唤醒频率的不同差距能拉到很大。按现在的代码连续扫描时电流大概在80mA左右改成占空比扫描后可以降到20mA以内。这个就要结合具体产品形态来权衡了。最后贴几个我实测过的小建议标定环境要和实际使用环境尽量一致差别大的情况下A和n值全部要重新标定不同beacon之间发射功率差异明显同一个工程里混用不同品牌的beacon时要分别标定参数关闭蓝牙扫描去重是提高rssi采样密度的关键但会增加内存开销beacon数量特别多的时候慎用在程序里把原始RSSI和滤波后的RSSI同时打出来调试的时候能省很多力这篇实战记录基本覆盖了从零到能用的所有环节希望正在做ESP32蓝牙beacon测距的朋友能少走一些弯路。如果有其他更好的RSSI抗干扰思路欢迎一起交流。