I wonder if GPT et al. would help with this kind of thing, or if it's too esoteric.

Bluetooth is huge and designed by committee. I don't know what GPT could help with; it's not that there aren't any good guides, it's that good guides are impossible. The protocol and stack are not designed to be understandable by a single human mind.

...unless it's the mind of Fabrice Bellard.

If you thought BT was huge, the cellular mobile specs (ETSI GSM etc.) are more than an order of magnitude bigger and more complex.

There is a document for the 3GPP specs that contains a list of the abbreviations used in the rest of the spec...

Its an 80 page document.

The ETSI documents I saw all tried really really hard to “don’t repeat yourself”, and, as far as I can tell, succeeded at that.

So, I guess this is a document that has two columns, the abbreviation and a reference to the document that defines it, without mentioning the long form?

I have worked on 3GPP implementations and honestly, not as bad as Bluetooth.

LLMs generate content that's statistically plausible, not factually accurate. We don't need more content about USB that might be mostly right.

I thought the USB specs were already LLM written? How else did we get USB Type C 3.2 Gen 4x4 AWD Superspeed 4.0 kbps?

this comment actually makes me mad because of how close to reality it feels. :-P

If you think about it, USB cables and ports are themselves nondetermistic, probabilistic models of connectivity :D

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!

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.

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.

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.

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.

> 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.

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.

How would you implement such a mechanism without introducing a lot of overhead?

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.

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.

At the HCI level the Bluetooth protocol is sane enough, it's straightforward to provide a zero-copy interface to the L2CAP layer if you're writing your own host stack.

A product I worked on in the past used a serial connection over Bluetooth to Android/iOS apps. In order to communicate to an Apple device, the layers roughly looked like:

Radio -> L2CAP -> RFCOMM -> iAP2

The RFCOMM/iAP2 part were redundant. It's understandable that Apple wanted to certify devices, but implementing that as a thin layer over L2CAP and making the profiles on top optional would have made the system much simpler. There may have been historical reliability concerns on the Bluetooth side that justifies what they ended up with, I'm not sure.

Absolutely, certification is necessary for manufacturer interop. But I do think separating profiles from the stack would have saved a lot of headache, especially in the early days. Each implementation had tons of bugs, and it was often impossible to do anything about it unless you were an OS/module vendor, or were otherwise in a position to deploy your own HCI firmware.

This cuts both ways: a vendor willing to fix things can if it is just about updating a library, but then a vendor that doesn't give a crap and who will never roll out fixes leaves a user stranded. But if the fix is part of the OS, every user will benefit from it, regardless of his device manufacturer.

I think in practise we have a mix anyway - manufacturers already license BT stacks from a few vendors, and don't develop them themselves.

> 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.

The best book on BLE is "Bluetooth Low Energy Developers Handbook" by Robin Heydon

It is responsible for what has become of my career these past 6 years or so.

I don't know if you were looking at more than BLE. If you are, I don't know of a good resource.

I love a good book to build a solid foundation for understanding, and understand that you can't rewrite the fundamentals every release, but does it matter that this book was published in 2012? I expect it doesn't cover all the highly relevant IoT features added in 4.2 and 5.0 and on...

The book doesn't cover things added after it was published, correct

Of course, I don't expect it to!

But in the past 6 years of your career, I expect you've studied those things a lot more than I have. Do you think that the book is still a good starting point for someone looking to progress beyond dumping confusing vendor binaries in off-the-shelf Bluetooth modules that seem to be energy hogs, to miniaturize and integrate custom firmware and onboard antennas on my PCBs?

yes, I highly recommend Heydon's book, even in 2023. The tech stack including l2cap, connection establishment, advertising, connection parameters, security, GAP, GATT, are all still relevant.

It's a good recommendation, but I'd prefer the whole thing were less complicated so, like USB, I could figure it out in a few days, finish my work and move on with my life.

I certainly appreciate one being able to make a career out of these things, but I'd rather not.

I would love to see a writeup that made bluetooth usable in a couple days. I suspect the aspects that make Bluetooth useful also make it too complicated.