We are currently using the Sterling LWB which uses the cyw43430 firmware version 188.8.131.52 and experience the following problem.
In our software application we are using bluetooth to continuously alternate between scanning passively (99% of the time) and connecting shortly (mostly <120 seconds) with a BLE peripheral, the application also requires a wifi connection to communicate with a central server. However, we noticed that during normal operation the wifi speed is highly affected by the bluetooth communication (average download speed of 20-50kbytes/s). If we disable the bluetooth communcation in general, download speeds up to 2 Mbyte/s are achieved.
Additionally, we've noticed the 'btc_mode' and 'btc_params' in '/lib/firmware/brcm/brcmfmac43430-sdio.txt' which can be tweaked for wifi and bluetooth coexistence. Sadly enough it is nowhere to be found what they mean.
One thing we've tested had a significant impact on the download and upload speed (however with reduced bluetooth stability). We've disabled (at least we think we did) bluetooth coexistence by setting 'btc_mode=0'. Disabling btc_coex improved the download speed which went up to 2 Mbyte/s, at the same time the bluetooth stability was reduced (i.e. time to set up connection increases + more failures). This seems similar to the 'BLE througput with coex enabled' test done in Coexistence Throughput Test. Though by disabling bluetooth coexistence we would expect everything to work very bad, but it did the opposite which seems very odd. After a while we did notice the following error which made the firmware unusable:
Oct 14 20:26:15 NODP-19-01111 kernel: brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x0004136C Oct 14 20:26:15 NODP-19-01111 kernel: brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 Oct 14 20:26:21 NODP-19-01111 kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout Oct 14 20:26:21 NODP-19-01111 kernel: brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x0004136C Oct 14 20:26:21 NODP-19-01111 kernel: brcmfmac: brcmf_sdio_checkdied firmware not built with -assert Oct 14 20:26:21 NODP-19-01111 kernel: brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle Oct 14 20:26:21 NODP-19-01111 kernel: brcmfmac: brcmf_do_escan: error (-110) Oct 14 20:26:21 NODP-19-01111 kernel: brcmfmac: brcmf_cfg80211_scan: scan error (-110) Oct 14 20:26:21 NODP-19-01111 wpa_supplicant: wlan0: CTRL-EVENT-SCAN-FAILED ret=-110
We've noticed this mailbox issue more frequent in 184.108.40.206 but was resolved by a newer release, though disabling bt_coex somehow triggers the error. In firmware version 220.127.116.11 we notice higher upload speeds but almost identical download speeds.
In addition I've added 2 boxplots showing download and upload speeds and bluetooth connection time (and a txt file with additional statistics). The speed is the result of an iperf test (over a 1 hour period) in kilobytes/s. The connect time is the time needed to set up a connection with a ble peripheral (in milliseconds).
The 3 boxplots mean following:
- btc_mode=0 -> firmware version 18.104.22.168 with bluetooth coexistence disabled
- 22.214.171.124 -> firmware version 126.96.36.199 without additions
- 188.8.131.52 -> firmware version 184.108.40.206 without additions
Additional tests that do not give significant changes:
- using btc_params used by RPI (firmware-nonfree/brcmfmac43430-sdio.txt at master · RPi-Distro/firmware-nonfree · GitHub)
- using bluez 5.50
- using laird btc_params (which are commented out by default)
- changing baudrate for brcm_patchram_plus (default value is 3000000) decreased gradually to 9600
The questions we currently remain unanswered are:
- what is the meaning of the btc_params ?
- does btc_mode=0 really disable coexistence or why do we achieve unexpected results?