Incisor Wireless News

download our latest issue subscribe to incisor magazine
wireless blog

Monday, 17 August 2009

Why does Bluetooth still not work the way it should?

Anybody who knows me knows that I have been a supporter and promoter of Bluetooth technology since it first started to poke its head above the parapet, way back in 1998. But there is an elephant in my room, and its tusks are blue! Despite all the good work that the Bluetooth SIG and all its responsible member companies have done, it is still the case that Bluetooth phones, headsets etc sometimes don't work the way they 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 ....

Labels: , , , , ,

16 Comments:

Anonymous Anonymous said...

Having to reboot your N96 seems harsh!

It has a menu option 3 or 4 clicks from your the home screen to reconnect to the headset.

Finally, if devices have gone out of range for a few minutes, it is common for the headset to attempt reconnecting to the phone, but it will not do this for the whole 2 hours you may be away from your phone as it would reduce the standby time of the headset to almost zero. Now what would be good is if that N96 would try reconnecting to the headset the next time it had an incoming call ... many phones do do that ...

17 August 2009 16:41  
Blogger Vince Holton said...

Sadly, the re-connect option does not work and I have to power-off/Power-on again. The N96 also hangs on a regular basis requiring the hard re-boot. My N95 (CSR Bluetooth silicon) had no such problems, so don't take me for a Nokia basher. I believe the N96 uses Broadcom. I'm not saying that Broadcom is at the bottom of the problem, by the way!

It is time I changed my phone.

17 August 2009 17:20  
Anonymous Anonymous said...

This would be a non issue if the test houses were required to perform more rigorous (and sensible) interop testing before allowing devices to be Bluetooth qualified - so the problem is with the SIG, who are apparently unwilling to get their act together on this. Pressure from SIG members perhaps, based on fears of limiting sales?

It is maddening, because it entirely goes against Bluetooth’s original premise: a spec for a short range wireless standard emphasizing built in interoperability between competing developers products.

17 August 2009 20:58  
Anonymous Anonymous said...

It is most likely a Symbian stack issue.

17 August 2009 21:51  
Anonymous Anonymous said...

will a small NFC device that has capability to store all my trusted device being brought closer to device solve the problem?

Uma S

18 August 2009 05:02  
Anonymous Anonymous said...

quote:
"all my trusted device being brought closer to device solve the problem?"

