測試DB確實變好了，能讀取到設(shè)備的addr的距離也變遠了，但是能夠連接上主機的距離沒有變化，一旦超出原來的那個距離，雖然能讀到設(shè)備的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);

應(yīng)該說是連接上了之后馬上斷開，但是Addr又是正確的，Reason：3e一般是什么情況才會導(dǎo)致的，后續(xù)的連接事件收不到嗎

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

3e是連接未成功建立，在使用最新官方代碼的情況下，可能與硬件有關(guān)系。

可以針對性的測試一下不控制PA是否可以搜索到微弱的信號以及是否可以連接成功，目的是確定是否為PA芯片的影響。

近距離是可以連接成功的，超出一定距離之后就一直顯示3e了

剛開始全部拉低的時候，不控制PA也是能連接上的，用官方代碼控制PA后，確實有信號增強的情況，比之前距離更遠一點點，但更遠的地方就一直報3e了

可以確定一下需要的距離是多遠，PA的硬件繪制對距離影響很大。

如果是近距離連接無問題，遠距離連接會很困難，則可能是距離過遠導(dǎo)致藍牙連接包交互困難丟包嚴重。一般加上PA后可以達到200m的。

好的謝謝，還想多問一下，BLE從機例程的功耗是會比BLE MESH Vendor例程的功耗大一些嗎，做的功能一樣，從機例程定時通知主機的功耗是7mA左右，但是mesh vendor例程定時用vendor_model_srv_send發(fā)送給配網(wǎng)者功耗到了17mA

把宏CONFIG_BLE_MESH_RELAY改為0之后 功耗也沒有什么變化，節(jié)點想做到只發(fā)不收來降低功耗，但是看例程低功耗節(jié)點需要綁定朋友節(jié)點，想做到圖示說的效果

相同的喚醒間隔（在BLE從機例程中是連接間隔決定，在藍牙m(xù)esh的低功耗節(jié)點例程中是CONFIG_MESH_LPN_POLLINTERVAL_DEF決定），藍牙m(xù)esh的功耗是比BLE要高的，因為藍牙m(xù)esh每發(fā)一包是在三個信道上都收/發(fā)一遍；BLE有跳頻機制，某一時刻只要在一個信道收/發(fā)包即可。

CONFIG_BLE_MESH_RELAY這個宏是決定了長供電節(jié)點（一般非mesh低功耗節(jié)點的設(shè)備都要做長供電）是否啟用包轉(zhuǎn)發(fā)，與是否進入低功耗無關(guān)。

mesh協(xié)議中提供了低功耗節(jié)點+朋友節(jié)點的解決方案來實現(xiàn)低功耗節(jié)點的雙向通信。

如果您不想增加朋友節(jié)點，且只做發(fā)往中心節(jié)點匯總的單向通信，那么可以不使用低功耗節(jié)點例程，使用一般節(jié)點即adv_vendor例程+啟用HAL_SLEEP休眠的方案實現(xiàn)。注意①每隔一段時間（比如說啟用一個20h/次的TMOS事件）需要開啟一段時間的接收掃描（bt_mesh_scan_enable/bt_mesh_scan_disable）以保持網(wǎng)絡(luò)同步；②配網(wǎng)過程中不可以進入休眠，可以在CH58X_LowPower函數(shù)中判斷是否已成功配網(wǎng)，是則允許繼續(xù)執(zhí)行休眠，否則直接return 3打斷休眠。

可以整理您的項目需求發(fā)送到郵箱zhaiyw@wch.cn