偶爾情況是這樣，但是好像時(shí)不時(shí)會(huì)出現(xiàn)，斷電重上電之后可能會(huì)正常，安卓主機(jī)的日志：[INFO:btsnoop.cc(323)] clear_l2cap_whitelist: Clearing whitelist from l2cap channel. conn_handle=6 cid=4:4?

btm_sec_disconnected clearing pending flag handle:6 reason:8

藍(lán)牙設(shè)置：

// How often to perform read rssi event

#define SBP_READ_RSSI_EVT_PERIOD? ? ? ? ? ? ?3200

// Parameter update delay

#define SBP_PARAM_UPDATE_DELAY? ? ? ? ? ? ? ?6400

// What is the advertising interval when device is discoverable (units of 625us, 80=50ms)

#define DEFAULT_ADVERTISING_INTERVAL? ? ? ? ?80

// Limited discoverable mode advertises for 30.72s, and then stops

// General discoverable mode advertises indefinitely

#define DEFAULT_DISCOVERABLE_MODE? ? ? ? ? ? GAP_ADTYPE_FLAGS_GENERAL

// Minimum connection interval (units of 1.25ms, 6=7.5ms)

#define DEFAULT_DESIRED_MIN_CONN_INTERVAL? ? 6

// Maximum connection interval (units of 1.25ms, 100=125ms)

#define DEFAULT_DESIRED_MAX_CONN_INTERVAL? ? 3200

// Slave latency to use parameter update

#define DEFAULT_DESIRED_SLAVE_LATENCY? ? ? ?6

// Supervision timeout value (units of 10ms, 100=1s)

#define DEFAULT_DESIRED_CONN_TIMEOUT? ? ? ? ?3200

用一些小程序連接有時(shí)候也會(huì)有這問題，連接成功后馬上提示斷開連接

reason8是超時(shí)斷開，檢查是否代碼有執(zhí)行時(shí)間過長的任務(wù)，導(dǎo)致藍(lán)牙本身任務(wù)來不及處理而出現(xiàn)的斷開。

將有效連接間隔配置為最大任務(wù)的兩倍。

slavelatency目前先不要配置，使用默認(rèn)的0。

可以先使用例程測(cè)試，防止硬件導(dǎo)致射頻信號(hào)受到影響。

最大任務(wù)600ms左右，最大連接間隔4s，按道理來說不會(huì)超時(shí)，而且這個(gè)任務(wù)是安卓發(fā)送指令了他才發(fā)生，沒發(fā)指令的時(shí)候什么都沒運(yùn)行。有時(shí)候是一連接，或者連接中突然斷連，還有沒有可能是其他情況?

reason8的斷開是超時(shí)斷開。

針對(duì)測(cè)試點(diǎn)：

1、例程測(cè)試，連接APP查看是否斷開；

2、例程測(cè)試如問題，將連接間隔拉大，如配置為1000，timeout時(shí)間配置為500，查看是否斷開；

3、自行檢查代碼是否有執(zhí)行時(shí)間過長的任務(wù)；

4、slavelatency這個(gè)參數(shù)目前建議不要使用。