CYW43455 - seems losing BLE packets

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

cross mob
DaKo_4725181
Level 2
Level 2

I'm using RPi4 (which utilizes CYW43455) for communicating with a BLE peripherial devices via gatttool:

# gatttool -b OTHERWORKINGDEVICE --characteristics
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb
...

I have at least 3 peripherial devices which I can query with gatttool.

But there is one device which timeouts 9 times of 10 during connection:

# gatttool -b NOTWORKINGDEVICE --characteristics
connect error: Connection timed out (110)

Now I could consider the "notworkingdevice" faulty. But "unfortunately" it is working from other devices (phones, with nRF Connect application) without any issues.

So I have hooked up a Bluetooth Link Layer Sniffer and took some measurements during the Pi tries to connect:M5jV2.png

Some legend:

  • Orange-filled box is the "faulty" device (BLE Peripherial)
  • Red-filled box is the Pi (BLE Central)
  • Red rectangles: marks channel change

I believe those Client Rx MTU requests are coming from the Peripherial (based on their Signal dBm).

However I tried running btmon on the Pi during the connection and it is simply not showing these MTU Requests. It seems Pi sends out a "LE Read Remote Used Features" and timeouts while waiting for the answer (I also tried increasing the timeout, but it did not help):

< HCI Command: LE Read Remote Used... (0x08|0x0016) plen 2 #11 [hci0] 7.477210
  Handle: 64
> HCI Event: Command Status (0x0f) plen 4 #12 [hci0] 7.479342
  LE Read Remote Used Features (0x08|0x0016) ncmd 1
  Status: Success (0x00)
> HCI Event: Command Complete (0x0e) plen 14 #13 [hci0] 7.479357
  LE Read Remote Used Features (0x08|0x0016) ncmd 1
  Status: Success (0x00)
  00 00 00 00 00 00 00 00 00 00 .......... 
> HCI Event: LE Meta Event (0x3e) plen 12 #14 [hci0] 7.993969
  LE Read Remote Used Features (0x04)
  Status: Connection Timeout (0x08)
  Handle: 64
  Features: 0x2d 0x00 0x00 0x00 0x00 0x00 0x00 0x00
  LE Encryption
  Extended Reject Indication
  Slave-initiated Features Exchange
  LE Data Packet Length Extension

I also tried to put the peripherial very close (<1.5m) to the Pi and nothing has changed.

RPi's firmware is updated, it's on 5.4.47-v7l+.

I took multiple sniffs and the communication is always the same: only requests, no response. The periperial tries to ask for MTU change but never gets reply. And the Pi is waiting for LE Read Remote Used Features but never gets reply and timeouts.

Given the above facts, what are my options to further investigate what causes the problem?

Is it possible to update the Cypress module itself? Or query it's version?

Thank you.

0 Likes
32 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

hello:

Did you try the interactive way to do the connection?  like:

gatttool -b D0:39:22:33:44:55 -I

then according the log, do :

connect

primary

characteristics

Hello,

Yes of course:

# gatttool -b NOTWORKINGDEVICE -I

[NOTWORKINGDEVICE][LE]> connect

Attempting to connect to NOTWORKINGDEVICE

Error: connect error: Connection timed out (110)

I did also tried with btgatt-client.

And my BlueZ version is 5.50.

0 Likes

Can you please check my updates? I'm still struggling with this.

0 Likes

Hello:

I can' t see the pics, Would you please help to capture two sniffer logs?

1.  43455 + other BLE device   ,  connection failed.

2.  other BLE client + other BLE device , connection succeeded.

I need to have a compare, and link key needs to be inputted for the logs also.

any other failed logs provided in 43455 side is better also.

0 Likes

and maybe you can have a debug to your connection setting like below :

echo ** > /sys/kernel/debug/bluetooth/hci0/conn_min_interval

echo ** > /sys/kernel/debug/bluetooth/hci0/conn_max_interval

connection interval,

slave latency

supervisor timeout

also can be modified to your failed device .

The same RPi (with 43455) can sometimes connect, but only 1/10 trials.

I have a sniff captured, with several failed attempts and then at the end one successful connection.

Also I have a parallel captured btmon log as well.

Could you tell me your email? I'd send you the raw sniffs (I don't want to share it publicly).