Yes, and create even worse security issues. :(

18 August 2009 16:16  
Anonymous Anonymous said...

quote:
"This would be a non issue if the test houses were required to perform more rigorous (and sensible) interop testing before allowing devices to be"

The SIG provides the PTS tool for testing IOP, and the tool does that job very well. The Bluetooth specification defines the air interface, this issue is caused by the Symbian stack. This issue is fixed, but the N96 has not been updated.

18 August 2009 16:21  
Blogger Vince Holton said...

Very interesting dialogue going on here. Its a shame that most people are choosing to remain anonymous, but I guess there are political issues at play here.

I've been talking to the SIG as this case has been discussed. They assure me that they do take such matters seriously, and indeed are looking specifically at my observations. We may see some commentary on here.

I apprecate all input.

18 August 2009 17:13  
Anonymous Mike Foley said...

Your question is very valid and seems so obvious. To paraphrase: “Why don’t products implementing Bluetooth technology work the way they should?” Unfortunately, my first response is “how should products implementing Bluetooth technology work?” (Yes, I hear your grown.) But, the response is valid. The Bluetooth specifications consists of volumes of work defining radios, communication protocols, data formats, etc. At the top of the stack are profiles that define use cases. However, nowhere in the Bluetooth specifications is there a definition of how a product should implement Bluetooth functionality. I.e. what capabilities should a mobile phone contain? A PC? A car? When the Bluetooth specifications were first published, you could consider them a Swiss Army Knife and each manufacturer decided which blades to incorporate into their product because who would know better what their customers desire than the manufacturer? That approach may have been OK 10 years ago when the specifications were first published, but I believe in 2009 and 2010 we have to do more. Consumers are familiar with Bluetooth technology and its capabilities. As such, they have expectations of what a mobile phone implementing Bluetooth technology should do. Or a PC. Or a Car. The list goes on and on. In the past, the Bluetooth SIG has published implementation guidelines to define what a “good” or “proper” implementation of a product should do. I think it is time to dust those off and promote them again. This is what consumers expect.

Then of course there are simply implementations that contain bugs. This may be the example you sight in your post. I’m having the SIG test team look into this and the results still aren’t conclusive. I’d encourage you, and anyone else, that has problems using products containing Bluetooth technology to report those issues to the SIG. This can be done on the www.bluetooth.com web site or feel free to send me a mail directly. (mfoley@bluetooth.com) When we receive reports like this, we test them to determine why the products aren’t working as expected. There are many possible issues that we run across:

• One or both products may contain bugs
• The products may conform to the specifications and not interoperate
• The specifications may be ambiguous regarding how they should work
• Etc

Depending on what we find, we take a different course of action. If a product has a bug, we work with the manufacturer to get it fixed. We also add additional test cases to the qualification program such that other products with the same or similar bugs are found during testing. If products conforming to the specifications don’t interoperate or the specifications are ambiguous, we work report those issues to the appropriate work group to improve the specifications such that future products don’t suffer the same fate. As such, reporting problem issues is very important to ensuring that products implementing Bluetooth work well.

Thanks for posing this question and stimulating some thoughtful dialog,

Mike Foley
Executive Director
Bluetooth SIG, Inc.

19 August 2009 04:58  
Blogger Vince Holton said...

This discussion has also been running on LinkedIn, at the Incisor WPAN World group. We have had some feedbackl from the Bluetooth SIG itself/ Executive director Mike Foley commented as follows:


Vince,

Your question is very valid and seems so obvious. To paraphrase: “Why don’t products implementing Bluetooth technology work the way they should?” Unfortunately, my first response is “how should products implementing Bluetooth technology work?” (Yes, I hear your grown.) But, the response is valid. The Bluetooth specifications consists of volumes of work defining radios, communication protocols, data formats, etc. At the top of the stack are profiles that define use cases. However, nowhere in the Bluetooth specifications is there a definition of how a product should implement Bluetooth functionality. I.e. what capabilities should a mobile phone contain? A PC? A car? When the Bluetooth specifications were first published, you could consider them a Swiss Army Knife and each manufacturer decided which blades to incorporate into their product because who would know better what their customers desire than the manufacturer? That approach may have been OK 10 years ago when the specifications were first published, but I believe in 2009 and 2010 we have to do more. Consumers are familiar with Bluetooth technology and its capabilities. As such, they have expectations of what a mobile phone implementing Bluetooth technology should do. Or a PC. Or a Car. The list goes on and on. In the past, the Bluetooth SIG has published implementation guidelines to define what a “good” or “proper” implementation of a product should do. I think it is time to dust those off and promote them again. This is what consumers expect.

Then of course there are simply implementations that contain bugs. This may be the example you sight in your post. I’m having the SIG test team look into this and the results still aren’t conclusive. I’d encourage you, and anyone else, that has problems using products containing Bluetooth technology to report those issues to the SIG. This can be done on the www.bluetooth.com web site or feel free to send me a mail directly. (mfoley@bluetooth.com) When we receive reports like this, we test them to determine why the products aren’t working as expected. There are many possible issues that we run across:

• One or both products may contain bugs
• The products may conform to the specifications and not interoperate
• The specifications may be ambiguous regarding how they should work
• Etc

Depending on what we find, we take a different course of action. If a product has a bug, we work with the manufacturer to get it fixed. We also add additional test cases to the qualification program such that other products with the same or similar bugs are found during testing. If products conforming to the specifications don’t interoperate or the specifications are ambiguous, we work report those issues to the appropriate work group to improve the specifications such that future products don’t suffer the same fate. As such, reporting problem issues is very important to ensuring that products implementing Bluetooth work well.

Thanks for posing this question and stimulating some thoughtful dialog,

Mike Foley
Executive director
Bluetooth Special Interest Group

19 August 2009 09:04  
Blogger Vince Holton said...

It is good to know the Bluetooth SIG takes these matters seriously. It doesn't fix my immediate problem, but I guess I just got to stop talking about getting a new phone, and actually get a new phone. N97 ...? iPhone ...? Blackberry ...?

20 August 2009 11:21  
Blogger Vince Holton said...

This topic will be covered in Incisor magazine.

20 August 2009 20:02  
Anonymous Anonymous said...

You can put this in Incisor but no good will come of it. The reply from Mike Foley is carefully worded, but your N96 has bugs which newer models of S60 do not have. You can not expect consumer electronics companies to go back to every product and maintain them. You may even find the team that created the product finished the work 6 months before you could buy it off the shelves and that team has moved onto other projects.

25 August 2009 19:51  
Blogger Vince Holton said...

Hi Anonymous (perhaps again!).

My point was that the N96 is a current-ish, high-end phone. And the problems have existed from when I first took delivery. Saying that the engineers can't go back and retro-fix old problems doesn't cut it - the problems shouldn't have been there at the outset.

We shouldn't do too much finger-pointing at Nokia. It is far from the only company shipping Bluetooth-enabled products that don't work the way they should.

As you can imagine, because of my job many people in my social circles talk to me about their Bluetooth exeperiences. It is sad but true to say that the people who say "I love my Bluetooth XXXX" are far outnumbered by those that choose to take a pop at the technology.

I know that I am unlikely to be enamouring myself to the Bluetooth SIG by making public this discussion, but I do think that it is better that issues are aired, heads are taken out of the sand, and ultimately the world ends up with a better Bluetooth experience.

That is my goal.

26 August 2009 09:51  
Anonymous Anonymous said...

Somebody mentioned the PTS being available to verify interoperability. Unfortunately it may not fix your issue because the PTS can not impose a specific user interface. It requires functionality to be demonstrated, but if the method of demonstrating that functionality is to reboot the product then that counts as the product can perform the desired function. To an end user it is crazy and broken, to a test program it is an irrelevant quirk of the user interface.

21 January 2010 13:18  
Blogger Vince Holton said...

Well, about an hour ago the result of me finally getting on top of my 'which phone should I use' indecisiveness landed on my desk. I now have my first iPhone, and I am about to start learning just how well Apple has implemented Bluetooth. And trying to run my cellular life on an Apple platform while continuing to run my computing life on a Microsoft (W7) platform. How much fun is this going to be??? Watch this space!

21 January 2010 13:25  

Post a Comment

<< Home

Previous Posts
Subscribe to Posts [Atom]
About Incisor
Partner with us
Incisor Magazine
Incisor TV archive
Vince's Wireless Blog
testimonial

©1998-2008 Click IT Ltd. All rights reserved