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]> 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]>
> 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:;>>
> > 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
> > >
> >
>
