We have moved to a new Sailfish OS Forum. Please start new discussions there.
14

Bug: Bluetooth LE scan kills WLAN connection

asked 2014-01-03 12:48:05 +0200

onion gravatar image

updated 2014-02-13 00:11:26 +0200

Doing a "hcitool lescan" kills WLAN connection.

edit retag flag offensive close delete

Comments

2

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 +0200 )edit
1

I 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 +0200 )edit
1

Some additional things I've noticed:

javispedro ( 2014-05-12 17:54:56 +0200 )edit
1

And here's a debug trace from the wlan driver http://depot.javispedro.com/jolla/ble/wlan-ble-trace.txt in the following scenario:

  1. WLAN associated to an WPA AP, pinging 192.168.1.1 every second, no other activity.
  2. On log mark START LESCAN I ran hcitool lescan. Ping replies start getting lost.
  3. On log mark STOP LESCAN, hcitool was Ctrl+C'd . Ping starts receiving replies back.
javispedro ( 2014-06-08 19:35:13 +0200 )edit

2 Answers

Sort by » oldest newest most voted
4

answered 2014-07-22 01:37:39 +0200

javispedro gravatar image

updated 2014-07-22 01:41:52 +0200

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.

edit flag offensive delete publish link more

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 +0200 )edit
3

answered 2014-01-05 21:18:25 +0200

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?

edit flag offensive delete publish link more

Comments

I'd be happy to test if I had such a device, unfortunately I don't.

onion ( 2014-01-18 12:38:42 +0200 )edit
Login/Signup to Answer

Question tools

Follow
9 followers

Stats

Asked: 2014-01-03 12:48:05 +0200

Seen: 1,380 times

Last updated: Jul 22 '14