Tim: Regarding the BLE_LL_CFG_FEAT_CONN_PARAM_REQ: I will discuss this with our host expert as I have some questions I need to ask him about this.
Regarding the LL_LENGTH_REQ. When you say a “load” of LL_LENGTH_REQ control PDU’s I presume that means more than one? So… 1) The controller should only send one LL_LENGTH_REQ to a device per connection if it receives the LL_UNKNOWN_RSP. If it is not, it is a bug. 2) Currently, the controller does not cache information about a peer. This is a feature we are going to add but it is not there yet. Thus, when I say “per connection” I mean if a connection with a peer gets drop (on purpose or not) and then another connection with that same peer is established, another LL_LENGTH_REQ will get sent. 3) The very first thing the controller attempts to do is the length req. After some unplugfest testing and thinking about this a bit more, we are going to change how the controller initiates control procedures. At first, I was thinking that moving to larger packets right away would be the most optimal but sending a feature exchange/version indication first might be best. The specification does not specify this ordering so technically we are ok, but practically we may not be. > On Sep 1, 2016, at 2:02 AM, Tim Hutt <[email protected]> wrote: > > Hmm well I didn't get the ble_gap_update_params() version to work, but I > did get ble_l2cap_sig_update() to work! The key is to *not* enabled the > BLE_LL_CFG_FEAT_CONN_PARAM_REQ feature. If I had that enabled, the slave > sent an L2CAP Connection Parameter Update Request, and the master replied > with an L2CAP Connection Parameter Update Response, saying they were > accepted, but then the parameters didn't actually change. If you disable > the feature, then instead of replying with an L2CAP Connection Parameter > Update Response message, it sends a LL_CONNECTION_UPDATE_IND packet that > actually changes the parameters. > > By the way I noticed Nimble sends a load of LL_LENGTH_REQ's that never get > replied to (except by an LL_UNKNOWN_RSP). They're even sent before > LL_VERSION_IND's have been exchanged. Is that intended? > > Cheers, > > Tim > > On 31 August 2016 at 05:03, Christopher Collins <[email protected]> wrote: > >> Hi Tim, >> >> Thanks for the report. I am curious why ble_gap_update_params() did not >> work with the Xperia. One thing I should mention is that the central is >> not obligated to update the connection when the peripheral asks it to. >> It should have responded to the request, though. >> >> On Tue, Aug 30, 2016 at 04:10:58PM +0100, Tim Hutt wrote: >> [...] >>> 3. Using a 5 second timeout, then ble_gap_update_params it works as >>> expected! I couldn't find in the spec where it mentions the 5 seconds, >> but >>> I guess it is needed in some way. >> >> The five second recommendation is in Vol. 3, Part C, Appendix A, Table >> A.1: >> >> Timer name >> TGAP(conn_pause_peripheral) >> >> Value >> 5s >> >> Description >> Minimum time upon connection establishment before the peripheral >> starts a connection update procedure >> >> Requirement or Recommendation >> Recommended value >> >> Thanks, >> Chris >>
