-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluetooth LE connection attempt disables Wifi on RPi3 #1444
Comments
I have been doing a little more research into this. It believe the rpi3 wifi drivers use power management (even if it is disabled) to hold back wifi data while access bluetooth low energy data. However there seems to be a bug with the RPi3 where
To look at the condition on wireshark (air sniffing from another machine) without quite as much traffic I did the same test as previously indicated, but I reduced the traffic and extending the bluetooth scan periods/increased the %of bandwidth available to wifi by changing the "iperf3 -c" and hcitool commands. Note: the hcitool cmd is a manual entry of lecc with the scan window and interval changed. I have tried this with both a Cisco/Linksys E1200 and ASUS RT-N12 Router.
|
Closing due to lack of activity. Reopen if you feel this issue is still relevant. |
I can confirm that this issue is still relevant. Cypress are aware of it, and improvements to BT+WiFi coexistence are planned, but they have been focusing on the recently discovered vulnerabilities. |
Cypress have responded with a suggestion to modify the HCI window and interval parameters for leinfo and lecc. The BlueZ hcitool utility hard-codes these both to 4, which essentially leaves no time for WiFi traffic. I have a modified hcitool that changes the defaults on Broadcom Bluetooth devices to 64 for the interval and 8 for the window, and adds extra command line options ( |
Its been a while, so I can't remember the details, I did some similar experiments as part of the testing above (the odd hcitool cmd set the interval/window). If I remember correctly this helped some but did not 100% solve the problem. I did not follow up any further on this because in my case even if it did work, it was not suitable. I was working with a bluetooth device that advertised every 10 seconds, so if I allowed more time to the wifi (and less to blueetooth) it extended the connect time too much. I am still working with an usb wifi dongle to get around the problem. |
Fair enough - thanks for replying. I don't know if this level of contention/interference is common to all single-antenna WiFi/BT combo systems, but when the device manufacturer's advice is to degrade BT performance like this then I think we're looking for the least worst compromise. |
I have encountered the same problems on other platforms that have shared hardware for wifi/bluetooth (Intel Edison and Next Thing CHIP). I know the Edison also uses a Cypress/Broadcom chipset, but I'm not sure about the CHIP. |
What should the command be to test the new settings? |
Good question. The aim is to see how BLE connections interfere with WiFi traffic, so it would be good to have some way of measuring WiFi bandwidth - an internet speed tester, file download, If you download the modified version to the pi home directory you can choose between the original and new commands by running
substituting the address of a BLE device you have. Connect using:
and disconnect with:
substituting the returned handle. You can then repeat the tests with If you are very keen, or if you find that connection takes too long using the new command, try changing the window and interval values using the command line parameters
|
@pelwell Anything to report on this one?Did we ever get any more information from Cypress, or is it ongoing? |
I have a BlueZ hcitool patch waiting to go that stalled for lack of feedback (as you can see above). |
I am having problems with Wifi and BT scans. See my attached chart of wifi pings vs legacy bluetooth scans. I downloaded your new hcitool, and do not see any degradation in wifi performance. I did not discover any Bluetooth devices, so I'm not certain the scan is working. |
I just walked out to the Pi doing the scanning. It is working and picked up my phone. |
Hello, it's 2020 and still having this issue unfortunately. Does anyone have up to date information on this topic? Any pointers or ideas worth exploring? @pelwell happy to help troubleshooting |
I have observed the same issue on a Raspberrypi Zero W. (I can see that this ticket has no traction, so this is just recording another voice of frustration) |
Same here on a Pi 3B. Any Bluetooth activity (not just LE) causes packet drops on WiFi. I disabled WiFi power management to improve the WiFi stability and now noticed that instead my Bluetooth connection fail left and right (due to the shared antenna). This really needs fixing on the Cypress level. Right now BT and WiFi just can't be used simultaneously. |
My 2¢ worth on this: sadly I deployed BalenaSound on my RPi 3B+ instead of the 4, and I was faced with that stuttering problem. Usually takes about 20-25 minutes of connect/play time for it to start acting up. Everyone talked about mitigating the problem with an external BT dongle, but I kept wondering why not disable wifi and use Ethernet and see if that solves it as well. I finally configured it this afternoon. I had one occurrence of the stutter problem, but I’ve been continuing to test, streaming for over 30-40 minutes and it hasn’t happened again yet. I’m not sure if this as good a solution or not but it seems to help. |
Check issue #3727 |
I have been able to isolate this down a simple low level test cases test case to show the conflict if this helps any
When I attempt to make a connection to a a bluetooth LE device and the connection does not establish (or the device does not exist), wifi is disable (or has >99% packet loss) while the bluetooth LE connection is being attempted.
On one RPi3 (#1) I have a window with iperf3 running
iperf3 -s
on another RPi3 (#2) I have a window with with iperf3 running with a connection to RPi3 #1
iperf3 -c 192.168.1.138 -time 100 -u
Everything works fine (RPi3 #1 shows it is receiving udp packets) unit I open another window on RPi3 #1 and attempt to connect to a non existent device
sudo hcitool lecc 11:11:11:11:11:11
Note: bluetooth LE will continue to attempt the connection even after hcitool returns with a timeout error.
RPi3 #1 iperf3 now shows it is dropping packets (0 data rate). After terminating the BLE connection attempt with an LE Create Connection Cancel Command things resume normally
sudo hcitool cmd 0x08 0x0e
I have tried this with "ping" instead and packets seem to get through
I have tried this with both "ping" and "iperf3" together, and there are a lot of dropped pings (and the one that do make it are very long... 10, 20, 30 seconds)
Looking at the data on wireshark I see the occasional packet is making it through... but very few.
this may be related to #1402
The text was updated successfully, but these errors were encountered: