Skip to content
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

Open
mweal-ed opened this issue Apr 28, 2016 · 15 comments
Open

Bluetooth LE connection attempt disables Wifi on RPi3 #1444

mweal-ed opened this issue Apr 28, 2016 · 15 comments

Comments

@mweal-ed
Copy link

@mweal-ed mweal-ed commented Apr 28, 2016

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
Copy link
Author

@mweal-ed mweal-ed commented May 12, 2016

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
Copy link
Contributor

@JamesH65 JamesH65 commented May 18, 2017

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

@JamesH65 JamesH65 closed this May 18, 2017
@pelwell
Copy link
Contributor

@pelwell pelwell commented Aug 9, 2017

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 pelwell reopened this Aug 9, 2017
@pelwell
Copy link
Contributor

@pelwell pelwell commented Jan 8, 2018

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
Copy link
Author

@mweal-ed mweal-ed commented Jan 8, 2018

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
Copy link
Contributor

@pelwell pelwell commented Jan 8, 2018

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
Copy link
Author

@mweal-ed mweal-ed commented Jan 8, 2018

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
Copy link

@mdrons mdrons commented Jan 8, 2018

What should the command be to test the new settings?

@pelwell
Copy link
Contributor

@pelwell pelwell commented Jan 8, 2018

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
Copy link
Contributor

@JamesH65 JamesH65 commented Jun 28, 2018

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

@pelwell
Copy link
Contributor

@pelwell pelwell commented Jun 28, 2018

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

@brianmichalk1
Copy link

@brianmichalk1 brianmichalk1 commented Aug 9, 2018

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
Copy link

@brianmichalk1 brianmichalk1 commented Aug 9, 2018

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

@tmigone
Copy link

@tmigone tmigone commented Jan 20, 2020

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
Copy link

@hamishcoleman hamishcoleman commented Sep 24, 2020

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.