1. 项目概述与核心目标
最近拿到了一块合宙的Beetle ESP32-C3开发板，这板子小巧得让人爱不释手。ESP32-C3这颗芯片，作为乐鑫在RISC-V架构上的力作，集成了Wi-Fi和蓝牙5.0，性价比相当突出。我手头这块板子自带了一根PCB天线，这让我萌生了一个很实际的想法：测测它的蓝牙5.0传输距离到底怎么样。
对于物联网设备，尤其是那些需要无线通信的传感器节点、遥控器或者穿戴设备，通信距离和稳定性是硬指标。官方数据往往是在理想环境下测得的，实际应用场景千差万别，墙壁、干扰、天线设计都会对结果产生巨大影响。所以，这次测试不追求实验室级别的精准，而是要模拟几个常见的日常和轻度工业环境，看看这块小巧的Beetle ESP32-C3在实际使用中，其蓝牙信号能“跑”多远、有多稳。这不仅能验证板子的基础性能，更能为后续的真实项目选型和天线设计提供一手参考。
2. 测试环境与方案设计
2.1 硬件与软件准备
测试的主角自然是Beetle ESP32-C3开发板。它核心的ESP32-C3芯片支持蓝牙5.0，包含了BLE（低功耗蓝牙）和经典蓝牙。本次测试聚焦于BLE，因为它在物联网领域应用更广。板载的PCB天线是测试的基础，为了对比，我还准备了一根外接的2.4GHz胶棒天线（通过IPEX接口连接），看看外置天线能带来多大提升。
软件层面，我选择了Arduino IDE进行开发。乐鑫官方对Arduino的支持已经非常成熟，库函数丰富，开发效率高。主要用到的库是BLEDevice、BLEUtils、BLEServer和BLEAdvertising，这些库封装了蓝牙协议栈的底层细节，让我们能专注于应用逻辑。
为了测量距离，我需要一个中央设备（Central）来扫描和连接Beetle ESP32-C3（作为外围设备Peripheral）。最方便的中心设备就是智能手机。我使用了一部支持蓝牙5.0的安卓手机，并安装了nRF Connect这款强大的BLE调试工具。它可以扫描设备、查看服务（Service）、特征值（Characteristic），并能进行数据读写和通知（Notify）测试，功能非常全面。
2.2 测试固件设计思路
我的测试固件主要实现两个核心功能，模拟一个典型的传感器节点：
- 广播与连接：让ESP32-C3作为一个BLE外围设备，持续广播一个包含设备名称（如“Beetle_Test”）的信号，等待手机连接。
- 数据通信测试：建立连接后，ESP32-C3需要提供一个自定义的BLE服务（Service），其中包含一个可读、可写、可通知（Notify）的特征值（Characteristic）。手机端可以通过nRF Connect向这个特征值写入数据（如下发指令），ESP32-C3收到后原样返回，并通过通知（Notify）功能主动向手机发送模拟的传感器数据（如一个不断递增的计数器）。
这样设计的好处是能同时测试连接稳定性和双向数据传输的可靠性。单纯的广播信号强度（RSSI）扫描只能反映信号强弱，而建立连接并保持数据流才能真正模拟实际应用场景，暴露潜在的问题，比如在信号边缘地带的数据包丢失率。
2.3 测试场景与距离标定
我规划了三个有代表性的测试场景：
- 无障碍开阔环境：选择一段空旷的走廊或室外无遮挡场地，使用卷尺进行距离标定。这是测试理论最大距离的场景。
- 室内隔墙环境：在办公室或家庭环境中，测试信号穿透一堵普通砖墙或轻质隔断墙后的衰减情况。这是智能家居设备最常遇到的场景。
- 复杂干扰环境：在Wi-Fi路由器密集、微波炉等2.4GHz频段设备较多的区域进行测试，考察抗干扰能力。
距离记录点以连接断开或数据通信连续失败（例如，连续10次数据包丢失或响应超时）作为有效通信距离的边界。同时，我会用nRF Connect记录关键距离点的接收信号强度指示（RSSI）值，这是一个负的dBm值，其绝对值越小（如-50dBm）代表信号越强，绝对值越大（如-90dBm）代表信号越弱。
3. 核心代码实现与解析
3.1 BLE服务与特征值定义
在Arduino中，首先需要初始化BLE设备并设置广播参数。
#include <BLEDevice.h> #include <BLEServer.h> #include <BLEUtils.h> #include <BLE2902.h> // 定义服务UUID和特征值UUID，可以使用随机生成的UUID，避免与标准服务冲突 #define SERVICE_UUID "4fafc201-1fb5-459e-8fcc-c5c9c331914b" #define CHARACTERISTIC_UUID "beb5483e-36e1-4688-b7f5-ea07361b26a8" BLEServer *pServer; BLEService *pService; BLECharacteristic *pCharacteristic; bool deviceConnected = false; bool oldDeviceConnected = false; // 用于模拟传感器数据的变量 uint32_t sensorValue = 0; // 服务器回调类，处理连接事件 class MyServerCallbacks: public BLEServerCallbacks { void onConnect(BLEServer* pServer) { deviceConnected = true; Serial.println("设备已连接"); }; void onDisconnect(BLEServer* pServer) { deviceConnected = false; Serial.println("设备已断开连接"); // 断开后重新开始广播，便于重连 pServer->getAdvertising()->start(); } }; // 特征值回调类，处理手机端发来的写入请求 class MyCharacteristicCallbacks: public BLECharacteristicCallbacks { void onWrite(BLECharacteristic *pCharacteristic) { std::string rxValue = pCharacteristic->getValue(); if (rxValue.length() > 0) { Serial.print("收到数据: "); for (int i = 0; i < rxValue.length(); i++) Serial.print(rxValue[i]); Serial.println(); // 简单地将收到的数据回传 pCharacteristic->setValue(rxValue); pCharacteristic->notify(); } } };这段代码搭建了BLE通信的骨架。MyServerCallbacks负责在手机连接或断开时更新状态标志。MyCharacteristicCallbacks则允许我们在手机向特征值写入数据时立即做出响应，这里实现了简单的“回声”功能。
3.2 初始化与广播设置
在setup()函数中，我们需要完成BLE的初始化和配置。
void setup() { Serial.begin(115200); Serial.println("启动Beetle ESP32-C3 BLE距离测试..."); // 创建BLE设备，名称将出现在手机的扫描列表中 BLEDevice::init("Beetle_Test_Distance"); // 创建BLE服务器 pServer = BLEDevice::createServer(); pServer->setCallbacks(new MyServerCallbacks()); // 创建BLE服务 pService = pServer->createService(SERVICE_UUID); // 创建特征值，属性为：读、写、通知 pCharacteristic = pService->createCharacteristic( CHARACTERISTIC_UUID, BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_WRITE | BLECharacteristic::PROPERTY_NOTIFY ); // 为特征值添加回调 pCharacteristic->setCallbacks(new MyCharacteristicCallbacks()); // 添加一个描述符，用于启用客户端（手机）的通知功能 pCharacteristic->addDescriptor(new BLE2902()); // 启动服务 pService->start(); // 开始广播 BLEAdvertising *pAdvertising = BLEDevice::getAdvertising(); pAdvertising->addServiceUUID(SERVICE_UUID); // 在广播数据中包含服务UUID pAdvertising->setScanResponse(true); pAdvertising->setMinPreferred(0x06); // 这些参数影响连接间隔和扫描响应，有助于提高连接速度 pAdvertising->setMaxPreferred(0x12); BLEDevice::startAdvertising(); Serial.println("等待客户端连接..."); }这里有几个关键点：
BLEDevice::init("Beetle_Test_Distance")：设置设备名称，这是手机扫描时看到的主要标识。- 特征值属性：
PROPERTY_READ | PROPERTY_WRITE | PROPERTY_NOTIFY定义了该特征值支持的所有操作。 BLE2902()描述符：对于支持通知（Notify）或指示（Indicate）的特征值，这个描述符是必须的，客户端通过它来启用通知。- 广播参数
setMinPreferred和setMaxPreferred：它们设置的是“首选最小/最大连接间隔”的提示值，单位是1.25ms。这里设置的值（0x06=7.5ms, 0x12=22.5ms）偏向于较快的连接速度，在测试时响应更及时。在实际低功耗应用中，这个值会设得更大以节省电量。
3.3 主循环与数据模拟
在loop()函数中，我们主要做两件事：管理连接状态和模拟发送传感器数据。
void loop() { // 处理连接状态变化 if (deviceConnected) { // 模拟传感器数据，每秒递增一次并通过通知发送 sensorValue++; char txString[8]; sprintf(txString, "%d", sensorValue); pCharacteristic->setValue(txString); pCharacteristic->notify(); Serial.printf("发送通知数据: %s\n", txString); delay(1000); // 每秒发送一次 } // 处理断开重连逻辑 if (!deviceConnected && oldDeviceConnected) { delay(500); // 给蓝牙栈一个处理断开的时间 oldDeviceConnected = deviceConnected; } if (deviceConnected && !oldDeviceConnected) { oldDeviceConnected = deviceConnected; } }这里使用notify()方法向已订阅通知的客户端发送数据。与“写”操作不同，“通知”是由服务器（ESP32-C3）主动发起的，非常适合周期性上报传感器数据的场景。delay(1000)控制着发送频率，在实际测试中，为了更密集地测试通信稳定性，可以适当缩短这个时间，比如改为200ms。
注意：频繁发送通知（间隔很短）会快速消耗电量，并可能因为数据吞吐量超过BLE连接的数据速率限制而导致丢包。在极限距离测试时，过快的发送速率可能会让连接显得不稳定。我的经验是，对于距离测试，500ms-1000ms的间隔是一个比较平衡的选择。
4. 实测过程与数据分析
4.1 测试一：无障碍开阔环境
我选择了一条长约80米的空旷地下车库通道作为测试场地。将Beetle ESP32-C3（使用板载PCB天线）固定在起点，手持手机（运行nRF Connect）缓慢向远处移动。
- 连接建立：在30米范围内，手机能瞬间扫描到“Beetle_Test_Distance”设备，信号强度（RSSI）在-45dBm到-60dBm之间波动，连接非常迅速稳定。
- 数据传输：在50米处，RSSI衰减至-75dBm左右，但双向数据通信（手机写入指令，设备返回并通知数据）依然流畅，没有出现丢包或延迟显著增大的情况。
- 极限距离：继续移动到大约65米时，nRF Connect上显示的RSSI值在-85dBm到-92dBm之间剧烈跳动。此时，数据通信开始出现不稳定：偶尔会发生通知数据接收超时，或者手机写入指令后需要等待1-2秒才能收到回声。当距离达到70米左右时，连接彻底断开，且无法自动重连。
切换到外接胶棒天线后，结果有显著改善。在同样的70米位置，RSSI值约为-80dBm，数据通信虽有轻微延迟但基本完整。连接一直保持到大约85米才完全断开。外置天线带来了约15-20米的有效距离提升。
4.2 测试二：室内隔墙环境
测试环境是我的公寓，设备放在客厅，我拿着手机走向卧室（隔一堵承重砖墙）和卫生间（隔两堵墙）。
- 一堵砖墙（直线距离约8米）：使用板载天线时，RSSI约为-70dBm，数据通信完全正常，感知不到任何延迟。这印证了BLE在典型智能家居场景（单个房间内）的可靠性是足够的。
- 两堵砖墙（非直线，有转角，距离约12米）：信号衰减非常明显，RSSI在-85dBm到-95dBm之间波动。数据通信时断时续，大约有30%的数据包会丢失。连接状态也变得不稳定，偶尔会自动断开又重连。使用外置天线后，情况改善为RSSI约-78dBm，丢包率下降到5%以下，连接基本稳定。
这个测试说明，墙体是2.4GHz信号的主要杀手，尤其是承重墙内的钢筋对信号屏蔽作用很强。对于全屋覆盖的应用，可能需要部署多个中继节点或选用穿墙能力更强的天线方案。
4.3 测试三：复杂干扰环境
我将设备放在办公室的工位上，周围有超过10个活跃的Wi-Fi路由器和大量手机、笔记本电脑。
- 近距离（3米内）：尽管频谱拥挤，但由于信号强，连接和数据传输未受明显影响。
- 中距离（约15米，中间有多人走动和设备）：可以观察到RSSI值波动幅度比在开阔地要大得多（例如在-65dBm到-80dBm之间快速变化）。数据传输的延迟变得不规律，偶尔会出现一个数据包延迟高达1-2秒的情况，但很快又恢复正常。这体现了蓝牙的跳频扩频（FHSS）技术在一定程度上抵抗干扰的能力，但在强干扰下，性能仍有下降。
- 对比测试：我尝试关闭了设备周围的几个Wi-Fi路由器，在同样的中距离上，RSSI波动范围和通信延迟都有肉眼可见的改善。
5. 问题排查与优化经验
在实际测试和以往项目中，围绕ESP32-C3蓝牙距离和稳定性，我遇到过不少典型问题，这里总结一下排查思路和优化技巧。
5.1 常见问题速查表
| 问题现象 | 可能原因 | 排查与解决思路 |
|---|---|---|
| 手机根本扫描不到设备 | 1. 程序未正确启动广播。 2. 设备名称或广播数据过长。 3. 硬件天线虚焊或损坏。 | 1. 检查串口日志，确认startAdvertising()已执行。2. 确保设备名称符合规范，不宜过长。尝试使用简单的广播数据。 3. 检查PCB天线区域有无刮蹭、器件有无虚焊。可尝试外接天线对比。 |
| 连接频繁断开 | 1. 信号强度太弱（RSSI > -90dBm）。 2. 周围2.4GHz频段干扰严重。 3. 电源不稳定，导致芯片重启。 | 1. 缩短距离或改善天线环境。监控RSSI值，确保在稳定阈值内（通常>-85dBm）。 2. 更换信道或远离干扰源（如Wi-Fi路由器、微波炉）。 3. 使用示波器检查供电电压波形，确保在3.3V附近无大幅跌落。Beetle ESP32-C3通过USB供电一般没问题，但电池供电时需注意。 |
| 数据通信丢包严重 | 1. 连接参数（连接间隔、延迟）设置不当。 2. 数据发送速率超过BLE链路容量。 3. 特征值操作（如notify）过于频繁，未处理确认。 | 1. 在中心设备（手机App或代码）侧尝试优化连接参数，缩短连接间隔（但会增加功耗）。 2. 降低数据发送频率。BLE的理论吞吐量有限，需根据实际调整。 3. 确保通知发送有合理的间隔，并处理 onNotify等回调确认。 |
| 通信距离远低于预期 | 1. 天线匹配电路不佳。 2. 板子布局或外壳对天线产生屏蔽。 3. 输出功率（Tx Power）设置过低。 | 1. 这是最常见的原因。检查ESP32-C3的RF端口到天线之间的π型匹配电路（通常由电感和电容组成），元器件的值必须严格按照芯片手册和天线规格书设计。 2. 避免在天线附近放置金属物体或大面积铺铜。使用塑料外壳而非金属外壳。 3. 在代码中尝试调整发射功率： esp_ble_tx_power_set(ESP_BLE_PWR_TYPE_DEFAULT, ESP_PWR_LVL_P9);（P9是最高功率级别之一）。 |
5.2 天线设计与匹配的深度解析
对于无线性能，天线及其匹配电路是决定性的因素之一，其重要性甚至超过芯片本身。ESP32-C3的射频输出引脚阻抗并非标准的50欧姆，而天线（无论是PCB天线还是外接天线）的输入阻抗也未必是50欧姆。这就需要中间的匹配电路来完成阻抗变换，实现最大功率传输。
理解匹配电路：你可以把射频信号传输想象成敲鼓。芯片是鼓锤，天线是鼓面。匹配电路就是鼓锤和鼓面之间那根有弹性的鼓柄。如果鼓柄的硬度和长度（即阻抗）不合适，鼓锤的力量就无法有效传递给鼓面，大部分能量会被反弹回来（信号反射），导致敲不响（传输距离近）。匹配电路（通常是π型或L型，由电感和电容组成）的作用就是调整这个“鼓柄”的特性，让鼓锤的力量能完全被鼓面吸收。
如何优化：
- 参考设计：首要且必须遵循的是乐鑫官方提供的ESP32-C3参考设计原理图和PCB布局。官方设计已经计算好了基础的匹配电路参数。
- 矢量网络分析仪（VNA）：对于性能要求苛刻的产品，必须使用VNA对天线端口进行测量。通过观察史密斯圆图（Smith Chart），可以精确调整匹配电路中电感和电容的值，使阻抗点落在50欧姆附近，从而获得最小的回波损耗（S11参数），这意味着最多的能量被辐射出去，而不是反射回来。
- PCB布局禁忌：天线区域下方所有层必须净空（禁止走线和铺铜）；天线应尽可能放置在板边，周围远离金属器件和线缆；匹配电路应尽可能靠近芯片的RF引脚，走线短而粗。
板载PCB天线 vs 外接天线：
- PCB天线：成本低，体积小，无需组装。但性能受PCB板材、厚度、周围环境影响大，增益通常较低（如-1dBi至2dBi）。适合对尺寸和成本敏感，且通信距离要求不高的场景。
- 外接天线（如胶棒、陶瓷天线）：性能通常更优、更稳定，增益高（如3dBi以上）。IPEX接口提供了灵活性。但会增加BOM成本和组装工序。在本次测试中，外接天线带来了明显的距离提升。
5.3 软件层面的微调
除了硬件，软件配置也能在一定范围内优化性能：
- 广播参数：
BLEAdvertising对象的setMinPreferred和setMaxPreferred不仅影响连接速度，也间接影响设备被发现的概率和功耗。更短的广播间隔会让设备更容易被扫描到，但功耗更高。 - 连接参数：连接建立后，中央设备（手机）和外设（ESP32-C3）会协商一组连接参数，包括连接间隔、从机延迟和监督超时。这些参数在手机端（或作为中央设备的ESP32）往往有更大的决定权。更短的连接间隔意味着更频繁的数据交换机会，实时性更好但功耗更高。在nRF Connect中，连接后可以在“Connection Parameters”界面请求修改这些参数。
- 发射功率：如前面提到的，可以通过
esp_ble_tx_power_set()函数增加发射功率。但要注意，这会线性增加功耗，并且可能受到当地无线电法规的限制。
6. 实测总结与项目选型建议
经过这一轮实测，对Beetle ESP32-C3的蓝牙5.0性能有了更立体的认识。在理想开阔环境下，板载PCB天线能提供约60-70米的稳定通信距离，足以满足大多数庭院、仓库的覆盖需求。换上外置天线后，距离可延伸至80米以上。在室内环境中，单堵墙的阻隔影响可控，但多墙穿透能力衰减显著，需要合理规划节点位置。
对于天线选择，我的建议是：如果产品尺寸限制极严或成本压力大，且通信距离在10米以内（如智能手环、近场遥控），精心设计的PCB天线是可行方案。但如果对距离、稳定性有要求，或者环境复杂，强烈建议使用外置天线并预留IPEX接口，这为后期性能调整和应对复杂环境留下了宝贵余地。
在复杂电磁环境下，蓝牙5.0的跳频机制展现了一定的抗干扰能力，但并非免疫。在Wi-Fi密集区，通信延迟和波动会增加。因此，在关键数据传输上，加入简单的应用层重传或确认机制是明智的。
最后，关于功耗，本次测试未做精细测量，但BLE在连接间隔设置合理、深度睡眠利用充分的情况下，其低功耗优势是毋庸置疑的。这对于电池供电的传感器节点至关重要。在实际项目中，需要根据数据上报频率、实时性要求来权衡连接参数，找到功耗和性能的最佳平衡点。这块小小的Beetle ESP32-C3，凭借其RISC-V内核、蓝牙5.0和极具竞争力的价格，在需要无线连接的轻量级物联网应用中，确实是一个非常有吸引力的选择。
