Hello Internauts!
I have a motherboard with an Intel WiFi/Bluetooth combo wireless card so I started to use a wireless mouse again but this time using the internal Bluetooth instead of the usual proprietary receiver that usually wastes an USB port.
I think to understand why the majority avoid Bluetooth as mice protocol.
At the beginning I was quite disappointed, it worked erratically with frequent disconnections, even if I disabled the power-saving option1 and sometimes, after a disconnection, the mouse wasn't able to connect anymore.
Silly me, I didn't verified if there was a newer firmware for the Bluetooth stack, and yes after installing the latest version the mouse continues to turn itself off, but the update at least seems to have fixed the reconnecting problem and I'm not assuming all the times if the AA battery is depleted.
Another issue that I didn't found out immediately and not firmware related was the pointer horribly lagging when downloading something via WiFi on the LAN.
I tried to search something relevant on-line, but the issue seems a little too generic. At first I thought that being both services, WiFi and Bluetooth, on the same network adapter, maybe it was the result of a resource exhaustion or contention, like bus or the NIC CPU, even somewhat unreasonable with today's multi GHz and multi core CPU*s.
A more plausible hypothesis was a driver bug.
Scouring public mailing-lists and forum messages, I found out an option available on the WiFi Intel driver, bt_coex_active
, off by default. Yeah, I somewhat forgot that WiFi and Bluetooth2 share the same 2.4 GHz portion of the spectrum.
Coexistence is a somewhat ugly affair because the two technologies use the same medium but quite different protocols. In few words, FHSS (frequency hopping spread spectrum) used on Bluetooth consists on a signal transmitted on a narrow band but constantly "hopping" between different frequencies, while on WiFi is used DSSS (direct sequence spread spectrum) where the available spectrum is divided in bigger chunks of frequencies, so the Bluetooth signal that fall on the spectrum segment used by WiFi is seen as noise that in the best outcome requires packets re-transmission or, in the worst cases, a dropped connection.
Anyway, enabling the option eliminated the lag and I thought the case was closed, unless after a few days I found out that LAN WiFi connection was unbearably slow.
Yup, Bluetooth coexistence crippled the WiFi's bandwidth.
Pondering between an unusable lagging mouse or a frustratingly slow WiFi3, by the way I was leaning for the latter, I spotted arguments available with the bt_coex_active
option and started to experiment with them. I haven't tried all the combinations, but using the "enable agg TX" parameter it turns out that the bandwidth loss is lower than an acceptable 30% according to a few tests done with iperf3
.
So for the moment, I'm satisfied.4
For the records, the Intel WiFi card is the Dual Band Wireless-AC 3168 model.
I suspect the power-saving option is referred to the internal Bluetooth receiver ↩︎
and domestic appliances like wireless phones, garage gates/doors remotes, drones, also ignoring interferences by microwave ovens ↩︎
unfortunately, wired Ethernet isn't an option at the moment ↩︎
a better option could be using WiFi on the 5 GHz band, but for logistic reasons is not feasible at the moment ↩︎