测试DB确实变好了，能读取到设备的addr的距离也变远了，但是能够连接上主机的距离没有变化，一旦超出原来的那个距离，虽然能读到设备的MAC地址，但是连接不上,会报Reason:3e的错误

GPIOA_ModeCfg(GPIO_Pin_4|GPIO_Pin_5,GPIO_ModeOut_PP_5mA);

pa_config.txEnableGPIO =(uint32_t)&R32_PA_OUT;

pa_config.txDisableGPIO =(uint32_t)&R32_PA_CLR;

pa_config.tx_pin = GPIO_Pin_4;

pa_config.rxEnableGPIO =(uint32_t)&R32_PA_OUT;

pa_config.rxDisableGPIO =(uint32_t)&R32_PA_CLR;

pa_config.rx_pin = GPIO_Pin_5;

BLE_PAControlInit(&pa_config);

应该说是连接上了之后马上断开，但是Addr又是正确的，Reason：3e一般是什么情况才会导致的，后续的连接事件收不到吗

你好，方便提供一份硬件我们看下。

3e是连接未成功建立，在使用最新官方代码的情况下，可能与硬件有关系。

可以针对性的测试一下不控制PA是否可以搜索到微弱的信号以及是否可以连接成功，目的是确定是否为PA芯片的影响。

近距离是可以连接成功的，超出一定距离之后就一直显示3e了

刚开始全部拉低的时候，不控制PA也是能连接上的，用官方代码控制PA后，确实有信号增强的情况，比之前距离更远一点点，但更远的地方就一直报3e了

可以确定一下需要的距离是多远，PA的硬件绘制对距离影响很大。

如果是近距离连接无问题，远距离连接会很困难，则可能是距离过远导致蓝牙连接包交互困难丢包严重。一般加上PA后可以达到200m的。

好的谢谢，还想多问一下，BLE从机例程的功耗是会比BLE MESH Vendor例程的功耗大一些吗，做的功能一样，从机例程定时通知主机的功耗是7mA左右，但是mesh vendor例程定时用vendor_model_srv_send发送给配网者功耗到了17mA

把宏CONFIG_BLE_MESH_RELAY改为0之后 功耗也没有什么变化，节点想做到只发不收来降低功耗，但是看例程低功耗节点需要绑定朋友节点，想做到图示说的效果

相同的唤醒间隔（在BLE从机例程中是连接间隔决定，在蓝牙mesh的低功耗节点例程中是CONFIG_MESH_LPN_POLLINTERVAL_DEF决定），蓝牙mesh的功耗是比BLE要高的，因为蓝牙mesh每发一包是在三个信道上都收/发一遍；BLE有跳频机制，某一时刻只要在一个信道收/发包即可。

CONFIG_BLE_MESH_RELAY这个宏是决定了长供电节点（一般非mesh低功耗节点的设备都要做长供电）是否启用包转发，与是否进入低功耗无关。

mesh协议中提供了低功耗节点+朋友节点的解决方案来实现低功耗节点的双向通信。

如果您不想增加朋友节点，且只做发往中心节点汇总的单向通信，那么可以不使用低功耗节点例程，使用一般节点即adv_vendor例程+启用HAL_SLEEP休眠的方案实现。注意①每隔一段时间（比如说启用一个20h/次的TMOS事件）需要开启一段时间的接收扫描（bt_mesh_scan_enable/bt_mesh_scan_disable）以保持网络同步；②配网过程中不可以进入休眠，可以在CH58X_LowPower函数中判断是否已成功配网，是则允许继续执行休眠，否则直接return 3打断休眠。

可以整理您的项目需求发送到邮箱zhaiyw@wch.cn