Hello: They are both related (in a way). When you increase the slave latency the supervision timeout sort of increases along with it (in a manner so speaking). The minimum supervision timeout is this: (1 + connSlaveLatency) * connInterval * 2.
So if you increase the slave latency you need to increase the supervision timeout. I have not completely read through all the emails in this thread but you can do either to address this issue. However, there are pros and cons to changing the slave latency. The pro is that you save battery power on the peripheral; the con is that it will take longer to transfer data if data is not queued up at the master. If all you want to do is to avoid a period of time where one side basically goes away and does not come back for a while, I think I would change the supervision timeout. If you are connected but generally do not send lots of information, and do not care about latency and care about battery power, I would change the slave latency. I do think increasing the supervision timeout will help this particular issue. If you are erasing the flash and it takes, say, 100 msecs, having a long supervision timeout (greater than 100 msecs plus a number of connection intervals) should do the trick. I would give three or four connection intervals plus the time you think you might be away for the supervision timeout. > On Apr 20, 2017, at 3:42 PM, Simon Ratner <si...@proxy.co> wrote: > > 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 <ch...@runtime.io> > 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 >>
