supervision_timeout = 300 appears to have done it! Any good way to find the
existing params change just the 1 I actually want to change?
Maybe nrf51 devices should look up supervision_timeout and either send an
error code or even request parameter update automatically?
static int
bleprph_gap_event(struct ble_gap_event *event, void *arg)
{
struct ble_gap_conn_desc desc;
int rc;
switch (event->type) {
case BLE_GAP_EVENT_CONNECT:
struct ble_gap_upd_params params = {
.itvl_min = BLE_GAP_ADV_FAST_INTERVAL1_MIN,
.itvl_max = BLE_GAP_ADV_FAST_INTERVAL1_MAX,
.supervision_timeout = 300,
.min_ce_len = BLE_GAP_INITIAL_CONN_MIN_CE_LEN,
.max_ce_len = BLE_GAP_INITIAL_CONN_MAX_CE_LEN,
};
rc = ble_gap_update_params(event->connect.conn_handle, ¶ms);
assert(rc == 0);
return 0;
On Thu, Apr 20, 2017 at 4:23 PM, will sanfilippo <[email protected]> wrote:
> 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
> >>>>
> >>
> >
>
>