Thanks!

0 Likes

All files and sniffs are sent to you, let me know if something is still missing.

Thank you!

0 Likes

Email sent over with the logs. Thanks

0 Likes

hello:

  Is the ble device  an Apple one ?    from the log, I think the connection parameter will not comply with below setting.

pastedImage_0.png

0 Likes

Hi, it's not an Apple one, although it advertises itself as that.

The device has a Silicon Labs BLE chip, but I don't know the exact part.

Besides of that it would be useful to raise the supervision timeout to somewhere between 2 and 6 secs?

0 Likes

yes ,  supervision timeout parameter can be raised up to have a try .

0 Likes

I tried raising the supervision timeout, but it haven't changed anything.

Still timeouts at "LE Read Remote Used Features".

My connection parameters:

HCI Command: LE Create Connection (0x08|0x000d) plen 25

        Scan interval: 60.000 msec (0x0060)

        Scan window: 60.000 msec (0x0060)

        Filter policy: White list is not used (0x00)

        Peer address type: Public (0x00)

        Peer address: aa:bb:cc:dd:ee:ff

        Own address type: Public (0x00)

        Min connection interval: 30.00 msec (0x0018)

        Max connection interval: 50.00 msec (0x0028)

        Connection latency: 0 (0x0000)

        Supervision timeout: 5000 msec (0x01f4)

        Min connection length: 0.000 msec (0x0000)

        Max connection length: 0.000 msec (0x0000)

0 Likes

I just watched out wiced setting, the supervision timeout is set to 700 slots as default.

and would you please check the air log if your setting was really set into the connection ?

Well, btmon prints it wrong, I had to change the supervision_timeout value to 2400 to be exactly 3000ms, but I did it, and now on the sniffer radio it's also displaying:

3000_supervision_timeout.png

But it's still no good.

It only causes huge delay between connection request and timeout.

During this period, although btmon sees nothing, my sniffer radio captures enormous MTU request +Empty PDU replys (with channel change always).

So it seems remote device wants to change MTU, but RPi is not getting it to reply nicely. Maybe it's get lost in deeper levels.

What should be the next?

Thank you

0 Likes

Just a suggestion, you can capture the successful air logs to see connection parameters since you said some machines can connect with this LE device very well..   then we can set it to the same value , if still failed we can exclude the factors of the connection parameters.

Have you seen what I've sent you on email? In that sniff log there IS a successful connection at the end. From the same RPi device.

That's why I've sent you that file, and I've also sent description.

Please see it.

Thank you

0 Likes

That sniff file contains 4-5 trials from RPi -> BLE device which ends with timeout, and then a successful trial which succeed from RPi -> BLE device.

I have not changed anything during the trials, gatttool was put into a loop. But the script is also attached in the message I've sent.

0 Likes

Can you tell me if "Empty PDU" packets are sent by BlueZ or Cypress chip directly?

I.e. Empty PDU is sent automatically by Cypress chip, to keep the connection open? Or it is sent for a request from BlueZ?

Thank you!

0 Likes

Hi, also one more thing:

Is it somehow possible to disable channels for the Cypress chip?

I.e. I want to allow only channels above 30. How am I supposed to do that?

Thank you!

0 Likes

It seems there are channels which are mostly works, and there are other channels which seems never working.

Is it possible to check and update the firmware of the Cypress chip on RPi4?

maybe it's obsolete as it seems handling channel switching in a very ineffective way.

Thank you

0 Likes

Hello:

   Empty PDU is the packet to keep the link.  and it is not a good way to post RPi4 here ,  and how you confirm the HFP channels are fixed into some channels,  if so , you can find a clean environemt to see if the connection can be built up with big possibility .

0 Likes

Ok, thank you.

So Empty PDU is sent (initiated) by Cypress firmware, or BlueZ?

I.e.: am I have a chance to change BlueZ to send Empty PDUs different than now, or it is handled by Cypress's firmware?

0 Likes

Clean environment is something we are just dreaming of.

If there is clean environment we would not need AFH (Adaptive Frequency Hopping) at all.

(By the way what is HFP? Google drops me Hands-Free-Profile all the time)

0 Likes

not HFP, it is AFH . 

For empty PDU you can find if you can disable LPM mode , low power mode.

0 Likes

