Not sure I am answering the right question here as I am sort of jumping in the middle, but with the NRF51 when you erase the flash the CPU is halted. At least, that is what the documentation states. The joy :-)
> On Apr 20, 2017, at 4:16 PM, marko kiiskila <[email protected]> wrote: > > 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 >>>> >> >
