Mapping the Bluetooth stack
· Harsha Vardhan Patri
Your phone finds your headphones in half a second. The smart device on the same desk takes what feels like a minute.
Both are Bluetooth. What separates them is the negotiation that happens before either side says "connected" — invisible when it works, close to undiagnosable when it doesn't.
What gets agreed before "connected"
A peripheral announces itself on a schedule, and how often it does that trades battery life against how quickly anything can find it. Once found, the two sides settle on how often they will speak. That is the connection interval, and it is the difference between a device that responds and one that appears to be asleep.
They also agree how much data fits in a single exchange, which is the MTU. Underneath all of it sits GATT — the services and characteristics that decide what one device can even ask another for, and what turns up unprompted as a notification.
Getting three things to agree
A central hub, the peripherals around it, and a companion app in somebody's pocket all have to hold the same picture of what is connected and what it is doing. Harsha mapped the whole stack to get them there.
Where the spec stops helping
The specification is not the hard part. The gap between it and the devices people actually own is. Connections drop as someone walks out of range. Failures happen silently on one OS version and nowhere else. Something correct on paper behaves differently on hardware you did not choose.
One entry in his log reads: why is MTU dropping on Android? Answering that kind of question is most of the work, and it goes log by log rather than by rereading the standard.
Why it's the backbone
None of this shows up in a finished product. It is the layer everything else stands on. If the hub cannot hold a steady conversation with a sensor, nothing clever further up makes the device trustworthy.