Hi Simon, Unfortunately I am not able to reproduce that behavior. However, I think I can answer one of your questions. Hopefully that will lead to a full solution.
That -1 return code is generated when the stack runs out of HCI command / event buffers. The actual return code is a bug; BLE_HS_ENOMEM should probably be returned instead. I am a bit puzzled about the cause of the buffer shortage. You are probably receiving a lot of advertisement reports from the controller, but I wouldn't expect them to be coming in faster than you can handle them, but I suppose that depends on the particulars of your application. You can try increasing the number of HCI buffers at host initializtion time. This setting is in the host configuration struct, and it is called max_hci_bufs. Regarding the second problem (ble_gap_conn_initiate() returns BLE_HS_ETIMEOUT): I have a guess. The return code indicates that the controller did not respond to an HCI command in a timely manner. My guess is that the controller is unable to allocate an HCI buffer due to the shortage. From looking at the code, it appears we don't have any statistics indicating the number of times an HCI buffer failed to allocate... this is definitely something that should be added. Chris On Mon, Jun 20, 2016 at 5:07 PM, Simon Ratner <si...@proxy.co> wrote: > Thanks Chris, just tried it out and it seems to do the trick -- half of the > time. > > I see two occasional errors: > > 1. Sometimes, ble_gap_disc_cancel returns (-1); any idea under what > circumstances that might happen? > > 2. Sometimes, ble_gap_disc_cancel returns 0 but ble_gap_conn_initiate > immediately afterwards fails with code 14 (ETIMEOUT? unless it's an hci > error?). Is it possible that this is timing-related somehow and the link > layer hasn't switched to the right state yet? Should i delay connect > attempt for a tick? > > Both of these occur inconsistently; about half the time it just works. > > > On Sat, Jun 18, 2016 at 10:21 PM, chris collins <ch...@runtime.io> wrote: > > > Hi Simon, > > > > Thanks for the heads up; this is definitely an omission. You should be > > able to cancel a scan in progress. > > > > Barring any unforeseen complications, the cancel functionality should be > > implemented in the develop branch tomorrow. This will allow the app > cancel > > the scan and initiate a connect procedure from within the advertising > event > > callback. > > > > Chris > > > > > > On Sat, Jun 18, 2016 at 7:38 PM, Simon Ratner <si...@proxy.co> wrote: > > > > > Hi devs, > > > > > > Having initiated an undirected scan with ble_gap_disc(), I would like > to > > > connect to my peripheral as soon as I spot it in the scan callback. > > > However, calling ble_gap_conn_initiate() at this point fails with > > > BLE_HS_EALREADY, as ble_gap_master is still in discovery mode. I need > to > > > stash the discovered peripheral, wait for the scan to finish, and then > > try > > > to connect, which is unnecessary state management. Additionally, there > > > doesn't seem to be a way to cancel the scan, so this becomes especially > > > problematic if the scan is long-running. > > > > > > For comparison, while advertising, an incoming connection automatically > > > drops the slave out of advertising mode (which can be resumed > immediately > > > if you have enough connection resources). > > > > > > Is this an omission, or by design? > > > > > > Cheers, > > > simon > > > > > >
