Quick question: do you see supervision timeouts when you do not expect them? If so, does this happen more/less when you are either a master or a slave? I know this gets a bit tricky at times to “debug”, but if you are seeing unexpected supervision timeouts do they occur very close to when the device says it is connected (returns the connection complete event)? During the bluetooth unplugfest we realized that the controller is not properly returning the “connection failed to be established” error; it is returning a supervision timeout.
I would be interested to know if the devices are connecting, staying connected for a while, then timing out… > On Jun 30, 2016, at 12:39 PM, Simon Ratner <[email protected]> wrote: > > Hi devs, > > I've been looking at the reasons I get in BLE_GAP_EVENT_DISCONNECT to make > sure I cover all edge cases, and this is what I see (on an nrf51-based > board): > > switch (ctxt->disconnect.reason) { > case BLE_HS_ENOTCONN: > /* I see this when the local host has terminated the connection. > Feels like this should > * be BLE_HS_HCI_ERR(BLE_ERR_CONN_TERM_LOCAL) instead, per spec. > */ > break; > case BLE_HS_HCI_ERR(BLE_ERR_CONN_SPVN_TMO): > /* Supervision timeout, I see this occasionally. */ > break; > case BLE_HS_HCI_ERR(BLE_ERR_REM_USER_CONN_TERM): > case BLE_HS_HCI_ERR(BLE_ERR_RD_CONN_TERM_RESRCS): > case BLE_HS_HCI_ERR(BLE_ERR_RD_CONN_TERM_PWROFF): > /* Remote termination, I see the first one when remote peer > terminates the connection. */ > break; > case BLE_HS_HCI_ERR(BLE_ERR_CONN_TERM_LOCAL): > /* Local termination, I never see this one. */ > break; > } > > Local termination should not be setting reason to BLE_HS_ENOTCONN (which, > when mapped onto the space of error codes in 4.2 vol 2 part D, ends up > being BLE_ERR_MEM_CAPACITY, confusingly).
