You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Tim Hutt <td...@gmail.com> on 2016/09/01 09:02:00 UTC
Re: Setting connection parameters
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 <cc...@apache.org> 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
>
Re: Setting connection parameters
Posted by will sanfilippo <wi...@runtime.io>.
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 <td...@gmail.com> 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 <cc...@apache.org> 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
>>
Re: Setting connection parameters
Posted by Christopher Collins <cc...@apache.org>.
Hi Tim,
On Thu, Sep 01, 2016 at 12:39:59PM -0700, Christopher Collins wrote:
> So the NimBLE host really isn't doing its job here. The
> ble_gap_update_params() should do something like this:
>
> 1. If master: send LE Connection Update HCI command to controller.
> 2. Else (slave):
> a. If both peers support the CPRLLC procedure: send LE Connection
> Update HCI command to controller
> b. Else: Send the L2CAP Connection Parameter Update Request.
>
> We'll need to get this fixed in the NimBLE host.
This issue should be fixed on the master branch. Now you should be
able to call ble_gap_update_params() and the correct thing should always
happen. There is no need to explicitly call ble_l2cap_sig_update()
anymore.
Having said all that :), I am still not sure why you were seeing issues
with the Xperia phone. It would be interesting to see what happens with
the latest code. If you get a chance to try it out, please let us know
how it goes.
Thanks,
Chris
Re: Setting connection parameters
Posted by Christopher Collins <cc...@apache.org>.
Hi Tim,
On Thu, Sep 01, 2016 at 10:02:00AM +0100, Tim Hutt wrote:
> Hmm well I didn't get the ble_gap_update_params() version to work,
Is the host providing any feedback at all regarding the outcome of the
procedure? Here is the sequence of events that I would expect:
1. Application calls ble_gap_update_params()
2. Host informs application of the procedure outcome via a call to the
gap event callback with the following parameters:
* event.type: BLE_GAP_EVENT_CONN_UPDATE
* conn_update.status: indicates whether the peer accepted or
rejected the request.
If the peer accepted the request, then the application can determine the
updated connection parameters by inspecting corresponding connection
descriptor (via a call go ble_gap_conn_find()). This is necessary
because the master device doesn't have to use the exact parameters that
the slave requested.
I wondering if you are seeing a bug in the NimBLE host, or if the Xperia
device is not behaving as the NimBLE controller expects it to. Do you
happen to know which link-layer PDUs get exchanged when you initiate the
procedure?
> 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.
Ah, that makes sense. There is some wording in the spec that I hadn't
noticed earlier. This excerpt from the spec describes the L2CAP
connection parameter update request (Vol. 3, Part A, 4.20):
This command shall only be sent from the LE slave device to the LE
master device and only if one or more of the LE slave Controller, the LE
master Controller, the LE slave Host and the LE master Host do not
support the Connection Parameters Request Link Layer Control Procedure
([Vol. 6] Part B, Section 5.1.7).
So the NimBLE host really isn't doing its job here. The
ble_gap_update_params() should do something like this:
1. If master: send LE Connection Update HCI command to controller.
2. Else (slave):
a. If both peers support the CPRLLC procedure: send LE Connection
Update HCI command to controller
b. Else: Send the L2CAP Connection Parameter Update Request.
We'll need to get this fixed in the NimBLE host.
Thanks,
Chris