Re:Let's Talk About Beacons
by JoeAltmaier on Tuesday November 04, 2014 @03:08PM
(#8558761)
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.
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.
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.
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.