I constantly have to forget devices, turn them off and on again etc. I have regular drop outs and I’m forever trying to re-pair.
This is across connection types (keyboard, music etc), brands and devices.
Why is Bluetooth in general so flakey?
... Which is made clearer by the fact that the Bluetooth specification is:
+ Enormous. Even just the core spec, that doesn't include much of what the consumer is interested in, is around 3000 pages long. That's not a typo. 3000 pages to tell you how to make two devices do a handshake. Add in the things that make our devices actually work... And you're asking the software to match what has been written and defined across closer to 5000 pages. Nothing is going to perfectly match between implementations.
+ Badly defined. The original working group that made Bluetooth left behind so much because they couldn't agree on it that it has more "Undefined Behaviour" footguns than C ever did.
One example of some spec text that I've seen argued differently between implementations:
> There is no requirement for the application to insert additional framing information into the data, although it may do so if this is required
That's before we get to the actual real world problems that Bluetooth has to face and overcome, like being in the 2.4Ghz range and being a frequency hopper.
WiFi Direct (which is also somewhat horrible, but somewhat less), is also a competitor in this area. It hasn't seen a lot of adoption, but there are a few things that use it.
Apple's AirDrop is also a proprietary protocol that can handle a lot of this peering stuff, atop WiFi, and they seem pretty committed to keeping it around for all their stuff for the foreseeable future.
It never really had much of a chance though because BLE support was sort of added to phones for free as part of Bluetooth. With Zigbee (or ANT or Thread) you'd have to add a new chip, which phone manufacturers aren't going to bother with for a tiny market (though I think there are a very small number of phones with ANT support).
I don't know if manufacturers have got their shit together in more recent smartphone generations, but at the time every manufacturer had their own Bluetooth stack with undocumented, and sometimes conflicting, quirks. Manufacturer A requires that you pair to a device before connecting? Great, Manufacturer B won't pair unless you connect first.
The only way we could guarantee compatibility with the app was that we tested at least one phone from every manufacturer so could flag which workarounds had to be used for each device. Some manufacturers were at least consistent with themselves, but others had totally different stacks between devices and even android versions.
This was definitely a huge point in Apple's favour; iOS' Bluetooth was snappy and consistent, and I was forever jealous of our iOS dev doing the integration over a few days when it took me at least a month to work all the links out.
And then a manufacturer releases a new hot android phone and we get a complaint from our client that their app is suddenly awful because it didn't work out of the box.
No, I'm not salty at all. :/
One example: Until very recently the default connection timeout was 20 seconds. There was no way to change it. 20 seconds! Such a shockingly bad user experience. The default on iOS is something like 0.7 seconds.
Several years after reporting this issue they "fixed" it - by changing the hard-coded timeout to 5 seconds. Like, yeah that's better I guess, but I think you're missing the point.
Just in general Android's bluetooth stack was way buggier and less reliable than iOS's. There were entire classes of products (mostly proximity-based stuff) that we tried to make that worked perfectly on iOS but were effectively impossible on Android because it was so janky.
I have had other bluetooth headphones where sitting down at the computer means I first have to go find my phone and disable Bluetooth to use them with my computer. Where I have to go through the menus to connect them every single time For every device. But AirPods “just work”. Sit at my computer? They connect straight away no action from me, just my magic when I put them in. Walking around with my phone? They just connect (and show battery status) just when I put them in. It’s simple and effortless. That couldn’t have been an easy feat considering everyone else on the market are failing at this and have been failing at this for pretty much every Bluetooth device for more than a decade.
IMO they work great when new but slowly as you add devices, or whatever, they get worse and worse. And since there are no buttons, if it decides to just connect to one airpod, you're screwed until you can throw them back in the case to 'reset' them or whatever. Once you take an airpod out of its case, it either seems to connect properly, or not, but if not, it's game over.
I took my airpods out the other day for a run. they must have connected to my computer because my phone refused to connect to them.
Doesn't matter how many miles i run from my computer, but they will never connect to my phone until i can put them back in their case and take them out again.
Finally reset the whole thing and they SEEM okay.. I'm intending to maybe just keep my old airpods (<1h battery life) for conference calls, and the new ones for running.
But anyway, far from perfect.
RECON 2019 - Reversing and Exploiting Broadcom Bluetooth (Jiska, Dennis Mantz) https://www.youtube.com/watch?v=96Mi8_9ABCc
35C3 - Dissecting Broadcom Bluetooth (jiska mantz) https://www.youtube.com/watch?v=4_nI9ok7iQg
2. For low power devices like Bluetooth, even worse than that.
3. Bluetooth is a frequency hopper. Frequency hoppers have all sorts of synchronization problems. That plays havoc with link maintenance algorithms.
3b. Distributed link maintenance with no central control is a hard problem.
4. The people that designed the original spec didn't know what they were doing.
5. The baseband spec is very complicated. And thus hard to get right on all cases. And there are multiple layers each with a different party responsible for implementation.
6. Bluetooth devices are designed by groups working for a large number of manufacturers none of whom have license to help each other.
Items 1-3 explains why Ethernet tends to just work and Wifi/Bluetooth kinda sucks.
Item 4 explains why Wifi works better than Bluetooth.
Items 5-6 explains why your cell phone generally just works even though it uses RF.
The second thing is that much of the low level firmware for the stack is closed source stuff that is written in house. I suspect, after working with some of that shit, that it's poorly done and is a major cause of unreliability. Don't know if it would make any difference if it was open sourced, because the hardware/software combo is a lot like what you see with graphics cards. Everyone has their own secret sauce and they don't want to show it to the world.
I think WIFI chipsets hit $5 before Bluetooth ones.
Reminds me of a problem with how people think of 'low power RF'. You don't actually care so much about continuous current draw (within reason) what you care about is energy per bit. Which means high bandwidth doesn't penalize you as much as you would assume. Bonus in practice the longer your packet takes to transmit the higher the chance it gets clobbered. Bluetooth going with a low bandwidth low continuous power radio; FAIL.
That's why they chose a GFSK frequency hopper. Which ignored the expected advances in low power spread spectrum radio's. Previously the power requirements for a spread spectrum receiver were way too high, but within a two years of releasing the spec power requirements dropped dramatically. RF chip designers new this was going to happen.
Same time their baseband requirements were almost impossible to meet with a low power budget even in 2003 or so. So you had a crummy GFSK radio, frequency hopper. Married to a fat piggy baseband spec.
What I remember is about two dozen design groups spent a couple of years developing Bluetooth hardware and by 2004 or so exactly three of them succeeded. That's big indictment of the spec. And here 20 years later it still sucks.
First it’s on the 2.4 GHz band...which is quite busy as a significant number of devices, and protocols use that band including WiFi, Microwave ovens, baby monitors, and etc. The Bluetooth spec as done a lot to mitigate this in the spec but the issue persists.
Second there is an security element that was kinda added on later but was also built in and was optional.... this causes an untold amount of issues (aka vulnerabilities) and is probably what your experiencing with the paring issues.
Lastly the protocol stack implemented almost everything from audio to serial to TCP/IP...which is probably why it’s so ubiquitous and is implemented weirdly because there is multiple ways to do it...see the number of Bluetooth codecs.
Like it’s telling me, “yeah, I’m working now, but I’m going to hurt you one day and there is nothing you can do about it.”
Regardless I still find grief from things like the volume resetting on one or both ends after pairing. There is a lot of attention to detail needed to get this stuff right, and most companies can barely manage to ship - that's not on the standard of the spec but the standard of the marketplace.
I don't know if the old (around 11 years old) keyboard had an implementation issue, or slight hardware damage, or what, but the new stuff seems rock solid.
Then why does wireless not have these exact same issues?
It works ok on most devices.
If Bluetooth being crap was about cheapest solutions, I'd expect to see this problem on Wi-fi, which in practice generally works.
Every single device in the combinations is having crazy connection issues everyday.
If you had a honeypot accessible only by Bluetooth, you could pass off delays and dropped service for quite a while before the attackers figured out that it wasn't BT just being BT. :-)
I was burnt by Bluetooth several times, but I really hate wires so I keep coming back. And then keep getting burned.
And it burns me more this time. I found the new generation of Bluetooth headphones like the Airpod Pro and Sennheiser Momentum wireless 3 tried to maintain multiple connections simultaneously, but they really have no idea which one to switch to most of the time. It's literally a nightmare.
I really like the wireless concept, could anyone enlighten me why cannot the industry come up and adopt a better standard?
to me thats seems directional signal type issues.
I've also notice that my headset sitting around my neck will disconnect if my phone is in my pocket when my wife gives me a hug. meaning its range is less than 1 meter if having to go through a human body...
Before switching to Bluetooth we used the nRF51422 as an ANT+ radio. The development experience was completely different, it was a joy to work with, example programs were simple and worked. It was easy to code the things we wanted to implement.
My understanding of this extreme difference is (1) Bluetooth was designed to present a high barrier to entry, so that smaller device makers would have a hard time competing. It is intentionally complex and difficult to deal with. The standard for SD cards is similar (which is why almost all open source projects use the simpler, less functional SPI method of accessing an SD card.) (2) Nordic had a team for hire to write Bluetooth code for customers. Some of the API turmoil might have been to make it difficult for customers to develop their own code so they'd have to turn to Nordic for software. It's difficult to prove either of those conjectures, especially since large corporations see a benefit in creating barriers to entry and will support them.
So basically no one reads the documentation, they try to work from the example programs, and stability and interoperability suffers because no one really understands what they are doing (the API's completely obscure the underlying operations). Hence Bluetooth is often unreliable, unless a company has a team devoted to it and spends a lot of resources on it. The large gaps of undefined behavior don't help either, the order of many API interactions is often absolutely critical, even when you wouldn't expect it to be.
Another factor is that Bluetooth subsystems are essentially real-time systems where timing is critical. The chips are often sold as having spare MCU capacity for running your own code, but it's not apparent in the advertising that your code needs to be pristine and flawless in handling interrupts and in how long running operations are handled. Otherwise the Bluetooth firmware behind the API can easily lock up or start to do weird things. So a device maker who tries to have the Bluetooth MCU do other things to save the cost of an external MCU can easily have bugs in their code that interfere with the operation of the Bluetooth stack.
Why is Wi-Fi so unreliable? At this point you need specialized semi-pro equipment just to get a reliable connection to a router 15 feet away.