Glad other folks were answering you Simon; I was away for a bit. I do not have anything else to add. The only thing is that if you do not have a sniffer one (possible) way to determine what is going on is to look at statistics. You need to look at the stats directly before and after the issue which could be a problem. What that will tell you is if the peripheral heard the connect request from the master and to determine which side is not hearing the data frames. If you want to go that route please let me know and I can tell which stats to look for. This might be difficult for you to set up if it is that infrequent.
I would also try out the new code base as well if that is easily doable for you. Many things were fixed/changed so using that codebase going forward would certainly be best (imo) > On Sep 5, 2017, at 11:57 AM, Łukasz Rymanowski > <[email protected]> wrote: > > Hi, > > On Sep 5, 2017 8:15 PM, "Simon Ratner" <[email protected]> wrote: > > On Tue, Sep 5, 2017 at 11:01 AM, Łukasz Rymanowski < > [email protected]> wrote: > >> >> Note that this is how BLE works. Master sends LE Create Connection on >> Advertising event and assumes connection is created. In this point of time >> host gets Connection Complete Event according to BT spec. However, for the >> reasons Will described, it might happen that peer will not answer on any > of >> the first 6 connection events. In this case connection is considered as >> dropped and Disconnect Complete Event will come with "Connection failed > to >> be established" goes to host > > > Got it, thanks Łukasz! I am sure that the timeout is happening in exactly > this place.Since it seems that in all cases the times are very close, i > think i can increase connection interval to make this significantly less > frequent. > > > Please let us know the result. > BTW Air logs would help to confirm what is happening. > > \Łukasz
