We're wondering if there is documentation available regarding when a device is considered "disconnected".
We have an app that communicates with a custom hardware device (Nordic chip) over BLE. Everything usually works great as long as the iOS device and the hardware device are in close proximity.
When the connection is "bad" (i.e. blocked by a human body or a couple of feet of distance) the app occasionally receives the didDisconnectPeripheral event from CBCentralManager.
How does iOS determine when to disconnect a device? Are there any connection parameters that could be tweaked?
Blocked by human body or a few feet is rather surprising to get a disconnect in open air. What is the tx power of your device? Do you have a PCB antenna or a dedicated one? Years and years ago I was able to get an iPhone and iPad to stay connected over BLE several houses away down the street in open air. I think iOS defaults to 0 dbm for tx power when using CBPeripheralManger? It has been a while. Anyways, operating within an arms length should really be something that is stable IMHO if you have relatively high TX and good antenna design. I forget if the NRF series has an antenna built into the housing or allows for external ones. If you have the ability to turn up your tx power, that is one thing you can try. Do you read RSSI from your device often? What does it look like just before disconnect? This can be used to help troubleshoot too.
As for what is controlling the disconnect determination, you're looking for the "supervisory timeout" or "supervision timeout". This is probably something you can control from the nordic SDK and have updated during the connection with your iOS device. I thought that iOS set the supervisory timeout to 720 ms by default, so you can only go < 1 second without bidirectional packets before the link is considered lost. However the accessory guideline now talks about having your device set to 2 seconds.
Here are some useful links
