3 ms·

> it's full of insane quirks and vendor bugs As someone not familiar at the low level, can somebody explain how this can still be happening today? Are there n

> it's full of insane quirks and vendor bugs As someone not familiar at the low level, can somebody explain how this can still be happening today? Are there not libraries that help ensure proper implementation? I really don't understand.

lukeschlather 6y ago
Not an expert in this kind of low-level stuff, but bluetooth is mostly implemented in hardware. I don't imagine you could get a compact lightweight headset that can last 10 hours on a charge if it needed to run even something as lightweight as a C library. And obviously, you can forget something like Airpods.
- CyberDildonics 6y ago
  Are you basing this off of an assumption or do you have a source?
- TickleSteve 6y ago
  No, bluetooth is pretty much entirely in software. I say that as someone who has worked on Bluetooth devices at CSR/Qualcomm. Embedded software quite routinely runs hours on batteries. Indeed, some (entirely software) devices, last many years.
db48x 6y ago
Hardware makers basically can't write good software.
- imtringued 6y ago
  That doesn't explain why Bluetooth is the protocol that causing the most trouble. Proprietary 2.4Ghz devices appear to work just fine.
  - db48x 6y ago
    A Bluetooth device is much more complex than the proprietary wireless devices. The complexity is largely because Bluetooth hardware must support many different types of devices all with differing requirements. A proprietary keyboard dongle doesn't have to be able to deal with the audio traffic coming from a microphone or going to a headset. Furthermore, it doesn't have to support proper identification and authorization of each individual device; many of them will accept input from any compatible keyboard that happens to be near by.
rcxdude 6y ago
There's multiple effects going on. Firstly the bluetooth spec itself is quite complex: the 'core specification' document is near 3000 pages of very dense technical details, because it's aiming to allow anything to connect to anything. Secondly, many bluetooth devices are both heavily power and cost optimised: you don't have a lot of silicon and you don't get to use it very often if you want your product to have a reasonable battery life. This is especially true of the raio in a bluetooth device, and adds a whole other level of complexity to your implementation, and is one area where bugs are very easy to introduce. It also requires a fairly complex dance between hardware and software (most of the bluetooth spec is implemented in software, usually C. The hardware mostly consists of a radio capable of transmitting on the right 2.4Ghz signals with the right modulation scheme, but when you add power management to that it gets gnarly). Thirdly, hardware companies are generally not great at software. A lot of effort goes into physical testing and validation but the base level of quality of the code isn't great. Also the quality of a given bluetooth device often depends on the quality of the custom code for it: there's a generaly trend of running application code on the same CPU as the bluetooth code, and in an embedded context there isn't generally great seperation between the two (nordic's approach is probably the best here). A third-party making a cheap pair of bluetooth headphones is not likely to make a quality result, even if using a library which is relatively bug-free. Finally, there's a vicous sprial effect: because you need to interact with a wide variety of other implementations, which may all be buggy or quirky in their own ways, you wind up needing to test with a wide array of other devices (expensive and may not always happen) and play whack-a-mole with the remaining issues which appear, which in turn creates more quirks and more opportunity for bugs.

lukeschlather 6y ago

Not an expert in this kind of low-level stuff, but bluetooth is mostly implemented in hardware. I don't imagine you could get a compact lightweight headset that can last 10 hours on a charge if it needed to run even something as lightweight as a C library. And obviously, you can forget something like Airpods.

CyberDildonics 6y ago
Are you basing this off of an assumption or do you have a source?
TickleSteve 6y ago
No, bluetooth is pretty much entirely in software. I say that as someone who has worked on Bluetooth devices at CSR/Qualcomm. Embedded software quite routinely runs hours on batteries. Indeed, some (entirely software) devices, last many years.

db48x 6y ago

Hardware makers basically can't write good software.

imtringued 6y ago
That doesn't explain why Bluetooth is the protocol that causing the most trouble. Proprietary 2.4Ghz devices appear to work just fine.
- db48x 6y ago
  A Bluetooth device is much more complex than the proprietary wireless devices. The complexity is largely because Bluetooth hardware must support many different types of devices all with differing requirements. A proprietary keyboard dongle doesn't have to be able to deal with the audio traffic coming from a microphone or going to a headset. Furthermore, it doesn't have to support proper identification and authorization of each individual device; many of them will accept input from any compatible keyboard that happens to be near by.

rcxdude 6y ago

There's multiple effects going on. Firstly the bluetooth spec itself is quite complex: the 'core specification' document is near 3000 pages of very dense technical details, because it's aiming to allow anything to connect to anything. Secondly, many bluetooth devices are both heavily power and cost optimised: you don't have a lot of silicon and you don't get to use it very often if you want your product to have a reasonable battery life. This is especially true of the raio in a bluetooth device, and adds a whole other level of complexity to your implementation, and is one area where bugs are very easy to introduce. It also requires a fairly complex dance between hardware and software (most of the bluetooth spec is implemented in software, usually C. The hardware mostly consists of a radio capable of transmitting on the right 2.4Ghz signals with the right modulation scheme, but when you add power management to that it gets gnarly). Thirdly, hardware companies are generally not great at software. A lot of effort goes into physical testing and validation but the base level of quality of the code isn't great. Also the quality of a given bluetooth device often depends on the quality of the custom code for it: there's a generaly trend of running application code on the same CPU as the bluetooth code, and in an embedded context there isn't generally great seperation between the two (nordic's approach is probably the best here). A third-party making a cheap pair of bluetooth headphones is not likely to make a quality result, even if using a library which is relatively bug-free. Finally, there's a vicous sprial effect: because you need to interact with a wide variety of other implementations, which may all be buggy or quirky in their own ways, you wind up needing to test with a wide array of other devices (expensive and may not always happen) and play whack-a-mole with the remaining issues which appear, which in turn creates more quirks and more opportunity for bugs.