Bug: Bluetooth LE scan kills WLAN connection
asked 2014-01-03 12:48:05 +0300
Doing a "hcitool lescan" kills WLAN connection.
2 Answers
answered 2014-01-05 21:18:25 +0300
I've pushed this towards the hardware adaptation guys, will let you know if we find a fix. Anybody up for testing this on a comparable Qualcomm android device?
Comments
answered 2014-07-22 01:37:39 +0300
I think I know how to workaround this. The problem seems to be in the values of the LE_Scan_Interval and LE_Scan_Window parameters (during the LE Set Scan Parameters HCI command). The default values of 10ms and 10ms cause the wlan interface to die, but lighter scanning duty cycles (e.g. 100ms and 30ms) seem to keep the wlan interface alive!!!
Sadly those parameters can't be changed from hcitool so for now I have to experiment with my test programs.
Scan_Interval = 10ms, Scan_Window = 10ms (the default value and the one used by hcitool). According to standard this should be "continuous scan". Using these values interrupts wlan functionality, but it is restored as soon as one stops scanning.
Scan Interval = 60ms , Scan Window = 30ms . This is what the Proximity Profile recommends to use IF the device that's scanning wants to perform additional tasks. However, in my Jolla at least, when I set these values and initiatiate a scan the wlan interface dies completely until next reboot. No idea why. So it is unusable.
Scan Interval = 100ms, Scan Window = 30ms. This seems to WORK flawlessly, does not even cause WLAN ping spikes. It does not seem to significantly impact BLE scan performance, so I think these may be usable as new defaults and call the bug closed.
Comments
2
Thanks for the good analysis javispedro. Makes sense that WLAN gets starved during continuous scan, but wlan problems with 60/30 would need to be examined further.
Any chance you'd be willing to write e.g. a patch for specifying interval and window on hcitool command line and sending it to BlueZ upstream from where it could be cherry-picked to Mer?
hmallat ( 2015-01-30 17:05:02 +0300 )editStats
Asked: 2014-01-03 12:48:05 +0300
Seen: 1,367 times
Last updated: Jul 22 '14
Does trying to connect to a bluetooth headset also kill the WLAN connection? If so, my bug is related to this. Connecting a bluetooth headset while connected to WLAN disconnects both WLAN and bluetooth.
Disconnecting the WLAN before connecting the bluetooth makes it work, reconnecting it one by one.
fawz ( 2014-01-04 17:51:34 +0300 )editI can only add that actually connecting and transmitting to a BLE device does not seem to cause any effect on the WLAN connection. It's just scanning -- and both active and passive scans cause it.
javispedro ( 2014-01-17 00:35:40 +0300 )editSome additional things I've noticed:
javispedro ( 2014-05-12 17:54:56 +0300 )edithcetool lescan kills WLAN connection but only right until it's terminated. After that, WLAN works OK.
test-mw( https://gitorious.org/gato/test-mw ) does a scan plus connecting, and for some reason it kills WLAN connection even after being terminated. WLAN only recovers after bluetooth is powered down (using e.g. settings). Also, it leaves the following records on dmesg: http://depot.javispedro.com/jolla/ble/wlan-ble-dmesg.txt
And here's a debug trace from the wlan driver http://depot.javispedro.com/jolla/ble/wlan-ble-trace.txt in the following scenario:
- WLAN associated to an WPA AP, pinging 192.168.1.1 every second, no other activity.
- On log mark START LESCAN I ran hcitool lescan. Ping replies start getting lost.
- On log mark STOP LESCAN, hcitool was Ctrl+C'd . Ping starts receiving replies back.
javispedro ( 2014-06-08 19:35:13 +0300 )edit