WL1831MOD: Bluetooth performance degredation with concurrent stream on WIFI

Hi,

Can you pls provide us with more details - is it Linux OS ? If yes, what version ? What is the version of WiLink8 driver ? Is WiLink8 running station or AP role ? What the is version of WiLink8 firmware ?

Saurabh 

Dear SN,

let me add the requested tech details for my colleague: This is a Yocto Linux build based on kernel version 4.9.87 (ARMv7 platform).
The drivers report the following module & firmware information:

wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
wlcore: loaded
wlcore: PHY firmware version: Rev 8.2.0.0.246
wlcore: firmware booted (Rev 8.9.0.0.89)

We are using R8.9 of the software suite with the
service packs  SRCREV=3aa1d75f3c2ae77f6e4d36194e3d281b899ab149,
firmware SRCREV=6c5ca87b9a912f09d090d5e1b6ace86d26718888
wlconf SRCREV=7325bf0b7b2d462e334437d2c7f9198d0ac55ce2

We have set up the module both with AP and P2P-GO roles, station mode is not an option due to connectivity & usability issues. We have a mobile phone sending audio over Bluetooth classic (either a media stream via A2DP or via the HFP protocol) via this module to a headset; any amount of Wifi traffic results in audible interruptions at the headset. We have set up a simple UDP sender to trigger this behavior.

Simon

P.S. let me add that this is a single-antenna configuration

Hi,

Are there any stations connected to DUT AP ?

SN

Hi Saurabh,

yes, there is exactly one station connected. Typically this is the phone that initiates the BT audio connection that subsequently tries to send data via Wifi.

We have broken the setup down to a minimal test setup -- audio dropouts occur any time a Wifi packet is received, cf. this python script:

#!/usr/bin/python3

import socket
from time import sleep

# Target system IP address (hosting the wl1831)
ip = "192.168.6.1"
port = 1234

len = 8
arr = []
for i in range(len):
        arr.append(' ')
buf = "".join(arr)

print ("sending | " + buf + "|")

sock = socket.socket(socket.AF_INET, # Internet
             socket.SOCK_DGRAM) # UDP
while True:
    sock.sendto(bytes(buf,"UTF-8"), (ip, port))
    sleep(0.1)
    print(".")

We have been running a signal generator app with a constant sine tone that makes dropped packets well audible.

Thanks a lot for the quick reaction,

Simon

Hi,

Which BT stack are you running on the linux host ?

For your reference : https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38?h=r8.8

Patches 0003/0004 apply to AP role. You may consider applying these to the driver.

SN

Hi,

we are running Bluez 5.62 ;

meanwhile I verified that the same problem occurs in STA mode, but I will try the patches and repot back asap

Thanks a lot

Simon

Hi,

We had fixed a WiFi/BT coex issue in firmware 8.9.0.0.86 : https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/tree/changelog

FYI - We support Bluetopia BT stack and use that for testing .

SN

Yes, we have seen that firmware update and are using the latest revision for our tests: Rev 8.9.0.0.89

The issues reported are still there.

I have also integrated the kernel patches that you suggested but this change does not make a difference, the audio problems are still there.

I have seen the Bluetopia stack, but switching to it is not an easy option - this product is already on the market, we are just working on a new feature. N.B. that Bluetooth alone is working as expected, it is just the Wifi part that is interfering.

It would be great ff you have any other suggestions, this is a real blocker for an otherwise very useful feature we're planning.

Simon

Hi,

Can you try changing beacon interval to 200ms in hostapd.conf and see it helps ? 

SN

Hi,

well, we have been trying different settings with no real solution - increasing the BI mainly results in routing errors on iOS devices (even at >=120ms), while audio outages pertained.

My colleague found a short presentation that highlights the coexistence approaches taken in the module - https://docplayer.net/10135987-Wilink-8-solutions-coexistence-solution-highlights-oct-2013.html

As far as I could see, the approach takes the periodic SCO traffic into account but focuses on the sending side. As our configuration acts as a bridge with incoming and outgoing audio streams, I wonder if there have been attempts to keep Wifi silent for the time-slots where SCO traffic arrives as well?

Simon

Hi,

We will look into your queries .

 - Can you please confirm if target is being configured ? section 4.1 : https://www.ti.com/lit/ug/swru561a/swru561a.pdf

- What channel is WiFi on ?

- WiFi TP is 10Mbps - UDP or TCP ?

- Host MCU/MPU ?

- Details of BT profiles being run ?

- Does it work better if you reduce WiFi TP ?

SN

Hi,

- yes, we have run configure-device.sh again after the software update

- Channel 1

- throughput target is 10Mbps; we started with TCP but resorted to UDP to eliminate response packets

- This is an ARM 7 - AT91SAMA5D2

- BT: the device supports the full audio glory - HS/HFP as well as AVRCP/A2DP; the tests are run using a single A2DP connection

- reduced Wifi TP: does not make a difference; we have noticable outages even when a device registers at the AP

I have recorded a few audio tracks locally to make sure the audio outages are already present when receiving the data, even without the receiving headset connected.

Simon

Hi,

Thanks for the response . We will review and get back to you 

SN

Hi Simon,

Are you able to post BlueZ application logs or Bluetooth air traffic during the poor audio quality? Do you happen to know what audio codec you are using?

Thanks,
Jacob 

Dear Jacob,

looks like the standard SBC codec is involved; I have put a short btmon dump to this place: btmon_noHS_wifi_traffic.dump

We had a look at the time-differences of incoming packets, as long as no Wifi traffic is involved this looks quite regular with a maximum of 0.05s difference between consecutive packets (x-axis is packet number, y-axis is seconds):

When we transfer data via Wifi in parallel at application-typical rates,  BT timing looks considerably different:

Simon

Hi Simon,

I was able to view your btmon logs but did not notice anything unusual. Do you know what bitrate you transmit the Bluetooth audio? I believe the max bitrate for SBC is 320 kbps. 

Do you notice an improvement in Bluetooth audio quality if you lower your Wi-Fi stream rate (maybe at 5 Mbps)? 

Thanks,

Jacob