Hi Szymon, Thanks for the clarification. I was going to write a queue system for GATT writes/reads but it looks like I should rely on lower layer and just reconnect if my central app has problem with communicating to peripherial devices.
Kind regards, Łukasz On Mon, May 15, 2017 at 9:07 PM, Łukasz Wolnik <lukasz.wol...@gmail.com> wrote: > Hi Chris, > > Thanks a lot for your responses. They are very helpful and are radically > shaping the way I'm going to develop the second version of my app. > > I'm pretty sure, when I investigated the issue with gdb, that the problem > was not enough GATT procs available. I'll experiment with MSYS_1_BLOCK_COUNT > and BLE_GATT_MAX_PROCS and let you know if increasing BLE_GATT_MAX_PROCS > helped. Thanks a lot for sharing these two config values. And yes, that'd > great if alongside the error it would tell which resource is not available > and what are the current limits. > > Right, so it's a 30 not a 20-second timeout. My app is a wearable item and > it's crucial for it to be robust. I think what I can do is to manually > disconnect a connection handle when I'm not getting a confirmation within 1 > second. > > Kind regards, > Łukasz > > On Mon, May 15, 2017 at 7:06 PM, Christopher Collins <ch...@runtime.io> > wrote: > >> On Mon, May 15, 2017 at 11:01:38AM -0700, Christopher Collins wrote: >> > Hi Łukasz, >> > >> > On Mon, May 15, 2017 at 12:33:59PM +0100, Łukasz Wolnik wrote: >> > > Hello, >> > > >> > > From time to time my ble_gattc_write_flat (run as central) is timing >> out >> > > after 20 seconds while sending to an Android 6 phone (in peripherial >> mode). >> > > Is there a way to reduce the timeout to just 1 second? At the moment >> if >> > > there's an issue with writing, my newt program has to wait 20 seconds >> until >> > > it can respond to a timeout. >> > > >> > > What's the best strategy here? Keep "bombarding" the peripherial with >> > > multiple writes until receiving first confirmation. Or reduce the >> timeout >> > > from 20 seconds (I don't know where this value is coming from) and >> resend >> > > only when got an HCI 19 timeout error in the callback? >> >> Oops, I forgot to respond to your actual question :). Sorry about that. >> The 30-second timeout is hardcoded in the spec, and is currently not >> configurable (Vol. 3, Part F, 3.3.3). It might be useful to make this >> configurable, but the device would not be standards compliant. >> >> Chris >> > >
