- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you please check my updates? I'm still struggling with this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All files and sniffs are sent to you, let me know if something is still missing.
Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Email sent over with the logs. Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello:
Is the ble device an Apple one ? from the log, I think the connection parameter will not comply with below setting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes , supervision timeout parameter can be raised up to have a try .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
not HFP, it is AFH .
For empty PDU you can find if you can disable LPM mode , low power mode.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
You can see that Wifi channel 7 is between roughly 2.430GHz - 2.4520GHz.
Now here is the BLE channel list:
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):
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I put RPi4 right next to the BLE device and it took 12 trials for CYW43455 before finally could connect to the BLE device.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
Failed connection: (packets marked until #82)
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?