Ok, we are not on the same track.

Look, I think I found the problem. You can help me to solve this:

I will write down everything in detail:

I am trying to connect to a BLE device (let's name it DeviceA) from a RPi4 which has an onboard CYW43455 (let's name this DeviceB).

From DeviceB->DeviceA, connection usually ends with timeout, but sometimes succeeds.

All the neccessary logs were sent via email to ZhengbaoZ_96.

Let's introduce a new device (my phone, let's name it DeviceC).

From DeviceC->DeviceA, connection always succeeds.

There are lot's of traffic on 2.4GHz around me. Normally, BLE chip can not know in advance which channels are good and which channels should be disabled. But Cypress is a Wlan+BT chip, so it can (should!) exactly know which channels are bad for BLE.

To test this, I have enabled the Wifi and connected to my Access Point (AP) on DeviceB with the Cypress CYW43455.

My AP is using Wifi channel 7.

You can have a look on wifi channels if you are not familiar:

fig%201.png

You can see that Wifi channel 7 is between roughly 2.430GHz - 2.4520GHz.

Now here is the BLE channel list:

BLE-vs-WiFi-1-6-11-channels-and-spectrum-12.png

This is a bit tricky, there is 2MHz between BLE channels although only start (2402) and end (2480) are marked.

Believe me, Wifi channel7 can be mapped roughly onto between BLE channels 12-20.

Now with this Wifi connection I tried to create a BLE connection, and Cypress chip was able to select the WORSE channel hopping combination of all: BLE channel#12 then hopped to #18, which is almost the exact middle of the used 7th Wifi channel:

(You can see the used BLE channel on the column named "RF Channel"):

(And you can also see that Cypress is not disabling any of the channels):

channels.png

Now here comes a serious question (and I'd be extra happy if you can answer it):

Is there a way to force Cypress CYW43455 to not use BLE channels that are already used by its Wifi?

(I know that Cypress might have some BT+Wifi coexistence implemented in the chip, but as my AP provides Wifi on this channel, it will be jammed if Cypress tries to create BLE connection on these channels).

Thank you very much in advance.

0 Likes

thanks for the share,   yes, I know the channel frequency map.

that's why I suggested a clean environment (even this environment is not clean enough , I test the BLE connection in my office, it was always successful with wifi AP nearby)to confirm it is due to environment noise.

and if your AP is in channel 7 , you can change the channel to a different one to see if it has influence to the connection. 

0 Likes

I've completely disabled my AP, and it took 50 trials for CYW43455 before finally could connect to the BLE device.

This is insane. It seems we are going nowhere.

I'll try to put RPi to close (2cm) to the BLE device and retest. If it still won't connect I drop it into the dustbin and never ever think about buying it.

0 Likes

I put RPi4 right next to the BLE device and it took 12 trials for CYW43455 before finally could connect to the BLE device.

0 Likes

thanks a lot for your info,   Does your board have an external antenna point ? if so , I think you can try a 2.4G antenna to see if it can improve.

That's something I'm not able to try at the moment, RPi4 does not have external antenna connector by default and my antenna stuff is not with me, so I think we have to wait.

Maybe it's all is just a really bad antenna design of the RPi4. Luckily they don't provide any specifics for their designs anymore like measurements, external antenna options, etc.

But there is possibility to solder an external connector onto it just I need time for that.

0 Likes

Is the CYW43455's Wifi subsystem helping to select the usable BLE channels?

This is a major difference I'm seeing: when I connect to the problematic device from my phone, it disables some BLE channels (which is used by Wifi).

How CYW43455 can do the same?

0 Likes
DaKo_4725181
Level 2
Level 2

I dig deeper, and created a sniff which includes failed connection attempts, and one successful connection (from the same RPi).

Please see the two images below:

(I marked the packets with black which were sent by RPi (I believe this based on packets' RSSI), and red circles are where channel is switched)

Successful connection: (packets marked until #207)

aEAs0ql.png

Failed connection: (packets marked until #82)

tksry4u.png

If my assumptions on the packets are correct, the question is, why RPi is not sending "Connection parameter update request".

Moreover it seems stucking in a state of requesting the MTU forever (until the whole connection times out).

BlueZ or Cypress chip does not handle well if there is a channel change right after the MTU request?

0 Likes