> 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.
Note that iOS will reject such a request, see their accessory design
guidelines.
For one, itvl_max must be at least 20ms bigger than itvl_min.
On Fri, Apr 21, 2017 at 5:30 PM, chris collins <ch...@runtime.io> wrote:
> 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 <jakerosent...@gmail.com>
> 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 <ch...@runtime.io
> > <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 <jakerosent...@gmail.com
> > <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 <
> ch...@runtime.io
> > <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
> > > > >
> > > >
> > >
> >
>
