So just increasing the conn itvl hasn't solved it, which makes me suspect it isn't simply a timing thing, but rather a peer not responding to the request (or responding in an unexpected way). I tried up to 180ms, which should give it a full second to receive the first data frame.
014762 [ts=115328104ssb, mod=4 level=1] GAP procedure initiated: connect; peer_addr_type=1 peer_addr=42:62:84:90:38:f7 scan_itvl=16 scan_window=16 itvl_min=24 itvl_max=144 latency=1 supervision_timeout=512 min_ce_len=16 max_ce_len=768 014792 [ts=115562464ssb, mod=64 level=1] peer: connected; conn_handle=29 status=0 addr=42:62:84:90:38:f7 014794 [ts=115578088ssb, mod=4 level=1] GATT procedure initiated: exchange mtu 014907 *** ble_ll_conn.c:2160 *** cputime=116849198 anchor_point=117028850 last_rxd_pdu_cputime=115946959 tmo=1080000 014910 [ts=116484344ssb, mod=64 level=1] peer: updated; conn_handle=29 status=520 itvl=144 latency=1 tmo=512 014912 [ts=116499968ssb, mod=64 level=2] peer: failed to exchange mtu; conn_handle=29 status=7 014915 [ts=116523404ssb, mod=64 level=1] peer: disconnected; conn_handle=29 reason=520 I will try the 1.2 branch and report. On Tue, Sep 5, 2017 at 12:43 PM, will sanfilippo <[email protected]> wrote: > 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 > >
