CC2642R-Q1: Channel Selection Algorithm #2

Hi, Shuyang

Whether or not CSA #2 is used for the connection depends on what is supported on the peer device. If CSA#2 has been disabled by peripheral, the CSA#1 should be used by central device. Is there an Ellisys sniffer file? You can check the Chsel field of the connection indication packet and the LLCP feature exchange process for CSA information.

Regards,

Kevin

Hello Shuyung, 

Kevins comment is exactly right. An Ellisys log will show the CSA of the advertisement packets, and the CSA of the connection indication packet. Please verify using this method. 

Make sure the CSA is selected before advertising or initiating. If the CSA is changed during advertising/initiation, the CSA will not update from CSA set before. Please refer to Disabling CSA #2 in the User's Guide for more information. 

Thanks, 

Isaac

Hi Isaac,

Please find a sniffer log for this issue, the file can be opened with blueSPY software.

0703_resetok.pcapng

From the sniffer log, we can see the Adv PDU is using CSA#1, but the CONNECT_IND is using CSA#2:

My question is if this behavior compliant with BLE spec?

To add more background, the customer is reporting this because they saw 0x3E disconnection. Besides the channel selection, is there any other reason that could cause 0x3E?

Best regards,

Shuyang

Hello Shuyang, 

I apologize for the delay, need additional time to give you a response. There are some gaps here that I am attempting to address. I will have a response for you Thursday (07/11). 

In terms of the disconnection (0x3E), I am unsure. I cannot seem to open the PDU in blueSPY, so I cannot give an answer until I figure that out. 

Thanks, 
Isaac

Hi Shuyang,

Shuyang Zhong said:

Which one is correct? Is it legal for the central device to use CSA#2 when it is not supported by peripheral?

Both of the two sections are correct. In terms of final behavior, it is not correct for the central device to use CSA#2 when it is not supported by peripheral.

Shuyang Zhong said:

In BLE core spec 5.3, there are two sections which look contradictory about CSA#2. In Vol 6, Part B, 2.3.3.1 it says that the initiator may set the ChSel field to 0 or 1 in case of the initiator supports CSA#2 but the advertiser does not:

I guess the only thing that's confusing in section 1 is: The initiator may set the ChSel filed to 1 when the advertiser does not support CSA#2.
On this condition, the advertiser should set ChSel filed to 0. At this point, the statement in Section 2 is still valid, so these two sections don't contradict each other.

The advertiser always uses CSA#1,but the initiator use CSA#2 in its CONNECT_IND packet, they don't communicate in the same way, This is why they cannot establish a connection and cause disconnection 0x3E.
Now let's analyze why ADV_IND is using CSA#1, but the CONNECT_IND is using CSA#2 in sniffer log.

Shuyang Zhong said:

From the sniffer log, we can see the Adv PDU is using CSA#1, but the CONNECT_IND is using CSA#2:

The cause should be an issue with the processing of ChSel filed in the ble stack. The receiving device should set ChSel to 0 and ignore it when using CSA#1. It should not be set according to the ChSel file of the rx pdu, because the ChSel filed is RFU bit before core spec 5.0.

if the initiator set the ChSel filed to 0 when the advertiser does not support CSA#2, the CONNECT_IND will use CSA#1. It seems that NXP's device did not set the ChSel filed to 0, although NXP is core spec compliant, but it is best to set the ChSel to 0 in this case.

Here is the sniffer log of CC2652 using CSA#1 and mobile phone using CSA#2, they can communication normally, and the CONNECT_IND is using CSA#1.

(Strangely, why I can't add a sniffer attachment here)

Regards,
Kevin

Hi Isaac,

The empty packets were filtered in the settings of blueSPY, please enable the empty packets button then you can see there were 6 empty packets after CONNECT_IND:

And the customer added a debugging GPIO in GAP_LINK_ESTABLISHED_EVENT, it appeared this event is not entered when the issue happened.

The customer also observed that there was a ADV_IND shortly after the CONNECT_IND when the issue happened, but no ADV_IND was seen after a successful connect(the last connection in the sniffer log was successful).

Best regards,

Shuyang

Shuyang, 

Thank you for the response. After seeing the empty packets, we will need to re-evaluate our response. Expect a response early next week.

I apologize for the inconvenience. 

Thanks, 

Isaac