使用的是最新的2.4G庫，從機(jī)進(jìn)入低功耗之后，主機(jī)通信超時(shí)，然后從機(jī)喚醒之后，主機(jī)就會(huì)有一段時(shí)間3-5s在跳頻成功和失敗切換，之后才可以正常通信。這個(gè)怎么解決？

請貼上例程中修改了哪些地方出現(xiàn)的問題，并附上對應(yīng)修改的代碼

另外低功耗處理是否是通過例程中的RF_SLEEP_EVENT進(jìn)行管理的？

歷程給的數(shù)組是7個(gè)，我把這個(gè)改成1個(gè)就改了一些東西，低功耗在另一個(gè)任務(wù)里面執(zhí)行，沒有在跳頻這里執(zhí)行，如果你需要看全部代碼可以給個(gè)郵箱我發(fā)過去

這些宏定義中，

#define? RF_ROLE_ID_INVALD? ? ? ?(0x07)

#define? RF_ROLE_ID_MASK? ? ? ? ?(0x07)

#define? RF_ROLE_BOUND_MAX? ? ? ?(0x07)

上面這三項(xiàng)不要做修改，RF_ROLE_BOUND_ID可以自己指定ID，讓Dongle分配這個(gè)ID給你，如果填寫的是RF_ROLE_ID_INVALD，也就是0x07，那么Dongle會(huì)隨機(jī)分配ID。

當(dāng)然你改了這些也不會(huì)對當(dāng)前的通訊造成影響，現(xiàn)在出現(xiàn)的現(xiàn)象比較像是雙方時(shí)序不同步造成的，現(xiàn)在確認(rèn)以下幾點(diǎn)：

1、首先確認(rèn)時(shí)鐘宏雙方是否一致。

2、雙方綁定連接回調(diào)中，斷開連接時(shí)校準(zhǔn)內(nèi)部RC的函數(shù)是否有執(zhí)行到，目的是斷開連接雙方校準(zhǔn)一次，鞏固下一次的連接穩(wěn)定性。

3、從機(jī)端休眠任務(wù)是自己調(diào)用LowPower_Sleep、LowPower_Halt、LowPower_Idle其中一個(gè)接口，還是通過我們提前寫好的sleep自動(dòng)喚醒保持連接的任務(wù)進(jìn)行調(diào)用的，如果是自己調(diào)用LowPower_Sleep這種形式，是有可能在喚醒后存在一段時(shí)間的斷連和連接的，但時(shí)間不會(huì)長達(dá)幾秒鐘，一般在幾百毫秒之內(nèi)能恢復(fù)穩(wěn)定。

4、雙方綁定任務(wù)中bound.timeout = 150參數(shù)有沒有改??？

1、首先確認(rèn)時(shí)鐘宏雙方是一致的。

2、這個(gè)校準(zhǔn)函數(shù)有，但是好像沒怎么調(diào)用。

3、喚醒是自己寫的，用的是外部中斷

4、超時(shí)參數(shù)沒有改動(dòng)。

有個(gè)問題，我發(fā)現(xiàn)如果master進(jìn)入低功耗之后，host斷開藍(lán)牙連接，有時(shí)會(huì)連其他的master，有沒有辦法做到一對一切斷開不連其他設(shè)備，重新初始化設(shè)定之后又可以連其他設(shè)備了，超時(shí)之后不連接任何設(shè)備。

1、低功耗休眠喚醒后，反復(fù)的斷連回連出現(xiàn)概率高嗎？如果概率較小，可能是32M時(shí)鐘未穩(wěn)定，加上內(nèi)部32k誤差較大引起的，可在喚醒后主動(dòng)調(diào)用Lib_Calibration_LSI();接口校準(zhǔn)兩次試試。

2、首先確保CONNECT_NUM參數(shù)為1，代表此host只會(huì)連接1個(gè)設(shè)備，在此基礎(chǔ)上，host端關(guān)注一個(gè)參數(shù):gSpeedList_t.pList[0].peerInfo，該變量代表host此時(shí)會(huì)去定向連接的設(shè)備mac地址，如果全為0，則會(huì)連接任意設(shè)備，否則會(huì)去連接指定設(shè)備。

并且host端的綁定做法是上電前三秒，會(huì)主動(dòng)清空gSpeedList_t.pList[0].peerInfo，也就是全為0，符合你說的重新初始化能夠綁定其他設(shè)備的現(xiàn)象，超過3秒后未連上任何設(shè)備的話，則會(huì)從dataflash中取出地址回連，因此，host端非必要不要重新初始化RF。