undefined | Better HN

0 pointsmojuba11y ago0 comments

Pairing is an equivalent of connecting devices with a physical wire. When you stream music you want to know exactly where it goes, or e.g. which BT headset is connected to which phone in the room.

Pairing can be combined with connecting in a lot of situations though, and I believe the Bluetooth standard, as well as implementations are moving towards simplification. For example, I'd rather have a list of BT audio speakers around me directly in my music player app, then I'd just tap on one of them and hear music playing straight away. This is a protocol/API/UI issue rather than a fundamental limitation.

0 comments

3 comments · 2 top-level

JoeAltmaier11y ago· 1 in thread

I've always thought BT pairing kind of backward - the computer is the 'master' in the protocol; the headset is the 'slave'. But its the headset I have picked up; I know which one I have in my hand, but the computer (iphone/music station) knows about many of them. So I have to select one from a list, and maybe I don't know which one in the list is the one in my hand. MAC address? really. How about vendor string? What if I have two of those? A mess.

Instead, the headset could scan for the computer, select it and voila we're bound.

mojubaOP11y ago

True, and actually some cleverly designed BLE devices advertise only for a limited time after pushing a button. I don't see why classic BT devices shouldn't do the same and work (almost) like you described: only advertise for a minute or two when asked to, and shut up for the rest of the time.

m_eiman11y ago

Using un-paired BLE devices you can do things such as adhoc mesh networking, which isn't possible with "old" Bluetooth. That's kind of cool, and possibly useful.

I agree that general Bluetooth usability could be improved - having to switch to an OS-provided, generic "add device" wizard before being able to use any Bluetooth device is just UX murder.

j / k navigate · click thread line to collapse