Establishing BLE connection with windows 10 unreliable

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
thbr_4732196
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello,

I am using a CY8C6347BZI-BLD53 and ble connections are working well with iOS and Android clients. However, establishing a BLE connection with windows is unreliable; sometimes it works, some times it doesn't. I've used a protocol analyzer to capture the BLE traffic while establishing a connection with windows and have found that when a connection doesn't work, the PSoC6 doesn't acknowledge the LL_FEATURE_REQ sent by the windows radio and the windows radio retransmits that packet until the connection times out. What could cause this behavior?

I've attached a couple of screenshots of the packet trace showing the issue. Frame 8,308 is the connection indication and it is immediately followed by the LL feature request on frame 8,309. Frame 8310 doesn't acknowledge frame 8,309 and then it gets retransmitted a lot of times, never being acknowledged by the PSoC6. I'm happy to upload the full packet trace to a non-public forum, it contains both successful and unsuccessful connections.

Thanks,

Theo

0 Likes
1 Solution

Hello,

The issue seems to be on windows side. From your logs, it has shown the follow:
1. Frame 3866: Windows sends LL_FEATURE_REQ in a PDU with SN 0, NESN 0 on channel 32.
2. Frame 3867: PSoC 6 Acknowledges the packet from Windows with an empty PDU with SN 0 and NESN 1 on channel 32.
3. Windows seems to ignore this empty PDU and re-sends same LL PDU in frame 3686 on channel 32.
4. Then in the next connection event, windows radio again sends the same packet, we acknowledge the packet again, but windows ignores our acknowledgement.
PSoC 6 will continue to acknowledge the LL PDU using the empty PDU and will not send a new packet untill windows radio acknowledges PSoC's empty PDU.

Similarly, from the images which you attached, in frame 8310, PSoC 6 is acknowledging the LL PDU, so frame 8310 acknowledge frame 8,309. In fact, Frame 8311 doesn't acknowledge frame 8,310.

Thanks,
P Yugandhar.

View solution in original post

0 Likes
9 Replies
Yugandhar
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 5 likes given

Hello,

Could you please let us know the built version of the Windows which you are using ? 

Also,  could you please check with the 'BLE_FindMe' code example from the PSoC Creator and let us know the observations. 

Note: Use the latest BLE component and PDL in the project. 

Thanks,

P Yugandhar.

0 Likes
lock attach
Attachments are accessible only for community members.
thbr_4732196
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hi,

Thanks for your response. My windows build version is:

OS Name Microsoft Windows 10 Pro
Version 10.0.19042 Build 19042

Yes, I can reproduce this issue with the BLE_FindMe with the CY8CPROTO-063-BLE and the latest PDL (PDL 3.1.4 with BLE PDL 2.20). I have attached the packet trace. The problem occurs with the connection starting on frame 3865. The PSoC6 does not respond to the LL_FEATURE_REQ sent in frame 3866 and the packet is retransmitted until the connection timeout.

Please let me know what you think.

Thanks,

Theo

0 Likes
thbr_4732196
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Any updates on this? Is investigation in progress? Thanks!

0 Likes

Hello,

Could you please let me know the BLE dongle details which you are using at the Host side ?

Thanks,

P Yugandhar.

0 Likes
thbr_4732196
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

I'm not using a BLE dongle, the Bluetooth hardware is an  Intel® Wireless 9560 WIFI/BT5.1 in a Lenovo X1 Carbon 7th generation.

0 Likes

Hello ,

You have to use the Cysmart BLE dongle to make connection between PSoC6 BLE and PC.  Please refer to the CY5677 CySmart dongle from the link for more information.

For BLE HID projects, you can directly connect through windows bluetooth settings. 

Thanks,
P Yugandhar.

0 Likes

No, I don't believe this is the issue.

Perhaps I was unclear about how I was testing the connection with the findme example. I was using the Microsoft Bluetooth LE Explorer to establish a connection with the PSoC6 device running the findme example. This is using standard ble communication to connect, and discover services. Sometimes this connection and service discovery was successful, other times it was not. The unsuccessful tests were because the PSoC6 did not acknowledge a packet sent in by Windows, as shown in the BLE packet trace I sent earlier in the this thread.

If you are saying that the PSoC6 is not expected to connect to windows, please explain the part of the bluetooth specification that the PSoC6 is not conforming to (or windows is not conforming to). Otherwise, I think this needs to be escalated to an engineer with knowledge of the BLE stack internals to analyze the trace and figure out why the PSoC6 didn't send an acknowledgement.

Thanks,
Theo

0 Likes

Hello,

The issue seems to be on windows side. From your logs, it has shown the follow:
1. Frame 3866: Windows sends LL_FEATURE_REQ in a PDU with SN 0, NESN 0 on channel 32.
2. Frame 3867: PSoC 6 Acknowledges the packet from Windows with an empty PDU with SN 0 and NESN 1 on channel 32.
3. Windows seems to ignore this empty PDU and re-sends same LL PDU in frame 3686 on channel 32.
4. Then in the next connection event, windows radio again sends the same packet, we acknowledge the packet again, but windows ignores our acknowledgement.
PSoC 6 will continue to acknowledge the LL PDU using the empty PDU and will not send a new packet untill windows radio acknowledges PSoC's empty PDU.

Similarly, from the images which you attached, in frame 8310, PSoC 6 is acknowledging the LL PDU, so frame 8310 acknowledge frame 8,309. In fact, Frame 8311 doesn't acknowledge frame 8,310.

Thanks,
P Yugandhar.

0 Likes

Hello,

Thank you for your analysis, the SN and NESN sequence does point to an issue on the Windows side as you describe. I was misled by the "retransmission status" reported in the WPS interface, this is a good reminder to just look at the raw data.

I'll relay this information on to our contact at Microsoft and see if they can root cause on their side.

Thanks,
Theo

0 Likes