Why does Bluetooth still not work the way it should?
Example - I use a Nokia N96 with a Jabra JX20 headset - both high-end products from respected companies. The two are paired and work OK on first connection. But, if I go out of range, or switch the headset off for some reason, they then will not reconnect. I have to switch the headset off and re-boot the phone. In a given day this can happen several times. Most frustrating.
After 11 years of Bluetooth development, and with two products from a couple of the most respected manufacturers, this really shouldn't be happening. And this isn't isolated. A lot of kit passes through our hands, and similar things happen all the time. I'm in the industry, so I keep using this kit, but what will consumers be thinking?
I've put the question to the wireless community, and Peter Hauser, CEO of The Quality Factory came back with these observations?
I'm surprised nobody is willing to comment here!
Your question: "Why does Bluetooth still not work the way it should?" is more a question about "Quality" than it is about "Conformance to the Bluetooth standard" and therein lies the problem...
First of-all, there will always be a struggle between innovation and conformance to a standard. Every company wants, and needs to innovate. This implies that every company seeks to use the standards in new and interesting ways, and when they do, they make "assumptions" as to how other, compatible products, will react, thus creating the first problem...
For instance, the Bluetooth standards speak little about timing tolerances for commands and responses (beyond the standard timeouts). Some devices can respond very quickly to a command, while others cannot. If, however, a device is EXPECTING a delayed response and instead receives a very rapid one, if the firmware is intolerant, it could cause the device to lock-up.
Also - the Bluetooth standards do not currently address most multi-profile scenarios. It is only recently that the common "HFP, HSP, A2DP, and AVRCP" in a single device scenario was examined more closely for integration into the specifications AND the play/pause behavior (you know, where Play means Play, and Pause means Pause) has changed between the whitepaper and the specifications.
In short, unless companies are willing to invest in clarifying and standardizing their assumptions, these types of problems will continue.
And then, there's the issue of QUALITY.
With Bluetooth technology's pull towards commoditization, this complex technology is now in the hands of implementers who don't understand its intricacies and are building products based on new assumptions. Couple that with reduced development budgets for commodity products, and you have all of the makings of a reduction in product quality.
Teams are no longer "expected" to attend such events as UPF and to conduct extensive interoperability tests. Instead, they are expected to keep development budgets as low as possible.
All the while, new platforms are opening-up APIs that enable 3rd party applications to affect the Bluetooth performance. For instance, a mobile phone may have three separate music players on it. If one of those music players interacts with the Bluetooth A2DP/AVRCP (music) stack in an unexpected fashion, it could damage otherwise solid interoperability with wireless stereo headsets.
So - I guess the answer to your very simple question is quite complex.
If companies are going to do a really good job making their solutions "work" in the real world, they need to take the time to understand the assumptions made by products that already exist in the marketplace (of which there are many), find the similarities in these assumptions, and design accordingly.
Then, they need to TEST, TEST, and TEST again.
Thanks, Peter. Other contributions on this topic are very welcome. In the meantime, I may just have to change my own gadgets on a more often basis to check whether this situation is getting better, or worse.
After all, a Nokia N96 has been around for quite a while now ....