Bluetooth LE connection attempt disables Wifi on RPi3

[mweal-ed]

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

[mweal-ed]

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

• the Rpi3 transmits a Null data frame with Frame Control - Power Management bit set to hold off wifi data while accessing bluetooth LE data.
• if the frame is not Ack'ed, the RPi3 resends the frame without the Power Management bit being set.
• the AP Acks the new Null frame.
• The RPi 3 Wifi goes to sleep
• the AP now transmits data to the RPi3 which ignores the data
• the situation escalates causing this SNAFU

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.

iperf3 -c 192.168.1.138 -l 32 -b 1K -t10000

sudo hcitool cmd 0x08 0x0d 0x60 0x00 0x40 0x00 0x00 0x00 0x11 0x22 0x33 0x44 0x55 0x66 0x00 0x0f 0x00 0x0f 0x00 0x00 0x00 0x84 0x03 0x01 0x00 0x01 0x00

[JamesH65]

Closing due to lack of activity. Reopen if you feel this issue is still relevant.

[pelwell]

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.

[pelwell]

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 (--interval=/-I and --window=/-W) to use different values. If there's anyone still on this thread who could spare 5 minutes to try the new hcitool I would be grateful for any feedback.

[mweal-ed]

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.

[pelwell]

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.

[mweal-ed]

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.

[mdrons]

What should the command be to test the new settings?

[pelwell]

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, iperf etc.

If you download the modified version to the pi home directory you can choose between the original and new commands by running hcitool ... or ~/hcitool .... The modified subcommands are lecc <addr> and leinfo <addr>. First of all, try:

$ hcitool leinfo 00:11:22:33:44:55

substituting the address of a BLE device you have. Connect using:

$ hcitool lecc 00:11:22:33:44:55
Connection handle 64

and disconnect with:

$ hcitool ledc 64

substituting the returned handle. You can then repeat the tests with ~/hcitool.

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 --interval=<m> and --window=<n>. The window is a fraction of the interval, meaning the window size (<n>) should be less than or equal to the interval (<m>).

hcitool leinfo... is equivalent to ~/hcitool leinfo --interval=4 --window=4 ... and ~/hcitool leinfo... is equivalent to ~/hcitool leinfo --interval=64 --window=8 .... For improved connection speed increase the window size, and decrease it for improved WiFi bandwidth. I would try window sizes of 4, 16, 32 and 64. There may also be a small difference if you halve both numbers (e.g. --interval=32 --window=4).

[JamesH65]

@pelwell Anything to report on this one?Did we ever get any more information from Cypress, or is it ongoing?

[pelwell]

I have a BlueZ hcitool patch waiting to go that stalled for lack of feedback (as you can see above).

[brianmichalk1]

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.
https://i.imgur.com/VCpkwor.png

[brianmichalk1]

I just walked out to the Pi doing the scanning. It is working and picked up my phone.

[tmigone]

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

[hamishcoleman]

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)

[brevilo]

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.

[k9gardner]

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.

[max17048]

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
Maybe this belongs