Hi Jacob, itvl_min and itvl_max specify the range of connection interval values that you're willing to accept. The controller chooses the value in that range that it likes best. If you want an exact interval, then specify the same number for both fields. In this case, that number would be the connection interval reported by ble_gap_conn_find.
To be honest, I don't recall what the min_ce_len and max_ce_len fields mean, and I don't have the spec handy. I do know that these fields are only meaningful between the host and the controller. That is, they aren't properties of the connection, and the peer device doesn't one what value your controller uses here. The host also doesn't know which value the controller uses in this range. Re: auto negotiating- there is nothing Mynewt which does this. It is lest up to the central to use disable connection parameters if it will be performing an image upgrade. It sounds like a useful feature, though. Maybe someone can contribute it :). Chris On Friday, April 21, 2017, Jacob Rosenthal <[email protected]> wrote: > Hrm. The only thing I could pull from that is conn_latency > I need itvl_min, itvl_max, but Ive got conn_itvl > I also need min_ce_len, max_ce_len > > struct ble_gap_conn_desc { > struct ble_gap_sec_state sec_state; > ble_addr_t our_id_addr; > ble_addr_t peer_id_addr; > ble_addr_t our_ota_addr; > ble_addr_t peer_ota_addr; > uint16_t conn_handle; > uint16_t conn_itvl; > uint16_t conn_latency; > uint16_t supervision_timeout; > uint8_t role; > uint8_t master_clock_accuracy; > }; > struct ble_gap_upd_params { > uint16_t itvl_min; > uint16_t itvl_max; > uint16_t latency; > uint16_t supervision_timeout; > uint16_t min_ce_len; > uint16_t max_ce_len; > }; > > But also back to my lost question, in a world where (to my knowledge) you > cant set supervision_timeout from ios/osx/web bluetooth, is there an > upstream newt solution for newtmgr ble transport to automatically negotiate > favorable firmware update parameters from device as part of the image > upload command? > > > > On Fri, Apr 21, 2017 at 11:28 AM, chris collins <[email protected] > <javascript:;>> wrote: > > > ble_gap_conn_find tells you the settings that are actually being used. If > > you just want to change one parameter in an established connection, you > > would copy all but one of the values from the returned desc into the > update > > parameters. You would probably call ble_gap_conn_find immediately before > > calling ble_gap_update_params, during the connect callback. > > > > Chris > > > > On Friday, April 21, 2017, Jacob Rosenthal <[email protected] > <javascript:;>> > > wrote: > > > > > find returns ble_gap_conn_desc which is the post negotiated values.. > Im > > > not sure it helps me know what the original max/mins we negotiated > were. > > > These are based on the advertised values right? Itd be nice to have a > > > helper function to just update the one I want, much like in advertising > > > where they were autocalculated > > > > > > struct ble_gap_conn_desc { > > > struct ble_gap_sec_state sec_state; > > > ble_addr_t our_id_addr; > > > ble_addr_t peer_id_addr; > > > ble_addr_t our_ota_addr; > > > ble_addr_t peer_ota_addr; > > > uint16_t conn_handle; > > > uint16_t conn_itvl; > > > uint16_t conn_latency; > > > uint16_t supervision_timeout; > > > uint8_t role; > > > uint8_t master_clock_accuracy; > > > }; > > > > > > > > > As low as 248, or could just round up to 256 (x100) works here as well. > > > > > > > > > On Fri, Apr 21, 2017 at 8:09 AM, Christopher Collins <[email protected] > <javascript:;> > > > <javascript:;>> > > > wrote: > > > > > > > On Thu, Apr 20, 2017 at 09:43:12PM -0700, Jacob Rosenthal wrote: > > > > > 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? > > > > > > > > You can use ble_gap_conn_find() to determine the current connection > > > > parameters. > > > > > > > > > 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; > > > > > > > > Careful, you're specifying advertising interval values as connection > > > > interval parameters. Using ble_gap_conn_find() will take care of > this. > > > > > > > > Chris > > > > > > > > > >
