Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why is Bluetooth so unreliable?
89 points by aosaigh on April 18, 2020 | hide | past | favorite | 41 comments
After all these years and consecutive versions, Bluetooth in my experience is still a hugely unreliable experience.

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?




You get flakey Bluetooth when the two implementations on the two devices differ significantly, or when it is poorly implemented.

... 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.


Part of the big thing that's missing in those 3000 pages is limitations. Once a bluetooth connection exists there's really nothing preventing the device from using any of the profiles available, other than limits placed by the item connecting. Connect a bluetooth audio device? It can just become a internet route for you, or become something that accesses contacts, or any of the swath of different profiles available.


Absolutely insane and fascinating. Here's the core spec: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?d... [pdf]


Good reply...but the real question is why has nobody stepped up to replace it? Close quarter communication is only becoming more prevalent, why do we live with a broken standard?


The LTE Bluetooth standard actually does make large inroads towards removing a lot of the less clear parts of the standards, and reducing the size of the specification. It is still far from perfect, but attempts are being made by the industry to clean things up.

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.


Bluetooth Low Energy is this replacement – it's a completely different standard.


What about Zigbee?

https://zigbeealliance.org/


Zigbee is more of a competitor for Bluetooth Low Energy, which is quite a bit more modern, sane and reliable than Bluetooth Classic.

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).


Bcz - Money


I was the developer responsible for the bluetooth integration of a "smart lock" in an android app and it was an absolute nightmare.

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. :/


I had exactly the same experience. Android's Bluetooth stack is shockingly bad. They even changed implementation once (from the standard Linux Bluez stack to some other one). Just as bad, if not worse.

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 don’t know the reasons To this. But I but would comment that when it comes to bluetooth, once again Apple has shown that they “get it” with airpods, the major feature To me is simply that they remove most of the incredibly annoying issues with Bluetooth that other products just seem to not even notice.

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.


I'm on my 2nd set of "2nd gen" (not the noise cancelling ones tho) airpods.

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.


Broadcom bluetooth/wifi chips ran out of firmware hot patch ram slots long time ago. Company seems to be too cheap to respin the rom mask with all the fixes baked in. From what I remember even brand new iphone x ships with no room for BT firmware patching.

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


1. The quality of service for RF vs a wire sucks big phat donkey balls.

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.


#4 makes me laugh because I had that thought when I was trying to work with bluetooth. I think the real problem is two-fold. The original spec required approval from all members of the consortium. I think a lot of things were left out that are really important, such as security. I know they had security from the start, but really, it's bullshit. Plus the original chipsets were incredibly expensive, and my pure speculative thought is that they cut corners (the firmware part) to bring them out to market. I was really surprised, shouldn't have been with hindsight, to see when bluetooth chipsets started to reach price parity with wifi chipsets.

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 was writing firmware for RX transceivers when Bluetooth was specified. I feel like they wrote the spec with very little input from chip designers and without building prototype hardware.

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.


I remember watching a tech news report on cable TV (yeah, that long ago) about a hot new tech called 'Bluetooth' that was going to revolutionize device interoperability, and the BT chipset would be at most $5 of the device cost.... until that never happened.


It actually did, charmingly. usually I just click upvote on these but it was stunning to read one and think "wait...that is exactly what happened, even if its not perfect"


Yeah, but how long did it take to truly drop to the $5 mark? When bluetooth stuff came out (mice, keyboards, etc.) they were exorbitantly expensive. It was way cheaper for manufacturers to sell stuff with their own RF dongles instead of using BT.


I recall buying a USB Bluetooth adapter in the mid 2000's that was maybe $12 shipped from Asia. If that was a the cost to the consumer for a device that was mostly a bluetooth radio I suspect that the cost to add bluetooth to a high volume product was probably at or below $5 ~15 years ago.


I remember the marketing guys had this spiel that WiFi was for businesses and that consumers would use Bluetooth for wireless networking. Because at $50-100 obviously WiFi was 'too expensive' for home use. LOL.

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.


Well for a multitude of reasons....

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.


Even the icon makes me irrationally angry.

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.”


IME it's all down to the implementation these days, which is a low-bidder-gets-what-they-pay-for kind of affair. My phone is cheap and the Bluetooth is nearly unusable on it(it can only really support one device at a time and that device will periodically drop out), but on my laptops, which have more of an emphasis on build quality, it's pretty solid, with few to occasional instances of audio tearing.

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.


From my experience, I'd agree with this. I got an Apple bluetooth keyboard from goodwill for $7 (retail ~$95) and used it with my hackintosh. Because it dropped out constantly, I figured I had installed antennas incorrectly, or that the ufl connectors were internally damaged, or… something. After upgrading to the newer (stupidly expensive) Magic Keyboard it works from anywhere in my house, as do my Power Beats Pro.

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.


No, it's still terrible on my [Macbook Pro, Mac Pro] <*> [Airpod Pro, Sennheiser Momentum 3].

Every single device in the combinations is having crazy connection issues everyday.


> IME it's all down to the implementation these days, which is a low-bidder-gets-what-they-pay-for kind of affair.

Then why does wireless not have these exact same issues?


what do you mean by wireless?


Wi-Fi.

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.


WiFi isn't much better in my experience. When I take my phone out of Flight Mode, the 4G LTE data connection is established in a fraction of a second whereas the WiFi can take 10 seconds or more. To a known router that is five metrea away.


I hate Bluetooth also but I did think of a use case where it could be great:

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. :-)


This [episode of Android Studio Backstage](https://androidbackstage.blogspot.com/2018/08/episode-97-blu...) has a lot of fun details about the Android Bluetooth stack and all the problems they have faced with it.


Two months ago I replaced my Macbook Pro and PC plus tens of wires set up with a cheese grater Mac Pro with most Bluetooth devices.

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?


My current bluetooth headset and mobile phone seem to have a directional antenna issue. I can get drop outs on my headset if the phone is laying flat and I'm 2 meters elevated above it and less than 4 meters away.

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...


Am I the only one with the opposite experience? Given the huge amount of devices, protocols and use cases I'm actually surprised how well it works.


I get the impression that Bluetooth 5 is better on multiple counts — based on a set of TaoTronics headphones I’ve used. (Most of the devices available currently use Bluetooth 4.2, afaik)


I have the same issues. Each new version of Bluetooth it's supposedly fixed but still lacks.


Yet if you get a device from Plantronics the Bluetooth is immediate and rock solid, so it can be done.


I spent two years working with the Nordic nRF51822 Bluetooth chip. During that time Nordic continually modified their developer API, completely changing it at least once. They changed the chips themselves every several months also, and you had to match the API version to the chip. They obsoleted old chips, so the code you had written would not run on the new chips, and it soon became difficult to find the old chips forcing you to upgrade to the new version of the SDK and change your code. Example programs in new SDK's often did not work because Nordic had not finished porting them. None of the example programs were written to coexist with the others; if you tried to combine two examples the result would often fail. The complexity of Bluetooth is also staggering; instead of writing code I could have probably spent those two years just reading the documentation, by which time substantial parts of it would have changed.

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.


Forget Bluetooth.

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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: