你好，我使用的芯片時CH32V208，我想請教一下，在使用貴公司BLE mesh的配網(wǎng)器例程provisioner_vender_with_peripheral時， 由于環(huán)境影響等原因，配網(wǎng)器給節(jié)點(diǎn)發(fā)消息時常丟包（配網(wǎng)器顯示發(fā)送成功但是節(jié)點(diǎn)沒收到），所以選擇相同的數(shù)據(jù)循環(huán)發(fā)送3次，情況有所好轉(zhuǎn)，但是還是無法完全避免，配網(wǎng)器如果通過廠商自定義模型循環(huán)發(fā)送透傳數(shù)據(jù)時（代碼如圖微信圖片_20240803001808.png），不論數(shù)據(jù)長度，只能完成前8次發(fā)送，當(dāng)發(fā)送到第9次的時候會出現(xiàn)報錯err：-7（發(fā)送緩存已滿）微信圖片_20240803001829.png，加入延時也沒用，CONFIG_MESH_ADV_BUF_COUNT_DEF最大只能到16，否則無法配網(wǎng)，報錯：Unable set configuration (err:-7)，trans_cnt本來就是最小，為0x01，請問有什么辦法可以解決上述問題嗎？（或者如何有效避免丟包）

“只能完成前8次發(fā)送，當(dāng)發(fā)送到第9次的時候會出現(xiàn)報錯err：-7（發(fā)送緩存已滿）”

報錯-7通常有兩種情況①發(fā)包太快，發(fā)包隊(duì)列滿了；②協(xié)議棧內(nèi)存不足。

與情況①相關(guān)，圖一中的發(fā)包邏輯，for循環(huán)中10ms就填充一包，會向發(fā)包隊(duì)列中填充vendor_model_cli_send接口中，.trans_cnt結(jié)構(gòu)體成員數(shù)值數(shù)量的包個數(shù)；在當(dāng)前.trans_cnt是1的情況下，若周圍有其他節(jié)點(diǎn)發(fā)包，轉(zhuǎn)發(fā)包也算在發(fā)包隊(duì)列空間內(nèi)，那么連續(xù)執(zhí)行3個for循環(huán)是很可能會隊(duì)列大小滿的。按mesh協(xié)議實(shí)際發(fā)完應(yīng)用層的一包，需要約70ms，加上其他時間開銷，1s內(nèi)只能安排往外發(fā)送10個包。

排查情況②，Ⅰ.檢查BLE_MEMHEAP_SIZE是否被改動，改太小了；Ⅱ.檢查是否在BLE已連接的情況下才可以復(fù)現(xiàn)問題，若是，請下載一份最新EVT，覆蓋更新mesh庫；Ⅲ.如果在應(yīng)用層的發(fā)包函數(shù)中添加了tmos的內(nèi)存申請接口，檢查發(fā)包后是否釋放。

CONFIG_MESH_ADV_BUF_COUNT_DEF改大后報錯-7的問題，這個報錯少見，推測還是協(xié)議棧ram分配太小導(dǎo)致的，加大BLE_MEMHEAP_SIZE在做嘗試。

好像還是不太像誒，請問底層如何判斷消息是否發(fā)送完成哇？第9次開始報錯是不是因?yàn)橹暗南]有發(fā)送成功或者節(jié)點(diǎn)沒有收到，導(dǎo)致內(nèi)存一直被占用，沒有釋放？也就是說循環(huán)發(fā)送3次實(shí)際上是無效的？

發(fā)包方?jīng)]有接口可以查詢發(fā)包隊(duì)列中現(xiàn)存幾個包，只能通過報錯來表現(xiàn)。查看收包方的打印，看能不能收到包，用來查看發(fā)包能不能發(fā)出；發(fā)包的目標(biāo)地址，配置為0xFFFF，這個包是所有節(jié)點(diǎn)包括本節(jié)點(diǎn)都理應(yīng)收到的。

多收集一些信息：斷開BLE，關(guān)閉轉(zhuǎn)發(fā)功能后，發(fā)包頻次降低到1s發(fā)出1包還會不會報錯？EVT包是什么時候下載的，更新到最新EVT的mesh庫是否解決。