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 > > >
