[trelliscoded]

The factors that contribute the most are

1) Bluetooth devices are usually battery powered and have their microwave RF section and DSPs implemented in power-sensitive silicon. Layer 1 and 2 performance is not good.

2) The Bluetooth specification is very complex and requires IP licensing for more desirable features such as low-latency audio, so inexpensive Bluetooth devices often badly test unpopular features and forgo licensing for nicer CODECs.

3) Bluetooth is based on frequency-hopping (FHSS), and the wavelength difference between the lowest and highest permitted frequencies is about 4mm. In some cases, this means that an intermediate RF-opaque object which is around that size near either transceiver may cause portions of the Bluetooth spectrum to be blocked, resulting in some percentage of the transmitted frames to be below the receiver's ability to get the bits out of the frame. Those dropped frames are not retransmitted, so the audio presented to the user sounds like swiss cheese, with evenly interleaved gaps of a few dozen milliseconds each.

4) Many legacy Bluetooth devices for Windows have driver packages that install an entire parallel Bluetooth stack (CSR, Toshiba...) next to the Windows one, because the in-box stack was pretty bad for a long time and didn't support many newer features. The situation is much better now, but machines which were upgraded from such a state, or ones which had whatever drivers were in the device's box installed are often using Bluetooth stacks which are totally ancient.

5) Embedded Bluetooth firmware is often not tested against many hardware failure cases, or omits more sophisticated portions of the stack due to CPU or memory constraints, and relies on cost-sensitive NVRAM technologies which have high bit error rates compared to e.g. a NVMe device with a 1 GHz controller to do lots of fancy error correction. Sometimes, the device just doesn't have reliable areas of NVRAM to store certain persistent state, and has no way to tell you that the checksums aren't working out (if they're even implemented), so pairing just fails for what seems like mysterious reasons. Keep in mind that many, many Bluetooth chips are driven by extremely low-end CPUs (I've seen 8051s), so there just isn't space for handling errors. The spec is complicated enough that many procedures have lots of failure modes, and in many of those cases the firmware just gives up and drops the frame on the floor.

[rapjr9]

Bluetooth is indeed very complex, the complete spec runs into thousands of pages. The Nordic SDK has more than 100,000 lines of code in it, and the proprietary stack (which they don't give you source code for) is probably another 100,000 lines of code. Nordic tries to get you to buy their software development services for Bluetooth, which may explain why their example code is not the greatest in my opinion (for example they provide an example of handling interrupts and an example of connecting to multiple devices, but no example of doing both at the same time and you can't just put the two examples together.) Nordic's SDK is a wrapper around the Bluetooth stack, so you not only have to understand Bluetooth itself, you have to learn Nordic's wrapper around it. They kept changing the stack and SDK and the chips themselves every few months (look at their part number histories) as well so any code you wrote went out of date quickly. There is speculation that large manufacturers love Bluetooth because it is a large barrier to entry for smaller companies, unlike say ANT+. I got ANT+ working on an embedded device in a month. I spent two years trying to get Bluetooth to work on the same device (admittedly in a more complicated configuration with multiple simultaneous channels) and I've spent a decade doing embedded programming with wireless radios. Most developers just use an example program with little modification, so they don't handle errors well or think about recovery from bad situations or do security/encryption. Human bodies block Bluetooth signals. I had a test device about 3 feet from a laptop where I was running long term tests of the radio, the data stopped every time I stood between the device and laptop. We were using Bluetooth based body worn sensors with a custom smartwatch so this was a problem for us, if someone put the smartwatch hand behind their back or under their arm all communication stopped. Put your phone in your back pocket and it will miss most packets from your smartwatch. This comes from using the 2.4GHz frequency, VHF radios are much more robust in getting around bodies and through obstacles. Bluetooth is just the wrong technology for many of the things it is used for, but it became ubiquitous in smartphones so now we're stuck with it.