CC2745R10-Q1: About GAP_UpdateLinkParamReq() in SDK9.10

Hello,

Just to make sure I'm understanding correctly, some devices are able to have their link parameters updated via the API but others are not?

Do you mind providing an airtrace that captures both the failing and successful devices? What I'm looking for in the airtrace is when the connection is first formed, there usually is a feature exchange. The feature exchange might shed some light why it's working in some cases and why it isn't in others. Additionally, what is the device that you are connecting? Is it a phone?

Best,

Nima Behmanesh

Hi,

I took air traces when GAP_UpdateLinkParamReq() returned 0x1A and 0.

The exported csv file is as follows:

GAP_UpdateLinkParamReq() returned 0x1A. This was connected from a Vector VH4110.

→GULPRQ_Ret1A_Con_from_VH4110.csv

GAP_UpdateLinkParamReq() returned 0. This was connected from an OPP smartphone using the "nRF Connect" application.

→GULPRQ_Ret00_Con_from_SmartPhone.csv

Does this help you?

Hello,

I will take a look at these logs and get back to you on Tuesday.

Best,

Nima Behmanesh

Hello Nakamura-san, 

Please provide the sniffer log for the successful and unsuccessful case instead of the csv file. 

 Additionally, what are the connection parameters that you are attempting to update to? Also, I assume the CC2745R10 device is a peripheral if you are connecting to the smartphone? 

I suspect the parameters sent from the CC2745R10 to the VH4110 are not supported by the VH4110. The value returned indicates that the remote device received unsupported features, which in this case would indicate the parameters for the connection parameter update. Are you aware of any connection parameters that are not supported on the VH4110? 

See Vol. 1, Part F, section 2.26 of the BLE specification for the specific return code. 

Thanks,
Isaac

Hi,

We will send the sniffer log later from our representative.

The remote device I used is the VH4110 and the smartphone, BLE dongles.
Failure Log: we used the VH4110.
Success Log: we used the smartphone and BLE dongles.

> what are the connection parameters that you are attempting to update to?
I am attempting to update to the following arguments of GAP_UpdateLinkParamReq().
.intervalMin = 24
.intervalMax = 48
.connLatency = 0
.connTimeout = 100
.signalIdentifier = 0

>Also, I assume the CC2745R10 device is a peripheral if you are connecting to the smartphone?
The CC2745R10 device is a peripheral.

>I suspect the parameters sent from the CC2745R10 to the VH4110 are not supported by the VH4110.
>The value returned indicates that the remote device received unsupported features, which in this case would indicate the parameters for the connection parameter update.
>Are you aware of any connection parameters that are not supported on the VH4110?
So, it means that the VH4110 cannot support receiving the LLCP Slave Connection Parameter Request, right?
If not, what functions should the VH4110 support?

Best Regards,
Yukine

Hello Okita-san, 

I am not saying the VH4110 does not support LLCP Slave Connection Parameter Request. The 0x1A error indicates that the link layer of the remote device does not support a feature or parameter of the LLCP packet from the peripheral (Vol 1, Part F, section 2.26 of BLE specification). 

Because of this, I am suspecting a parameter within the LLCP connection parameter update is not supported by the either device. Can you clarify if the central or the peripheral is raising this error code? Can you confirm what control packet the 0x1A is seen? 

Please provide the sniffer log, as the log will help in understanding the problem. 

Thanks,
Isaac

Hi,

When a parameter update (*1) is performed on CC2745, what parameters does CC2745 expect from external devices (such as VH4110)?
Please provide the necessary parameters and the correct values and ranges for the parameters.

*1. The values of the member of the argument structure in GAP_UpdateLinkParamReq() will be updated with the following parameters:
　.intervalMin = 24
　.intervalMax = 48
　.connLatency = 0
　.connTimeout = 100
　.signalIdentifier = 0

Best Regards,
Yukine

Okita-san, 

