I believe the setting to tweak is the slave latency, and have some empirical evidence to back that up. Increasing supervision timeout doesn't help if the timeout is at the link manager level (because of a blocking call, say), while increasing slave latency allows the peripheral to take more than one connection itvl to ack the frames.
On Thu, Apr 20, 2017 at 2:55 PM, Christopher Collins <[email protected]> wrote: > Hi Jacob, > > On Thu, Apr 20, 2017 at 02:21:01PM -0700, Jacob Rosenthal wrote: > > I think the default intervals are here, which should be sufficiently over > > 20ms > > /** 30 ms. */ > > #define BLE_GAP_ADV_FAST_INTERVAL1_MIN (30 * 1000 / > BLE_HCI_ADV_ITVL) > > //48 > > > > /** 60 ms. */ > > #define BLE_GAP_ADV_FAST_INTERVAL1_MAX (60 * 1000 / > BLE_HCI_ADV_ITVL). > > //96 > > > > /** 100 ms. */ > > #define BLE_GAP_ADV_FAST_INTERVAL2_MIN (100 * 1000 / > BLE_HCI_ADV_ITVL) > > //160 > > > > /** 150 ms. */ > > #define BLE_GAP_ADV_FAST_INTERVAL2_MAX (150 * 1000 / > BLE_HCI_ADV_ITVL) > > //240 > > > > or I can even force to the higher ones in bleprph: > > > > adv_params.itvl_min = BLE_GAP_ADV_FAST_INTERVAL2_MIN; > > adv_params.itvl_max = BLE_GAP_ADV_FAST_INTERVAL2_MAX; > [...] > > > <https://devzone.nordicsemi.com/users/580/olha/> > > > In logs, interval advertises as adv_itvl_min=0 adv_itvl_max=0, on > > > connection logs ive seen both itvl=9 and itvl=12, not sure what that > maps > > > to yet though.. > > These are advertising intervals, i.e., how frequently the device sends > out an advertisement, and not relevant here. BLE has a lot of > "intervals," so I don't fault you for getting confused! > > The interval of importance here is the connection interval, i.e., how > frequently the two connected peers attempt communication. > > I think adjusting the connection interval is not the best solution for > the supervision timeout problem. If you increase the interval, this > might help maintain the connection, but it will also impair response > time between the two devices. The correct setting to increase, in my > opinion, is the supervision timeout. By increasing this, you allow the > peripheral device to stay quiet for a longer period of time without the > connection getting dropped. > > Regardless of which parameter you change, there are two ways to do it: > 1. Configure the central device such that it initiates connections > with the preferred settings (this is what Vipul suggested in his > newtmgr diff). > > 2. Have the peripheral device request a connection parameter update > after the connection is established. With NimBLE, you would use > the ble_gap_update_params() function for this > (https://mynewt.apache.org/latest/network/ble/ble_hs/ble_ > gap/functions/ble_gap_update_params/). > > Option 1 is the reliable way to do this. With option 2, the central may > choose to disregard your requested parameters, so you're really at the > central's mercy. > > Chris >
