4 ms·

The best way I found when I dove into it ~8 years ago was to read through the code of one of the open source embedded Host stacks. That only gives you a periphe

The best way I found when I dove into it ~8 years ago was to read through the code of one of the open source embedded Host stacks. That only gives you a peripheral understanding of the baseband layer though, which is like 10 more cans of worms. I spent a few years in that area, and was never able to answer the question of why the whole protocol couldn't just be a dumb pipe (plus advertising/identification). You can also get the worst of both worlds by trying to implement the Bluetooth HCI USB transport protocol!

MichaelZuo 3y ago
The energy budget is too low to allow for an additional layer of abstraction plus all the conversion that's needed. For example, Apple just barely managed to make streaming spatial audio work on the airpods pro, and even then it has a noticeably shorter battery life then competitors, ~5 hours in ideal conditions.
- sampullman 3y ago
  You're right, I didn't explain very well. What I meant is that I think the abstraction of profiles is bad - just let the application deal with the ACL packets. Then, depending on what you care about, you can optimize your device better for throughput, latency, or energy use. Higher level protocols (profiles) can be handled by libraries, rather than baked into the spec.
  - izacus 3y ago
    Because profiles are the reason why Bluetooth is a thing and other wireless protocols aren't? The lack of profiles and demand for proprietary crappy iot apps is a problem, not a solution for the standard.
    - sampullman 3y ago
      Bluetooth is a thing because the big players backed it in the late 90s. It's hard to say what it would look like now if profiles were at a different abstraction level in the spec. I see WiFi as a counterexample - the protocol doesn't make assumptions about your application and it seems to be successful enough. Agreed that lack of profiles and proprietary nonsense is a problem, but at least in my experience, it is much worse to deal with bugs baked into various implementations. In the past, getting maximum throughput (or minimum latency) between different devices required all kinds of nasty hacks. An escape hatch to the L2CAP connection would have been a lifesaver, or even better, if profiles were implemented outside the HCI layer. An OS update shouldn't be necessary to fix a bug in the heart rate profile.
  - MrBuddyCasino 3y ago
    > Higher level protocols (profiles) can be handled by libraries, rather than baked into the spec. But there needs to be a spec of a protocol in order to enable interop? The question whether it is baked into the protocol stack or distributed separately as a library doesn’t seem that much of a distinction. What is important is certification, because otherwise connecting different manufacturers would never work smoothly.
    - xyzzy_plugh 3y ago
      You're right, and if you're implementing a profile for a widget chances are you can stumble your way through the spec and get something that mostly works. The problem is that the cross product of hardware on the sending and receiving sides leaves sufficient gaps that you will be banging your head against the wall trying to figure out why a profile isn't working and it's because Vendor's part doesn't implement the spec properly. I sometimes wonder what a world where every radio is a software-defined radio and we can all just update our full Bluetooth implementation alongside our OS. Instead it's the worst case of "actually another CPU with closed source blob firmware" and so we're absolutely left stranded. I think what is being advocated here is moving profiles outside the implementation, into libraries we can port around, or e.g. the kernel somewhere, and I think that is indeed a step in the right direction.
      - MichaelZuo 3y ago
        How would you implement such a mechanism without introducing a lot of overhead?
        sampullman 3y ago
        Where's the overhead? Depending on your system the whole thing could be zero copy down to the DMA buffer. It's just a read/write protocol with a separate channel for commands.
        MichaelZuo 3y ago
        I'm not an expert on implementing Bluetooth in real life products, but something tells me it will be a bit more complex then that.
xyzzy_plugh 3y ago
> You can also get the worst of both worlds by trying to implement the Bluetooth HCI USB transport protocol! Are you me??? Truly this was entirely horrors that I will never unsee.

MichaelZuo 3y ago

The energy budget is too low to allow for an additional layer of abstraction plus all the conversion that's needed. For example, Apple just barely managed to make streaming spatial audio work on the airpods pro, and even then it has a noticeably shorter battery life then competitors, ~5 hours in ideal conditions.

sampullman 3y ago
You're right, I didn't explain very well. What I meant is that I think the abstraction of profiles is bad - just let the application deal with the ACL packets. Then, depending on what you care about, you can optimize your device better for throughput, latency, or energy use. Higher level protocols (profiles) can be handled by libraries, rather than baked into the spec.
- izacus 3y ago
  Because profiles are the reason why Bluetooth is a thing and other wireless protocols aren't? The lack of profiles and demand for proprietary crappy iot apps is a problem, not a solution for the standard.
  - sampullman 3y ago
    Bluetooth is a thing because the big players backed it in the late 90s. It's hard to say what it would look like now if profiles were at a different abstraction level in the spec. I see WiFi as a counterexample - the protocol doesn't make assumptions about your application and it seems to be successful enough. Agreed that lack of profiles and proprietary nonsense is a problem, but at least in my experience, it is much worse to deal with bugs baked into various implementations. In the past, getting maximum throughput (or minimum latency) between different devices required all kinds of nasty hacks. An escape hatch to the L2CAP connection would have been a lifesaver, or even better, if profiles were implemented outside the HCI layer. An OS update shouldn't be necessary to fix a bug in the heart rate profile.
- MrBuddyCasino 3y ago
  > Higher level protocols (profiles) can be handled by libraries, rather than baked into the spec. But there needs to be a spec of a protocol in order to enable interop? The question whether it is baked into the protocol stack or distributed separately as a library doesn’t seem that much of a distinction. What is important is certification, because otherwise connecting different manufacturers would never work smoothly.
  - xyzzy_plugh 3y ago
    You're right, and if you're implementing a profile for a widget chances are you can stumble your way through the spec and get something that mostly works. The problem is that the cross product of hardware on the sending and receiving sides leaves sufficient gaps that you will be banging your head against the wall trying to figure out why a profile isn't working and it's because Vendor's part doesn't implement the spec properly. I sometimes wonder what a world where every radio is a software-defined radio and we can all just update our full Bluetooth implementation alongside our OS. Instead it's the worst case of "actually another CPU with closed source blob firmware" and so we're absolutely left stranded. I think what is being advocated here is moving profiles outside the implementation, into libraries we can port around, or e.g. the kernel somewhere, and I think that is indeed a step in the right direction.
    - MichaelZuo 3y ago
      How would you implement such a mechanism without introducing a lot of overhead?
      - sampullman 3y ago
        Where's the overhead? Depending on your system the whole thing could be zero copy down to the DMA buffer. It's just a read/write protocol with a separate channel for commands.
        MichaelZuo 3y ago
        I'm not an expert on implementing Bluetooth in real life products, but something tells me it will be a bit more complex then that.

xyzzy_plugh 3y ago

> You can also get the worst of both worlds by trying to implement the Bluetooth HCI USB transport protocol! Are you me??? Truly this was entirely horrors that I will never unsee.