The parameters provided are valid from the CC2745R10-Q1 perspective. I cannot say what parameters/LL control packets are valid from the VH4110 side, as I do not work with the tester. An ellisys log will be extremely helpful for helping me narrow down what parameter is causing the error. 

Please provide an ellisys log. 

Thanks,
Isaac

Dear Mr. Sakashita of the Technical Sales Department at Japan TI,
The information has already been distributed to you on 8/25 (Monday).

Please proceed to obtain it at your earliest convenience.

Best Regards,
Yukine

Hello Okita-san, 

After looking at the ellisys log, I understand what is happening. Within the feature exchange of the three sniffer logs you can see that the BLE dongle, and the Smart Phone support Connection Parameters Request Procedure. Note, in the feature exchange between the VH4110 and the CC2745R10-Q1, the Connection Parameters Request Procedure is not within the feature set. 

This section indicates " If the LL_CONNECTION_PARAM_REQ PDU was issued by the Link Layer of the Peripheral as a result of a Host initiated connection update procedure and the Central does not support this procedure, then the Host shall be notified that the connection update procedure has completed with the ErrorCode set to Unsupported Remote Feature (0x1A)" (Vol 6, Part B, Section 5.1.7.1). 

Since Connection Parameters Request Procedure is not within the feature set, GAP initiated connection parameter requests are not supported by VH4110. Because of this, the CC2745R10-Q1 stack will initiate a L2CAP connection parameters update (Vol 3 Part A section 4.20). 

Now after looking through the logs, I am confused on where you are sending a peripheral connection parameter update for all devices. For the VH4110 log, I don't see any connection parameter update from either central or peripheral. In the smart phone, I see only central connection parameter updates. For the BLE dongle, I also do not see any connection parameter updates. Were these logs captures captured at the correct time? 

Even if the 0x1A return code is seen, a L2CAP connection parameter update should be sent from the peripheral device, which the VH4110 will support if it is BLE complaint. 

When you are running this test, do you see any L2CAP connection parameter update over the air? If a peripheral connection parameter update was sent, and returned 0x1A, we should see a L2CAP connection parameter update in the ellisys log. 

Additionally, can you try just calling L2CAP_ConnParamUpdateReq() instead of GAP_UpdateLinkParam() when in a connection with the VH4110? 

Let me know if this works and thank you for your patience. 

Thanks,

Isaac

Hi,

> Were these logs captures captured at the correct time? 
Yes.

>  If a peripheral connection parameter update was sent, and returned 0x1A, we should see a L2CAP connection parameter update in the ellisys log. 
Does this fall under the GAP_UpdateLinkParamReq() API specification that "If this fails, the stack will automatically attempt an L2CAP parameter update request."?

Best Regards,
Yukine

Hello Okita-san, 

I was able to reproduce the problem on my side. The stack does not send an L2CAP connection parameter update if Connection Parameters Request Procedure is disabled on the central side. Additionally, I found that this issue was already reported. The fix has only been complete if the local device does not support GAP connection parameter updates. The fix was added into the latest SDK release (v9.11.01.19). 

I am working with our R&D team to fix the issue if the remote device does not support GAP connection parameter updates, but this will not be released for some time. I would recommend two options: 

1. Always use L2CAP connection parameter updates when working with the VH4110. The function was linked above (L2CAP_ConnParamUpdateReq()). 

2. Add a check within your code. If GAP_UpdateLinkParamReq() does not return success, then use L2CAP_ConnParamUpdateReq(). 

Let me know if this works for you. 

Thanks,

Isaac

Hi,

> GAP_UpdateLinkParamReq()

In SDK 9.10, for the following return values, will the behavior “If this fails, the stack will automatically attempt an L2CAP parameter update request.” be triggered?
・INVALIDPARAMETER
・bleIncorrectMode
・bleAlreadyInRequestedMode
・bleNotConnected

Best Regards,
Yukine