Another option is not erasing every time, and or a separate erase command.
Then its kinda of ugly you get disconnected during erase or first attempt
at upload, but after you just reconnect and upload again.
On Fri, Apr 21, 2017 at 9:29 PM, Simon Ratner <si...@proxy.co> wrote:
> > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>
