The vast majority of my bluetooth woes are not with bluetooth, but with the complete lack of configurability on Android and other devices.
I end up pairing/unpairing my home speakers with my phone constantly, not because bluetooth is brittle, but because Android doesn't have options like "remember pairing but don't automatically connect with this device", or, "select audio output", or, "do/dont continue playing audio when this device loses connection". Otherwise, when I turn my headphones on to bike to work in the morning, my phone will be paired with the speakers, and the headphone will connect for calls but not audio.
I don't want linux-like configuration. I don't want to root my phone. But having no control on these thousand dollar devices over the most common tasks we use them for despite billions in R&D and tens of thousands of developers is ludicrous.
It's, IMO, due to how 99.9% of the world uses their bluetooth. It could have options to control these things but for most people, they just don't care. They might own one pair of bluetooth headphones and one bluetooth mouse and one car that pairs to their phone, and that would be about it.
So ironically it was designed to do anything & everything, like USB, but now it's a two-trick pony.
It’s funny, anytime anyone mentions the loss of the 3.5mm jack on flagship phones, the loud Bluetooth brigade conveniently forgets just how inconvenient Bluetooth can be.
The problems with Bluetooth are it doesn't pair, it doesn't unpair, you need to unpair first, you need to use the other protocol that transmits audio, the latency is way too high, it's insecure, the software stack hangs or crashes, you can't know for sure if two devices will work together, BLE is WAY too low level and a step back, the spec is way too big and complicated, ...
In 20 years they have not managed to make it good. It seems hopeless with the current institutions managing it. What a heap of hot garbage.
I agree with you, except about Bluetooth LE. LE (4.0) is a totally different protocol than 'classic' Bluetooth (<= 3), and shares no heritage. Nokia came up with the LE spec and dropped it down on the desk at the Bluetooth SIG and told them this was Bluetooth now ("wibree", [1]). The LE family is just a short couple of years old now, not 20.
For many of the tasks you'd want high bandwidth for, you probably want WiFi (or even point-to-point WiFi established over Bluetooth LE like AirDrop). LE is a huge step forward because it distinguishes between the two major use cases (low bandwidth - low power - promiscuous mode vs. high-bandwidth - paired) and allows for the development of standards which meet each use case without compromise. Part of why Bluetooth was pretty garbage before is that its use cases overlapped so heavily with WiFi, but it wasn't allowed to (or ever going to) replace it. This lead to this weird hybrid high-power, middling bandwidth, paired but you-probably-dont-want-it-to-be spec.
LE 2 (Bluetooth 5) addresses some of your concerns by increasing the bandwidth available for LE devices, without compromising on power efficiency.
Every Bluetooth device I have ever tried has failed to meet my expectations. I have a drawer full of Bluetooth devices that I regret purchasing. I've been fooled too many times already, I simply won't buy a device that relies on Bluetooth any more. For mouse/keyboard I like RF and for audio you can pry my 3.5mm jack from my cold dead hands.
Those aren't problems of Bluetooth, those are problems of device implementations. The BT protocol makes it possible to manage pairings, un-pairings, and re-pairings, in any which way that makes good sense for the user. But a lot of device manufacturers don't spend the time to read even the most basic parts of the spec necessary to manage connections.
For example, a lot of re-pairing issues come about from the device resetting its own device ID. Some rare devices do this on every soft-power-cycle. A good many devices do it on recovering from power-failure (e.g. dead battery). At that point, the device is basically a completely different "device". The best devices keep their device ID in non-volatile memory so they can recover from power failure without resetting their device ID.
Having built a few BT devices as a hobbyist, it's not really that hard to make a good pairing experience. You just have to... think things through and not do the most bare minimum work.
And you forgot one: it seems impossible to pair (e.g.) two headphones with a single phone. This makes it impossible to listen with a buddy to a single audio source.
In my opinion part of the problem with Bluetooth is that the API exposed by android and IOS is like... two or three layers too low. Imagine if in web programming you set the MTU size in your HTML and you get the idea of what programming Bluetooth is like.
Another issue I see is more of a view point that people have trouble shaking. Typically we think of the server as being more powerful than the client, but in BLE the client usually has more processing power and battery by several orders of magnitude. Once you examine this preconception BLE makes a whole lot more sense.
Compared to HTTP/TCP/IP, abstractions between layers of the BLE stack are extremely leaky. Examples: indicating choice of PHY coding and channels in the equivalent of a `listen/connect` call, or the three different but intertwined places where fragmentation/reassembly can happen. Being effective with BLE requires deep understanding of the entire stack, and since it is difficult for a single person to have such level of understanding, we get bugs. By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly.
I suspect this is due to not having enough independent implementations of each layer - Bluetooth is designed and standardized by one committee, and the entire stack usually implemented as a single "thing", making it too easy to break abstraction when a new feature needs to be added.
I'm someone who actually likes reading standards for fun (sometimes there are interesting things in them), and have read many of them as a result[1], and even implemented parts of some; but I still find Bluetooth, along with WiFi and GSM/LTE very intimidating.
Is there something about wireless in particular that lends itself to this proliferation of complexity? I've read 802.3 (Ethernet) and it was nowhere near as dense and intimidating.
[1] MP3, JPEG, JPEG2000, JBIG2, H.261 to 264, MPEG 1 and 2, USB, SATA, IEEE1284, RS-232, a bunch of RFCs, and too many others to list, those are just the ones I remember reading recently...
You stole my comment! No but in all seriousness, this is a long-standing issue. The A) requirement of making BT-enabled devices backwards compatible, B) the monstrous stack of protocols involved in like every use-case, & C) an assumption that Spread-Spectrum Frequency Hopping @ the physical layer is a substitute for encryption, all combine to make a BT kind of especially terrifying.
Take for example the Nike Fit Band, an iconic bluetooth peripheral that's been on the market for some time:
what’s is your point about it being a dollar per chip? that it’s implemented by super cheap labor or something?
silicon is free. you are paying for the r&d. that’s why volume matters. at the volume of bluetooth chips, they are almost indeed free. most of that dollar is distribution costs.
my point is, the cost of the chip isn’t a signal of anything except the ubiquity of it.
I've gotten so tired of protocols and specifications that are overly complex or are poor fits for how they're used that I've started developing my own for the services I'm implementing [0].
Making protocols & specs no more complex or ambiguous than necessary is a hard requirement in this modern, security-conscious world.
Neat, but I strongly recommend a "related" section in your list of pointers. One of the best ways to communicate what you've made is to relate it to things people already know. E.g. is this thing like Protobuffs or like Markdown? Is it like a Merkle Tree or like Moment? Another valuable thing this does is give people looking for an alternative technology a way to find your thing.
Recently, I rented a Dodge mini van. Was all they had.
The pairing is voice. Fucking menu via voice! It took 10 minutes...
Please say:
Manage devices
Add a new device
Configure
.
.
.
What priority, say 1 through 5...
I say 1.
Priority 1 is in use by [device name]
And on and on. I was angry when done. I will never use that POS again. Ugh!
Someone at Dodge needs to try again. I know you meant well. I know you were probably told to do it too. But damn. It is a real fail.
I hate quality changes for very thin reasons.
I hate quality changes for technical reasons.
I hate charging.
About the only time I loved Bluetooth was running windows XP and that excellent driver could pair with my old flip phone and do it all. Network, act as mic, etc... I did it once and done too. Ran that setup for a couple years until I got a better phone.
Here is the thing. Brb
Back! Had to change devices.
I can be convinced to go wireless. It is going to take more than the mess we have today.
Just renewed my phone with headphone Jack. Brand new, should be good for years.
The wireless devices need to be serviceable, the protocols need to be sane and robust too, or the whole affair is a total net loss.
Complaining about 3000 pages of spec, in comparison to WiFi, is a bit apples-to-oranges. A lot of Bluetooth is not just the binary protocol. There is a huge surface area of what basically amounts to RPC protocols for different, standardized device interfaces. Bluetooth is a wonder for having things like heart rate monitors, pointing devices, and audio interfaces specified in a single, standardized way. You can generally count on a BT device from literally thousands of vendors to behave in the same way in literally thousands of different client devices.
It's more fair to compare BT to heavy protocols like ZigBee, or worse yet, ZWave. If you wanna dig into a shit-show of wireless protocols, look no further than ZWave. That thing is a complete boondoggle.
I have a few Bluetooth speakers. If I accidentally close the app but forget to disconnect from settings too, then no one else can pair with them until I return. This seems like standard behavior, and makes me worry that if I lose my phone at the wrong moment, I might brick a few devices.
I really like common standards, but if the consortium can't fix either security or usability, we might be better off with a clean slate.
My favorite part is when headphones connect to the laptop in my backpack that’s closed and the laptop I’m currently using. They play music successfully but volume is set to 0 because I guess macOS does that in sleep mode.
So I have to open up the sleeping laptop just to disconnect bluetooth
I bought a Bluetooth speaker and only Apple devices can use it smoothly, my Android 8/9 phone remembers its paired speaker but can't connect it unless I unpair them, press speaker's pair button, pair my phone again every single times. I plan to buy a DAC that support Spotify connect.
I've gotten bluetooth to work a handful of times. I've not been able to repeat that feat enough times to figure out why it works when it works and doesn't work when it doesn't, so I just throw my hands up and stick to aux and USB wired connections.
There should be a part of the protocol that determines the lag and a standard way for programs to then set their delay accordingly, so that when I'm watching a video the sound is synced with the screen. Instead I have to manually try several different lag times until one feels good enough.
It seems like something endemic to the protocol. Logitech's recent wireless mice/keyboards have skipped bluetooth altogether - they determined the lag was simply too large for high performance gaming: https://www.reddit.com/r/MouseReview/comments/99qq4a/about_t...
The problem with BT is not unique to BT. Any protocol at the time when it's used by app developers is not understood and misused. Most products in the wild just use the example code provided in the sdks provided. You can make a whole product this way. Especially simple stuff like bt speakers.
You know what doesn't cause increased attack surface for your devices, doesn't have pairing issues, never cuts out audio randomly, works immediately upon connection, is low power, and doesn't introduce additional RFI into your living space? A headphone jack.
It has always been the case. Attending IDC in 1999 before a single device had been certified and the hardware standards and certification docs were already 3500 pages. You can only imagine how this has grown in 20 years.
Bluetooth is a "giraffe" technology. It evolved in to the current form through happenstance. Nothing about it is simple or normal, instead randomly weird and inconsistent. And nobody is surprised that after 20 years everyone rightfully assumes that it barely works and is full of holes. However, since the standards are controlled by the people who build the hardware it is not been possible for a functional, non-insane alternative to appear.
My main gripe with BT is the inpossibility to limit even which profiles[0] are active. For example: I do not mind allowing audio, but can not allow any form of networking.
I've not looked at recent specs but Bluetooth security has always been a bit of a misnomer. It's roots are in FTP etc and older protocols not really designed for security in mind, never was. So to say it's become a security risk, when it already was, may be missing the point.
I've been looking for a way to stop bluetooth from pairing with the Macbook asleep, this looks promising to switch it off when the lid is shut at least:
[+] [-] aschampion|6 years ago|reply
I end up pairing/unpairing my home speakers with my phone constantly, not because bluetooth is brittle, but because Android doesn't have options like "remember pairing but don't automatically connect with this device", or, "select audio output", or, "do/dont continue playing audio when this device loses connection". Otherwise, when I turn my headphones on to bike to work in the morning, my phone will be paired with the speakers, and the headphone will connect for calls but not audio.
I don't want linux-like configuration. I don't want to root my phone. But having no control on these thousand dollar devices over the most common tasks we use them for despite billions in R&D and tens of thousands of developers is ludicrous.
[+] [-] de_watcher|6 years ago|reply
I want linux-like configuration. It's the only way to be sure.
[+] [-] ip26|6 years ago|reply
So ironically it was designed to do anything & everything, like USB, but now it's a two-trick pony.
[+] [-] JustSomeNobody|6 years ago|reply
[+] [-] ahartmetz|6 years ago|reply
[+] [-] arcticbull|6 years ago|reply
For many of the tasks you'd want high bandwidth for, you probably want WiFi (or even point-to-point WiFi established over Bluetooth LE like AirDrop). LE is a huge step forward because it distinguishes between the two major use cases (low bandwidth - low power - promiscuous mode vs. high-bandwidth - paired) and allows for the development of standards which meet each use case without compromise. Part of why Bluetooth was pretty garbage before is that its use cases overlapped so heavily with WiFi, but it wasn't allowed to (or ever going to) replace it. This lead to this weird hybrid high-power, middling bandwidth, paired but you-probably-dont-want-it-to-be spec.
LE 2 (Bluetooth 5) addresses some of your concerns by increasing the bandwidth available for LE devices, without compromising on power efficiency.
[1] https://en.wikipedia.org/wiki/Bluetooth_Low_Energy
[+] [-] ignoretest|6 years ago|reply
[+] [-] moron4hire|6 years ago|reply
For example, a lot of re-pairing issues come about from the device resetting its own device ID. Some rare devices do this on every soft-power-cycle. A good many devices do it on recovering from power-failure (e.g. dead battery). At that point, the device is basically a completely different "device". The best devices keep their device ID in non-volatile memory so they can recover from power failure without resetting their device ID.
Having built a few BT devices as a hobbyist, it's not really that hard to make a good pairing experience. You just have to... think things through and not do the most bare minimum work.
[+] [-] amelius|6 years ago|reply
[+] [-] B-Con|6 years ago|reply
Their wireless audio protocol is bad and they should feel bad.
[+] [-] s_m_t|6 years ago|reply
Another issue I see is more of a view point that people have trouble shaking. Typically we think of the server as being more powerful than the client, but in BLE the client usually has more processing power and battery by several orders of magnitude. Once you examine this preconception BLE makes a whole lot more sense.
[+] [-] sratner|6 years ago|reply
Compared to HTTP/TCP/IP, abstractions between layers of the BLE stack are extremely leaky. Examples: indicating choice of PHY coding and channels in the equivalent of a `listen/connect` call, or the three different but intertwined places where fragmentation/reassembly can happen. Being effective with BLE requires deep understanding of the entire stack, and since it is difficult for a single person to have such level of understanding, we get bugs. By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly.
I suspect this is due to not having enough independent implementations of each layer - Bluetooth is designed and standardized by one committee, and the entire stack usually implemented as a single "thing", making it too easy to break abstraction when a new feature needs to be added.
[+] [-] fopen64|6 years ago|reply
Bluetooth is really a good bad example of committee design.
[+] [-] gHosts|6 years ago|reply
Do you have any idea how bloody insanely complex bluetooth is?
Just the the core stuff,
https://www.bluetooth.com/specifications/bluetooth-core-spec...
without the various protocol specs... https://www.bluetooth.com/specifications/protocol-specificat... or the GATT or ...
The bloody core spec is 3000 PAGES of standardese.
All in stuff that costs less than a dollar per chip.
[+] [-] userbinator|6 years ago|reply
Is there something about wireless in particular that lends itself to this proliferation of complexity? I've read 802.3 (Ethernet) and it was nowhere near as dense and intimidating.
[1] MP3, JPEG, JPEG2000, JBIG2, H.261 to 264, MPEG 1 and 2, USB, SATA, IEEE1284, RS-232, a bunch of RFCs, and too many others to list, those are just the ones I remember reading recently...
[+] [-] rotrux|6 years ago|reply
You stole my comment! No but in all seriousness, this is a long-standing issue. The A) requirement of making BT-enabled devices backwards compatible, B) the monstrous stack of protocols involved in like every use-case, & C) an assumption that Spread-Spectrum Frequency Hopping @ the physical layer is a substitute for encryption, all combine to make a BT kind of especially terrifying.
Take for example the Nike Fit Band, an iconic bluetooth peripheral that's been on the market for some time:
2015: https://securelist.com/how-i-hacked-my-smart-bracelet/69369/
2016: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4737495/
2017: https://www.zdnet.com/article/bluetooth-security-flaw-bluebo...
I'm sure I can find one from last year as well, but you get the point.
Also here's this for good-measure: http://ubertooth.blogspot.com/
[+] [-] techslave|6 years ago|reply
silicon is free. you are paying for the r&d. that’s why volume matters. at the volume of bluetooth chips, they are almost indeed free. most of that dollar is distribution costs.
my point is, the cost of the chip isn’t a signal of anything except the ubiquity of it.
[+] [-] kstenerud|6 years ago|reply
Making protocols & specs no more complex or ambiguous than necessary is a hard requirement in this modern, security-conscious world.
[0] https://github.com/kstenerud/specifications
[+] [-] amelius|6 years ago|reply
[+] [-] javajosh|6 years ago|reply
[+] [-] kennyadam|6 years ago|reply
[+] [-] ddingus|6 years ago|reply
Recently, I rented a Dodge mini van. Was all they had.
The pairing is voice. Fucking menu via voice! It took 10 minutes...
Please say:
Manage devices Add a new device Configure . . .
What priority, say 1 through 5...
I say 1.
Priority 1 is in use by [device name]
And on and on. I was angry when done. I will never use that POS again. Ugh!
Someone at Dodge needs to try again. I know you meant well. I know you were probably told to do it too. But damn. It is a real fail.
I hate quality changes for very thin reasons.
I hate quality changes for technical reasons.
I hate charging.
About the only time I loved Bluetooth was running windows XP and that excellent driver could pair with my old flip phone and do it all. Network, act as mic, etc... I did it once and done too. Ran that setup for a couple years until I got a better phone.
Here is the thing. Brb
Back! Had to change devices.
I can be convinced to go wireless. It is going to take more than the mess we have today.
Just renewed my phone with headphone Jack. Brand new, should be good for years.
The wireless devices need to be serviceable, the protocols need to be sane and robust too, or the whole affair is a total net loss.
[+] [-] moron4hire|6 years ago|reply
It's more fair to compare BT to heavy protocols like ZigBee, or worse yet, ZWave. If you wanna dig into a shit-show of wireless protocols, look no further than ZWave. That thing is a complete boondoggle.
I've been pretty happy with BT.
[+] [-] brownbat|6 years ago|reply
https://xkcd.com/2055/
I have a few Bluetooth speakers. If I accidentally close the app but forget to disconnect from settings too, then no one else can pair with them until I return. This seems like standard behavior, and makes me worry that if I lose my phone at the wrong moment, I might brick a few devices.
I really like common standards, but if the consortium can't fix either security or usability, we might be better off with a clean slate.
[+] [-] Swizec|6 years ago|reply
So I have to open up the sleeping laptop just to disconnect bluetooth
[+] [-] a012|6 years ago|reply
[+] [-] crehn|6 years ago|reply
[+] [-] throwaway2048|6 years ago|reply
[+] [-] thrower123|6 years ago|reply
[+] [-] wolfgke|6 years ago|reply
Complexity Is a Security Risk
[+] [-] ga-vu|6 years ago|reply
[+] [-] ikeboy|6 years ago|reply
There should be a part of the protocol that determines the lag and a standard way for programs to then set their delay accordingly, so that when I'm watching a video the sound is synced with the screen. Instead I have to manually try several different lag times until one feels good enough.
[+] [-] jjcm|6 years ago|reply
[+] [-] aantthony|6 years ago|reply
[+] [-] Paul_S|6 years ago|reply
[+] [-] tristor|6 years ago|reply
Just saying.
[+] [-] brokenmachine|6 years ago|reply
Expensive timebombed unrepairable accessories is a small price to pay in order to have a 1mm thinner expensive timebombed unrepairable phone!
[+] [-] bondolo|6 years ago|reply
[+] [-] jim-jim-jim|6 years ago|reply
[+] [-] peter_retief|6 years ago|reply
[+] [-] baby|6 years ago|reply
[+] [-] Paul_S|6 years ago|reply
The big thing about BT is that it's everywhere.
[+] [-] borumpilot|6 years ago|reply
0: https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
[+] [-] newaccoutnas|6 years ago|reply
[+] [-] andy_ppp|6 years ago|reply
https://apple.stackexchange.com/a/272244
[+] [-] geggam|6 years ago|reply