Does flash erase disable interrupts? I.e. would running newtmgr on a separate thread help?
> On Apr 20, 2017, at 4:14 PM, will sanfilippo <[email protected]> wrote: > > 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 <[email protected]> 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 <[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 >>> >
