Why is general bluetooth connectivity so "buggy"?
Why am I always struggling connecting my iPhone 6s to my bose bluetooth speaker?
I would love to understand that.
Also, it doesn't help that everything in Bluetooth until BLE (Low Energy) arrived was pretty bad. BLE changed everything and turned Bluetooth around, but BLE doesn't do audio.
There is lots of confusion in the naming, Bluetooth 4.0 incorporated BLE, and later they decided to just call the whole thing Bluetooth, even though it's now a set of two entirely different protocols, not even radio-compatible.
Bluetooth 1.0 uses GFSK at 1 Msym/s, just like BLE / Bluetooth 4.0. So it's the same r/f modulation protocol (it's the higher layers that are incompatible.) Is it the actual GFSK parameters, eg. frequency shifts, that are different?
I know that Bluetooth 2.0 and 3.0 use different r/f modulation (π/4-QPSK and 8DPSK at 1 Msym/s), but why do people say Bluetooth 4.0 is so different when it seems to be the same as Bluetooth 1.0?
Now that I write it out, I see that frequency hopping would count as a "higher layer," but I think it's still managed in hardware, which could be why there are many BLE-only chips. It's possible the GFSK parameters are also different, and of course the layers above the link manager are vastly different (for some reason).
https://en.wikipedia.org/wiki/Bluetooth_low_energy#Technical...
Windows 10 also seems monumentally bad at Bluetooth, and I've tried with a few different Bluetooth dongles with different chipsets. I've had the best luck with the one from Pluggable, which IIRC uses a Cambridge Silicon radio / driver stack. I really wish we had wireless serial instead of wireless USB, as most of the time, that's basically what I want, and stuff like the ESP, nRF24*, or even RFM69 does this quite well. I honestly wish they'd do a 433/900mhz standard for wireless HID only, and another for audio only.
OTOH, I have a Logitech Megaboom which always works amazingly well. Whoever did the Bluetooth radio on that...A+ .
If most bluetooth adapters had that, I could use it to navigate the BIOS, etc.
Haha. That reminds me of the classic, "Simply goto to http://example.com/drivers to download the network drivers for your new desktop".
Yeah, watch out with those, because a wireless wire is about accurate security wise too. Typically the proprietary dongles have very little security wise.
Me and a friend were at a regional lan party, and he had one of those keyboard. As we soon learned someone else in the locale also had one, because he would ever so often get random inputs on screen...
What I would like with the Logitech keyboards and mice is an option to plug in with micro USB or to go Bluetooth, i.e. wired but detachable if your Bluetooth happens to be reliable that day.
There already is a micro USB socket for power on the 810 keyboard, sadly they don't do a mouse that charges on microUSB and can also work on micro USB. Regardless, there is not a lot that really needs to be added on the hardware side to implement such a feature.
If such goodies existed then I would not need that normal keyboard/mouse that I have in my draw for the unpaired situation you describe. I could also do things such as BIOS UEFI settings without having to reach for the emergency input devices.
Despite deficiencies, I find the 810 to be the best keyboard going, I carry mine around instead of a laptop, it works great with work PC, my phone and my home PC.
FCC certs of a custom radio used with a bluetooth chip with a binary blob for firmware is the most painful thing I've ever done in my career...I think.
Water is a big one, which I think is one reason that having my phone in my back pocket almost always results in a dropped connection to my headphones over the course of working outside for a few hours, compared to my side or front jacket pocket. Too much water in our tissues.
First, we're bad at naming things. Is it BLE? Bluetooth Smart? BTLE? Bluetooth 4.0, or Bluetooth 4 Low Energy? And what does this have to do with ANT+? This doesn't seem to be a big problem, but it's a sign of deeper problems with the spec. In the long run it makes it very difficult for developers to implement.
Bluetooth 2.0 is radically different from BTLE. In 2.0, you had one device which acts like a microphone, and another device which acts like a speaker. This was like getting two people to dance together, it takes a lot of practice to get the joined movements right. If one person stumbles, it all goes down like dominoes.
BTLE on the other hand, acts like a (more familiar) client server model. You come up to the bank teller, and have a limited set of operations you can preform (withdraw/deposit money, open/close account). Here's the catch though... the teller is only open for 10 seconds during a 24 hour day, and moves throughout the city. You have to arrive at just the right time, or you have to wait until tomorrow. (This was done for battery saving.) The throughput is also MUCH slower than 2.0, which makes applications like audio out of the question for now.
There's also a lot of bureaucratic hype surrounding it. If you look at the release from the BT SIG, it seems very much similar to Java's claim that it runs on a bajillion devices. All in all, BTLE seems to be a solution in search of an IoT related problem, much like Java.
So in short, the reason I think it sucks is because it's a very complicated protocol with poor and confusing naming conventions. It sure doesn't help that it keeps getting re-invented! (Although BT5 seems to just be add-ons, finally!) Implementers (both on the HW side and the mobile/desktop side) have a difficult time figuring out how to do things correctly, much less why they need to be done. Things are getting better, but until the next "killer BTLE" application comes out, it's just heart rate monitors and useless iBeacons.
Here is another discussion of Bluetooth vs. Ant as written by someone in my industry (fitness): http://keithhack.blogspot.fr/2016/11/why-hasnt-ant-been-crus...
Tends to be hard to implement a specification without any implementation to test it out together with it, but those who do work out, should be looked into why so we all can learn from it.
A reason for the complexity was that the BT 1.0 profiles often leveraged existing technology, for example:
- RFCOMM was a way of sending arbitrary serial data, reusing RS232 comms which were very common.
- OBEX was a way of sending data which was previously sent over IrDA
- The "LAN access profile" basically said "use RFCOMM to do PPP over a serial link like you do with a modem"
If you tried to implement any of these from scratch then not only do you have to implement the BT part, you also have to implement the technologies that BT reused.
If you look at the initial SIG members, Nokia and Ericsson took care of the initial phone developments. Intel, IBM, Microsoft and Toshiba represented the PC side of things. I was working for 3Com at the time and we were interested in it as a short range network technology. 3Com developed a network device conforming to the "LAN access profile" but it was never released. 3Com also owned Palm and they were interested in incorporating BT with the hand held devices.
It is interesting to compare BT to Wireless Ethernet (IEEE 802.11) world. The IEEE Ethernet (802.3) specifications are pretty much only concerned with getting data packets from A to B at layers 0 through 2. At layer 3 and above they don't care if those packets are IPv4, IPv6 or some other protocol like IPX.
Bluetooth tried to define everything from the the RF communications all the way up to the application layer. The specification mentions how to the PIN code request should be presented to the user when authorizing a new connection. It also mentions which audio codecs should be supported for streaming audio. The BT profiles also tried to define how to transfer files, business cards or print documents.
These detailed application layer specifications simply don't exist in something like Ethernet. There might be an argument that BT tried to over specify things but it was attempting to give a level of interoperability which we still struggle to achieve over other networks.
It is a gigantic pile of mess and it never worked well enough for the majority of users.
Talking about design by committees, even the Wifi 802.11 has much improved.
I really wish Apple could design new one and force market adoption with the spec opened.
tl;dr when someone decided to use a 4 dBm transceiver, they (should have) made a conscious choice about it and would have verified that it's enough.
Quite plainly, if the connection drops when it shouldn't, it's either bad software or bad design.
Bad software is either the Bluetooth stack (especially in legacy Bluetooth devices; newer stacks tend to fare better) or the firmware that talks to the Bluetooth stack (if it's BLE, this is the safer bet).
Bad design on the hardware level is less excusable than it would seem, because a Bluetooth device is not exactly a long-haul wireless link that has to work during the mother of all thunderstorms. There's a wealth of information and modeling tools that help you with this stuff, too. Bad antenna design, bad filtering, bad casing are all common culprits, but I've seen a lot of electronic engineers who wouldn't call themselves RF engineers get it right by just following common sense and doing the math.
Sometimes (but even less often), it's not a design problem, it's a manufacturing problem (e.g. PCB antennas that get damaged or don't get etched right. But this is pretty rare.
Certainly, the operating environment plays a role, but that's why you consider it while you're designing the whole gizmo. You don't (or shouldn't) get to shrug and say hey, it's not my fault we're basically walking cucumbers.
So if a pair of super high-end Bose speakers and a super trendy iPhone keep dropping connection while they're within range, not inside and, respectively, outside a Farady cage or whatever, the reason isn't the black magic that RF design is, it's Bose's and Apple's profit margin.
Edit: I do concur with the other fellow who posted here, Bluetooth really is complex and the band it operates in isn't exactly a charm to work with, but frankly, neither of these reasons account for the huge range of devices that are simply badly designed and/or run bad software. There are a lot of Bluetooth devices that work just fine, a lot of other protocols that operate in the 2.4 GHz band and work just fine, a lot of other protocols that operate in similarly noisy bands and work just fine and a lot of protocols that are more complex and work just fine.
When those where in use, it would basically block all other traffic for the duration.
I noticed this back in the day when i really pushed my bluetooth usage.
My setup was a SonyEricsson featurephone, a Nokia N800, some Jabra headphones, and a white box folding keyboard.
As long as i used the "LAN" connection between the N800 and the phone to get online, it all worked fine. But switch it to PPP and the music would stutter whenever there was network activity.
SPP (serial port) on the other hand has never worked reliably for me. I mean, I have seen it work. I just never take it as granted that it will work, and thus far have not been disappointed.
This because while i have had problem on urban streets with a device in my hand and one in my ear, i have observed rurally living relatives that can walk around their whole house with the phone sitting in some corner and not suffering a connection outage.
Bluetooth frequencies are absorbed by water (and your body is water)