4 ms·

Right, I agree that it depends on the device. A Chevy model I don't recall had the stupidest bug where you sometimes couldn't pair unless you reset the car comp

by theGimp 10y ago

Right, I agree that it depends on the device. A Chevy model I don't recall had the stupidest bug where you sometimes couldn't pair unless you reset the car computer... by leaving the driver's door open for 5 minutes. I don't blame the Bluetooth standard though, messy as it might be. That's clearly terrible implementation on the car manufacturer's part.

kabdib 10y ago
BT seems over-complicated, especially considering that it's quite often low-level (I really mean that organizationally) firmware engineers working on products that won't be updated after they ship. Given the types of products that are made with BT support, the hostile environments that they're developed within, and the common after-sales abandonment of support, BT should be a simpler protocol that is a LOT more resilient to implementation mistakes. But I don't think that anyone designs protocols to withstand institutional failure :-)
- com2kid 10y ago
  BT itself is not overly complicated. Bargain basement BT chips, which is what everyone ends up using to save pennies, are full of bugs that have to be worked around. Of the various BT stacks out there, only a few are actually good, and the good ones get to charge appropriate licensing fees, meaning that they aren't in wide use. When you combine randChip with randBtStack, the end result is not necessarily a quality product. The poor engineers who have to work with this combination end up resorting to sending reset commands to their chip in an attempt to get the damn thing working.
  - gtirloni 10y ago
    It would be really interesting to have a list of good BT stacks and devices using them. That way maybe we could avoid the bad ones. As a consumer I have no idea which devices will actually work properly (and I assume Bluetooth as a whole sucks).
- Gibbon1 10y ago
  Fifteen years ago, looking at the Bluetooth spec my impression was the best way to implement it would have been to send the designers to the Siberia and then start over. The two issues I saw were Bluetooth is based on a frequency hopping radio using a dated low performance modulation scheme. The only nice thing you could say is potentially you can build really low power radio's using that design. However that brings up the second issues, a very complicated kitchen sink base band which requires a complex software stack and power hungry processor to support it. There goes your low power, out the window. (I think there were about 20 companies trying to design low power Bluetooth transceivers circa 2000-2003, most of them never could get the power low enough or a working stack) Hardware design issues aside, frequency hoppers have insurmountable quality of service issues for most applications. Professionally I don't think this is fixable. They would have been better off doing the following three things. 1. Define a low speed point to point oriented modulation scheme that can be supported by 802.11 radio front ends. Probably could have implemented this as a sub-band of some sort. 2. A direct sequence spread spectrum physical layer for USB. Advantage of that is the USB stack mostly works as USB had a 10 year head start and more resources than the Bluetooth alliance ever had, or will have. If one thinks a stack like USB is 'easy' consider Microsoft had to redesign theirs three or four times. 3. Dedicated DSSS wireless headphone spec. Seriously this was the original design goal and was totally achievable until the committee responsible for the spec lost their minds.
  - kabdib 10y ago
    The USB emulation thing is interesting. Unfortunately, most USB implementations are disasters, too. Don't get me started on security. BT is probably a festering pit of remote exploits and vendor backdoors.

by theGimp 10y ago

kabdib 10y ago

BT seems over-complicated, especially considering that it's quite often low-level (I really mean that organizationally) firmware engineers working on products that won't be updated after they ship. Given the types of products that are made with BT support, the hostile environments that they're developed within, and the common after-sales abandonment of support, BT should be a simpler protocol that is a LOT more resilient to implementation mistakes. But I don't think that anyone designs protocols to withstand institutional failure :-)

com2kid 10y ago
BT itself is not overly complicated. Bargain basement BT chips, which is what everyone ends up using to save pennies, are full of bugs that have to be worked around. Of the various BT stacks out there, only a few are actually good, and the good ones get to charge appropriate licensing fees, meaning that they aren't in wide use. When you combine randChip with randBtStack, the end result is not necessarily a quality product. The poor engineers who have to work with this combination end up resorting to sending reset commands to their chip in an attempt to get the damn thing working.
- gtirloni 10y ago
  It would be really interesting to have a list of good BT stacks and devices using them. That way maybe we could avoid the bad ones. As a consumer I have no idea which devices will actually work properly (and I assume Bluetooth as a whole sucks).
Gibbon1 10y ago
Fifteen years ago, looking at the Bluetooth spec my impression was the best way to implement it would have been to send the designers to the Siberia and then start over. The two issues I saw were Bluetooth is based on a frequency hopping radio using a dated low performance modulation scheme. The only nice thing you could say is potentially you can build really low power radio's using that design. However that brings up the second issues, a very complicated kitchen sink base band which requires a complex software stack and power hungry processor to support it. There goes your low power, out the window. (I think there were about 20 companies trying to design low power Bluetooth transceivers circa 2000-2003, most of them never could get the power low enough or a working stack) Hardware design issues aside, frequency hoppers have insurmountable quality of service issues for most applications. Professionally I don't think this is fixable. They would have been better off doing the following three things. 1. Define a low speed point to point oriented modulation scheme that can be supported by 802.11 radio front ends. Probably could have implemented this as a sub-band of some sort. 2. A direct sequence spread spectrum physical layer for USB. Advantage of that is the USB stack mostly works as USB had a 10 year head start and more resources than the Bluetooth alliance ever had, or will have. If one thinks a stack like USB is 'easy' consider Microsoft had to redesign theirs three or four times. 3. Dedicated DSSS wireless headphone spec. Seriously this was the original design goal and was totally achievable until the committee responsible for the spec lost their minds.
- kabdib 10y ago
  The USB emulation thing is interesting. Unfortunately, most USB implementations are disasters, too. Don't get me started on security. BT is probably a festering pit of remote exploits and vendor backdoors.