What I Don't Like About BlueTooth

[Jason Dunn]

<div class='os_post_top_link'><a href='http://articles.pocketnow.com/content.cgi?db=articles&id=92' target='_blank'>http://articles.pocketnow.com/conte...=articles&id=92</a><br /><br /></div>Russ Smith from Pocketnow.com has written a very thought-provoking article on Bluetooth. This isn't the usual "Bluetooth Sucks" or "Bluetooth Rules" rhetoric we sometimes see - Russ approaches it from a deeply technical level, and this isn't something I had thought about previously. Make me wonder if Bluetooth has what it takes for a long life.<br /><br />"As you've no doubt read elsewhere, Microsoft has decided to embrace the BlueTooth technology and support it on an operating system level in a revision to Windows XP. That's good news from the standpoint that it will help to solve some of the conflicting implementation problems. Unfortunately, BlueTooth has a number of problems, inherent in its design, which have nothing to do with how well it's integrated on the desktop.<br /><br />These problems all result of the BlueTooth standard trying to do too much. Because of that, many BlueTooth implementations can't do enough. Clear as mud? Try this: The creators of BlueTooth violated one of the key rules of networking: You don't mix the way in which information is transferred from one device to another with the services the device offers. The mechanism and protocols for moving packets of information from one device to another is a "low-level" function. Higher level functions such as file transfers, data security, and resource access, shouldn't care at all how the packets are moved. All they care is that they ask for some data and it gets there."

[Wuss912]

that and speed issues
bluetooth is just too sloow,,,

[Will T Smith]

I know for sure that the designers of Bluetooth were aware of the difference between application protocol and transport. Bluetooth designer DELIBERATLY schewed this line in order to provide greater interoperability.

You have to remember that Bluetooth was NOT intended as a generalized network. It was meant as a replacement for cables.

Which cables ????? Well, that's just the problem. That's why Bluetooth defines application profiles. Without this, vendors would go off and implement their own protocols on top of a network transport. This is not a strategy for success.

Wi-Fi doesn't do the same. However, it doesn't have to. Network application protocols are by now, very well defined. http:, ftp: gopher:, https:, ping, etc... These are products of MANY long years of work by the academic community. They didn't spring from a commercial venture with a 2 year development cycle.

Considering that Wi-Fi is riding 30 years of development and Bluetooth is effectively starting fresh, I think they've made pretty good progress.

[Janak Parekh]

So this is one of the great debates about Bluetooth - whether it should have violated the layered networking model or not.

If you view Bluetooth as a networking technology, then it did something it shouldn't have.

If you view Bluetooth as what it's supposed to be IMNSHO, a cable replacement technology, then the vision fits. There are different kinds of cables ("profiles"). Some of them support Ethernet ("LAN profile"), serial/RS-232 ("async"), or audio ("headset").

Incidentally, note the LAN profile I mentioned above - you can use Bluetooth in the ISO reference model just fine - just make it talk to other BT devices as a LAN entity.

Why do this? So you don't need a headset that, for example, implements TCP/IP (or NetBEUI) and needs to have an IP address!

Re security: this is also controversial. It's not clear at what layer security should appear - whether it's at the application (a la SSH and HTTPS) or at the network layer (IPSec), or at the physical layer (locked-down cables and Bluetooth). It's not really fair to say a physical-layer security model is outright wrong; it has its advantages and disadvantages. Do you want to see a Bluetooth headset not only implement IP but IPSec? OK, maybe we do, but there's advantages to using just the Bluetooth headset profile!

--bdj

[Janak Parekh]

Doh; Will, you typed that darn fast or pipelined just ahead of me :)

Well, I'm not the only one who sees the "intended vision" behind Bluetooth. ;)

--bdj

[Jason Dunn]

Interesting thoughts guys. One thing I seen quite often is missing profiles - ie: you get someone releasing a device that should work with another device (let's say a Pocket PC and a headset) yet the profile isn't there. I guess that's the limitation of profiles - they need to be created. In comparison to a networking protocol, which doesn't have that limitation.

I guess we'll see if over the next few years Bluetooth gets hammered out to the point that every device will include every applicable profile.

[jim s]

In comparison to a networking protocol, which doesn't have that limitation.


Seems to me that there is the same potential limitations with networking protocols. Say you buy a new NIC for your PC and go to install it and connect to your Novell 2.11 network. It very well may not have drivers for that protocol.

[Bob Anderson]

I guess we'll see if over the next few years Bluetooth gets hammered out to the point that every device will include every applicable profile.

And therein lies the "rub". If manufacturers don't take note of that, then users will complain that devices don't work well, dooming Bluetooth... However, if manufacturers do include all the profiles, then the less sophisticated users will get confused by all the options.

I think Bluetooth is a great PAN technology. I can't wait to put it to good use with my forthcoming ipaq 5450!

[MooseMaster]

It's my personal opinion that bluetooth should be relegated to Digimon toys.
There are already much better, much easier, much cheaper, and much more efficient means of wireless connections (including IR, of all things). I really wish that bluetooth were better, but it's not and it doesn't fit my needs, and the majority of the industry sees that also, just looking at the number of bluetooth cell phones available (the most toted bluetooth feature, wirelessly connecting to your cell phone to surf the internet, or using a headset) should reveal that fact.

[SteveNYC]

, just looking at the number of bluetooth cell phones available (the most toted bluetooth feature, wirelessly connecting to your cell phone to surf the internet, or using a headset) should reveal that fact.
Followed up closely by the large number of Wi-Fi cellphones, correct? :wink:

Just having some fun. :D But I do think your comment touches upon a good point. It's not for everyone's needs and I think much gets lost in the realm of better = faster or even WiFi vs. Bluetooth. Bluetooth is a wireless way to remove cables from the equation.

I don't see the two being used for the same purpose. I don't need WiFi for connecting a GPS receiver to my PDA or for printing to a local printer. I do need WiFi if I want to stream video (compressed) or if I want to transfer large files as quickly as possible. To me, Bluetooth and WiFi are in many ways complementary. It's like a Palm vs. Microsoft debate..... hehe, sorry, just had to throw that in there.

[st63z]

Haven't read the article, but very well put Will & Daddy (P.S. IPSec operates at network layer?)

Also seems to me MS likes the layered networking model for Bluetooth *exclusively*...? TCP/UDP txport/IP network datagrams as baseline...

[EricMCarson]

I can definitely see Bluetooth and WiFi as complementary technologies. I do not see profiles as an impedance to the long-term success of bluetooth. In fact, it gives the user a simple way to "replace wires" of their certain devices. I remember a point in time (prior to 1990) when http and ftp were hard to use and very few people saw potential in them. Now, we couldn't live without them. I really believe Bluetooth will be that indispensable within the next few years, particularly in devices where low power consumption is a necessity (pretty much anything portable).

[sweetpete]

I think a lot of people are missing the point in what Russ is trying to describe in the article (read his forums and he tries a couple times to explain himself) ... I'll try and summarize what I think he's saying because it's something that has frustrated me about Bluetooth.

1. He's not doing the age old Bluetooth vs. Wi-Fi comparison and which is better. He realizes they are complimentary technologies and likes both. He only uses Wi-Fi to point out a better "technical" implementation of what he sees to be a problem in Bluetooth, not it's intended use.

2. What he sees the problem to be (and I agree completely) is that the implementation of the Profiles is totally pooched. I'll try and explain through an example:

My 3870 has a limited number of profiles which are mostly hidden from the user. We just know them to be the Serial profile, phone profile, etc (not sure of the exact names, but hopefully you get what I mean).
Now, out comes MS with a snazzy Bluetooth keyboard. I buy this for my desktop, but hey, how about I use it with my Bluetooth iPaq. No, I can't ... why, because, even though the Bluetooth hardware is compatible between the two (i.e. at a low level these 2 devices can communicate), my iPaq doesn't have the keyboard profile. I also can't add the profile, because it's not only part of the stack (which could be upgraded as Compaq has done in the past), but it's also hard-coded into the Bluetooth chipset that Compaq put into the device when they built it (and this CAN'T be upgraded)

Now, what Russ is trying to say, is that if the creators of Bluetooth were to have implemented the protocol similar to Wi-Fi (or other networking protocols ... it is after all a Personal Area Network )and seperated the profiles out of the hardware, I still could have used the keyboard with a much simpler to do stack upgrade (aka. Bluetooth driver).

This can be extended further, but I hope that explanation shows the inherent weakness he's trying to describe.

I don't think doing stack upgrades (which already have to be done in the case of the iPaq) would make Bluetooth any harder to use than it already is. Others are trying to point out that it simply replaces wires, save on battery, etc. This is true, and by having implemented it in this way, none of that would have changed.

This isn't a comparison about why Bluetooth is better at it's intended use over Wi-Fi. It is simply intended to point out that, from a technical standpoint, it could have been done in such a way to make it more extensible to future applications if they should come along (as they have in the case of my keyboard example), without having to throw out perfectly good hardware (my 3870) to do it. He does talk about security, but to me that is another issue ... my beef is with the lack of this upgradeability.[/b]

[sweetpete]

In comparison to a networking protocol, which doesn't have that limitation.


Seems to me that there is the same potential limitations with networking protocols. Say you buy a new NIC for your PC and go to install it and connect to your Novell 2.11 network. It very well may not have drivers for that protocol.

I don't think you are correct here. The difference with your example and Bluetooth is that the manufacturer can come and write a driver for the Novell 2.11 network because there is nothing in the NIC hardware that is limiting this, it's a lack of software.
With the Bluetooth profile, it's a problem of both not being there. The software could be addressed, but what Russ is saying, is by also embedding profiles into the hardware, it stops you from being able to do this.

[wastl]

I compare Bluetooth with Wap!

Good indention, good idea BUT not doing what is suppose to do and that
is:

EASY - you can forget that judging on my grey hair that I suddenly got from trying to configure PocketPC, PC, Mobile Phone and Headset and I am 30 years in the computer industry.

SPEED - sure it is fast when you compare it with my old 14.400kps Modem form last century.

NO CABLES - good idea but where are all the keyboards, mice, printers, speakers with build in Bluetooth???? (oh yes, and don't forget to buy 10 years supplies of batteries, you might need them all within a couple of month!!!)

So Wap is slowly disappearing and so will HOPEFULLY Bluetooth too cause it is simple to complicated and to slow.

Cheers

[Janak Parekh]

Now, out comes MS with a snazzy Bluetooth keyboard. I buy this for my desktop, but hey, how about I use it with my Bluetooth iPaq. No, I can't ... why, because, even though the Bluetooth hardware is compatible between the two (i.e. at a low level these 2 devices can communicate), my iPaq doesn't have the keyboard profile.
Well, what Microsoft should have done is to use the async or LAN profile, then you'd have full backwards-compatibility, and would just need a software driver on top. In fact, do we know what profile they used? Besides, let's say the keyboard used Wi-Fi, and MS implements some proprietary TCP-based protocol. You could only use the keyboard on computers that happen to support their driver. That's not interoperable either. (In fact, from the news I read about the keyboard, it does seem to be some proprietary protocol on top of a Bluetooth connection... I don't think it's a profile, actually, since it's only supported on XP SP1. We'll get more details as we go along.)

I also can't add the profile, because it's not only part of the stack (which could be upgraded as Compaq has done in the past), but it's also hard-coded into the Bluetooth chipset that Compaq put into the device when they built it (and this CAN'T be upgraded)
Well, I'd rather attribute that to the Bluetooth chipset vendor's fault. Why not make it extensible?

Now, what Russ is trying to say, is that if the creators of Bluetooth were to have implemented the protocol similar to Wi-Fi (or other networking protocols ... it is after all a Personal Area Network )and seperated the profiles out of the hardware, I still could have used the keyboard with a much simpler to do stack upgrade (aka. Bluetooth driver).
Except the keyboard would need IP! You'd have an IP address for the keyboard. The power consumption for the extra IP traffic would be enormous. The keyboard would lose 80% of its battery life.

That's why they made it a cable replacement protocol, not a network protocol.

This can be extended further, but I hope that explanation shows the inherent weakness he's trying to describe.
It's a double-edged sword.

This isn't a comparison about why Bluetooth is better at it's intended use over Wi-Fi. It is simply intended to point out that, from a technical standpoint, it could have been done in such a way to make it more extensible to future applications if they should come along (as they have in the case of my keyboard example), without having to throw out perfectly good hardware (my 3870) to do it.
But, again, as I've said, if you want to use it as a OSI link-layer device, you can.

--bdj

[Janak Parekh]

I don't think you are correct here. The difference with your example and Bluetooth is that the manufacturer can come and write a driver for the Novell 2.11 network because there is nothing in the NIC hardware that is limiting this, it's a lack of software.
Hmm, actually, probably not. Novell 2.11 could never support IP, because it would probably require some intrinsic changes in the kernel as to how its network stack is architected. Novell was built IPX from the ground-up, which layers differently than TCP/IP.

--bdj

[Janak Parekh]

So Wap is slowly disappearing and so will HOPEFULLY Bluetooth too cause it is simple to complicated and to slow.
I understand your comparison, but sorry, it ain't valid. You're comparing a application to a network-layer device. Bluetooth, with good implementations, is easy, decent performance, and it works. Get a T68 and a 3970, you'll know what I mean :)

--bdj

[Janak Parekh]

Haven't read the article, but very well put Will & Daddy (P.S. IPSec operates at network layer?)
Yes. The idea of IPsec is that you can run TCP, UDP, etc. right on top of a secure IP connection as opposed to an insecure one.

Also seems to me MS likes the layered networking model for Bluetooth *exclusively*...? TCP/UDP txport/IP network datagrams as baseline...
Hm? Bluetooth doesn't require IP as the underlying network-layer protocol.

--bdj

[SteveNYC]

I don't think you are correct here. The difference with your example and Bluetooth is that the manufacturer can come and write a driver for the Novell 2.11 network because there is nothing in the NIC hardware that is limiting this, it's a lack of software.
With the Bluetooth profile, it's a problem of both not being there. The software could be addressed, but what Russ is saying, is by also embedding profiles into the hardware, it stops you from being able to do this.

Coincidentally, I think I just came across a good example for your position. I was just researching the idea of using a Socket Bluetooth compactflash card on a PocketPC PDA to connect via activesync to my PC and how well that would work. In my surfing I came across a post by someone who was discussing how they were frusutrated by the fact that the Microsoft Bluetooth transceiver that came with his Microsoft Bluetooth Intellimouse could not currently be used to sync Outlook with his T68 cellular telephone because the transceiver lacks a serial profile. That's the condensed summary of the thread, but it was interesting. I think it illustrates your point well.

Here's the thread if anyone is interested.

http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&safe=off&threadm=00dd01c28b9d%24b632bce0%248ff82ecf%40TK2MSFTNGXA06&rnum=9&prev=/groups%3Fq%3Dbluetooth%2Bactivesync%26hl%3Den%26lr%3Dlang_en%26ie%3DUTF-8%26safe%3Doff%26scoring%3Dd

I know, it's long. Sorry.

[Janak Parekh]

because the transceiver lacks a serial profile. That's the condensed summary of the thread, but it was interesting. I think it illustrates your point well.
I really should go reread the Bluetooth specification, but it seems pretty serious that they missed the async profile. That might be grounds for Bluetooth non-compliance; I mean, that's one of the basic profiles!

What the Bluetooth SIG should be better is in policing this and making sure at least a workable base set of profiles works for all implementations. That should solve a lot of the practical problems that people are encountering. I agree they've been pretty remiss on this.

Still, you should be able to buy a USB Bluetooth adapter and use it both with the MS keyboard and with the PocketPC.

I know, it's long. Sorry.
Use www.shorterlink.com in the future :)

--bdj

[sweetpete]

BigDaddyJ

Again, I don't think you see either Russ' or my point. No one is saying that BT should be a network protocol per se, it regarding the implementation of the technology. Just because a protocol emulates some aspects of the OSI model, it doesn't mean it has to be exactly the same, or be IP based. That's not what I'm asking for.
You say that you could make the chipset extensible ... true, you could, but that would require more expensive Flash chips and the architecture to do firmware upgrades and the manufacturers didn't do that either (notice, I'm not saying that my way is the only way, it's just one of many that wasn't done and I just would like one!)

On a final point, you mention my example (which granted may not be the best) in saying that MS could have use a LAN profile ... funny thing is, the iPaq 3870 doesn't support that profile either and the not so funny thing is, I can't change that :evil:

[Janak Parekh]

Just because a protocol emulates some aspects of the OSI model, it doesn't mean it has to be exactly the same, or be IP based. That's not what I'm asking for.
OK - maybe I'm not understanding the argument here. Let's say Bluetooth is abstracted as a standard OSI physical/link-layer model, i.e., it's the network card in WinCE. What protocol are you going to run on top of it, if it's not IP? Let's say BlueToothP. What does BlueToothP support? If it's generic, like IP, it's not going to be efficient for low-power devices. But OK, let's leave BlueToothP as the standard, maybe they do something much smarter than the IP guys. Then what is the actual application protocol on top of BlueToothP? Who supports it? You still need operating system and driver support.

Now, in an "ideal" world, let's say the Keyboard profile was supported in Bluetooth 2.0. Then, you grab any Keyboard and any Bluetooth 2.0 transmitter, and bond them. Done. No drivers. Of course, this is assuming there is a Keyboard profile. Let's say there isn't. Then bond the two using an async connection (basically what USB does), and install drivers. Done. Not nearly as ideal, because you're relying on proprietary drivers, similar to above (but fewer layers, since we're deliberately not layering).

I may be wrong, but I still maintain it's a lot more complicated then we are making it out to be on this board :D

You say that you could make the chipset extensible ... true, you could, but that would require more expensive Flash chips and the architecture to do firmware upgrades and the manufacturers didn't do that either
Ah, this gets interesting. BTW, all WiFi products do use Flash chips and support firmware upgrades. They are more expensive. :) We can't win either way! :lol:

On a final point, you mention my example (which granted may not be the best) in saying that MS could have use a LAN profile ... funny thing is, the iPaq 3870 doesn't support that profile either and the not so funny thing is, I can't change that :evil:
Really? I was pretty darn sure there's a LAN profile. I have read, on webboards, of people surfing the net with a Bluetooth access point and 3870 units.

(Searching...) Indeed, TinMan was using the Lan Profile on 3870's. See http://shorterlink.com/?3BYZH7. I haven't tried it (yet), admittedly, because, I haven't had a reason to.

Sorry for being so emotional in the last posts, btw. We may just have to agree to disagree, and see how Bluetooth 2, which will hopefully be more evolved, plays out.

Does anyone know how UWB (Ultra WideBand) will be implemented?

--bdj

[vincentsiaw]

reding to much made me confuse, so which one i should choose for my house network, wi-fi or bluetooth?

[Janak Parekh]

reding to much made me confuse, so which one i should choose for my house network, wi-fi or bluetooth?
Probably Wi-Fi if you're networking mostly computers - better range and faster. A Bluetooth LAN is only really useful for handhelds if you plan on doing long surfing sessions with them. Besides, Wi-Fi network access points are cheap right now due to their popularity.

This coming from the Bluetooth proponent ;) Honestly, I don't mind Wi-Fi at all. That's why my next unit's going to be a 5450...

--bdj

[sweetpete]

reding to much made me confuse, so which one i should choose for my house network, wi-fi or bluetooth?

Definitely WIFI ... if you're looking for a wireless network, that is what you should use as your first choice. Bluetooth is intended as cable replacement, though you can use it for a SLOW wireless network (maximum speed is around 1 Mbps vs. 11-54 Mbps for WIFI)

[Kati Compton]

I like the range on WiFi - I can go out to the garden and use my computer. At least, when it's not too hot and not too cold. ;)

[sweetpete]

BigDaddyJ,

I was looking through my 3870 and I can't see anything that would point to it having LAP. If you find something in yours or another more specific post, please let me know. One thing that leads me to think it doesn't is that my Anycom Bluetooth CF adapter (that has LAP) can't establish any such bond with the 3870. I can only do AS bond with passthrough to surf.
I've tried to search the new HP's site for information on what profiles the iPaq supports, but the closest link I could find is a compatibility matrix (http://www.compaq.com/products/wireless/wpan/btcompmatrix.html) that covers what profiles the other devices support and if they are compatible. If you look, a couple of the AP's it's compatible with don't have LAN access profile, only generic access and serial profiles. Obviously that doesn't mean the iPaq doesn't, it's just compatible because it supports the others.

Anyway, like you say, we may have to disagree. I still like my BT products and use them regularly for the intended use (no cables). I just wish that as new products come out, based on the same Bluetooth 1.1 spec my products support, that they would be compatible.

A final example (not that I'm trying to get the last word in or anything :lol: ) is the lack of support for the headset profile on the iPaq. Granted one may argue that it's only good for phones, but I could think of a lot of uses for a wireless headset and my iPaq. One, I could listen to mp3's. Two I could use the mic to record voice memos. Three, I could use it with the combined IBM via voice software to look up phone numbers or have it read back emails, all while it's sitting in my bag or pocket ... and all without wires. But then again, no headset profile because Compaq didn't think it would be useful at the time they put the product together. :evil: At least with some upgrade path, these things could be added by a headset manufacturer, or Compaq themselves ... right now that choice is removed. You get my gist.

[numo]

Well, this is not new - we have several cases where there is a rigid over-complicated technology and then someone makes the same on top of TCP/IP. Go read the OSI standards for networking (X.25 and similar) and then read the TCP/IP RFCs. Been there, done that (implemented a part of an OSI stack for a major company) - the countless possibilities and options in OSI regarding what to implement where are much easier to get wrong than the simple architecture of TCP/IP. The idea of device defined set of profiles in BT is also not new and probably comes from the same source.

The problem is that the Wi-Fi came too late. Technically it would be no problem to use a scaled down 802.11b radio (less power and/or eventually slower bitrates to limit the power usage) and to implement all the BT features on top of this. Practically the BT was (nearly) here before the Wi-Fi really took off (at least in Europe) and there was too much money invested into it.

I hope that someone makes the chipsets capable of doing both and the world will slowly shift to Wi-Fi-only applications with all of the features such as discovery, profiles or whatever they are called implemented as a clean pluggable architecture that is easy to upgrade in the devices.

Just MHO.

[sweetpete]

numo,

You've made some interesting points that I think have been overlooked when it comes to 802.11. I keep forgetting that one reason WLAN cards consume so much more power is they transmit at upto over 10 times the speed and up to 10 times the distance of BT. I'm sure there are other things that might play into this, but that is surely a large factor.
I'm very intrigued about some of the auto-discovery networks being proposed. It's still pretty early on, but this could lead to a technology with similar uses (there is the front page article about a company working on this, but I also recall Apple working on something similar too)

Anyway, time will tell where this takes us. I really hope that the BT SIG works on better implementation of the technology. Whether that's through better policing of compliant products, a better core standard that is extensible, or what ... who knows. It just needs some improvements in key areas if it is to survive the upcoming onslaught of different wireless technologies that could displace it by adding the benefits of BT.

[numb]

BigDaddyJ wrote:
Still, you should be able to buy a USB Bluetooth adapter and use it both with the MS keyboard and with the PocketPC.


Are you sure? I asked this question a while ago and the concensus seemed to be that it wouldn't work. Do the USB adapters support the right profile...there's a human interface profile mentioned in one of the links..wouldn't they need to support this?

[johncj]

Bluetooth is BAD (Broken As Designed). It's supposed to be a cable replacement. If I buy two devices that communicate over Bluetooth, I need to know whether or not they will communicate with each other. Today, there is simply no way to know that.

Some protocols require all devices that support the protocol to interoperate (WiFi, IP, etc.). Other protocols have well established rules (Ethernet, USB, etc.). Successful communication protocols are simple to implement, predictable in use (no surprises), and more desirable than the alternatives. Bluetooth fails on all of these measures, and the failure is inherent in the design.

[Janak Parekh]

Bluetooth is BAD (Broken As Designed). It's supposed to be a cable replacement. If I buy two devices that communicate over Bluetooth, I need to know whether or not they will communicate with each other. Today, there is simply no way to know that.
In my opinion, I don't think the design is the problem here, but rather the teeth of the Bluetooth SIG. They should have been able to dictate to MS "use the async profile" or somesuch and required their Bluetooth adapter, if it was 1.1 compliant, to include that profile.

I mean, USB is basically a next-generation asynchronous communications medium. The asynchronous concept is in Bluetooth, so the idea of using Bluetooth as a USB replacement is not unheard of, for low-bandwidth applications.

Well, this is not new - we have several cases where there is a rigid over-complicated technology and then someone makes the same on top of TCP/IP. Go read the OSI standards for networking (X.25 and similar) and then read the TCP/IP RFCs. Been there, done that (implemented a part of an OSI stack for a major company) - the countless possibilities and options in OSI regarding what to implement where are much easier to get wrong than the simple architecture of TCP/IP. The idea of device defined set of profiles in BT is also not new and probably comes from the same source.
While your point is valid to some extent, BT is not X.25, thank goodness. There are advantages, with wireless devices, to violating the network layer model -- in particular power saving modes. BT has "idle", "discoverable", and "communicating" modes, with different power requirements. IP-over-WiFi can't support that by definition - IP is connectionless. I guess one could hack a TCP connection-oriented protocol for turning on and off the radio, but that sounds like a nasty solution.

I hope that someone makes the chipsets capable of doing both and the world will slowly shift to Wi-Fi-only applications with all of the features such as discovery, profiles or whatever they are called implemented as a clean pluggable architecture that is easy to upgrade in the devices.
I agree that convergence is a beautiful thing, but I'm not sure it's entirely possible here. Like I said tho, there's hope -- maybe Bluetooth 2 will define a fixed set of underlying profiles, that people must adhere to unless they have a specialty device -- and maybe those underlying profiles are sufficiently generic to cover most, if not all, applications.

If you find something in yours or another more specific post, please let me know.
So I went looking, and there is an Async net adapter in the Network Adapters icon... I wonder if you have to use the async profile to bind to the network adapter? Which would suck, but is better than nothing. I'll be interested in seeing whether or not the 5450 "fixes" this.

A final example (not that I'm trying to get the last word in or anything :lol:) is the lack of support for the headset profile on the iPaq. Granted one may argue that it's only good for phones, but I could think of a lot of uses for a wireless headset and my iPaq.
Of course you're trying to get in the last word, we all are :D The big problem with this is Bluetooth's 768kbps bandwidth is not really sufficient to support 44KHz, 16bit, stereo audio - you really need about twice that much. I will be watching the 5450's implementation closely, rumor has it that compression is involved.

Maybe our disagreement is less than we think. I think Bluetooth is actually well-designed as a technical protocol, but agree that the SIG needs to have more teeth and set more fixed standards and force vendor interoperability more. However - this takes time in any protocol. If you study the history of Wi-Fi, you'll see the 1Mbps and 2Mbps Lucent WaveLAN solutions--those 2.4GHz proprietary wireless LAN solutions had many interoperability and compatibility issues. Let's let the standard evolve before calling it dead :)

My biggest complaint about Bluetooth is so few freaking cell phones support it. There is hope though - the Ericsson T61c is now available for Verizon, and it (theoretically) supports a "Bluetooth SmartBack". I'm watching the cellular newsgroups closely to see if it works well.

--bdj

[sweetpete]

bdj

I think you're correct in taht we aren't really at major odds here :)

Some notes on what I discovered:
MS is actively involved in teh Bluetooth SIG. In fact, the chair of the SIG is an MS employee (Mike Foley).
HID profile is an accepted profile and not some hack. It's built on top of the Generic Access Profile.
http://www.bluetooth.com/dev/specifications.asp has lots of the technical info.

BTW, Windows currently supports HID profile, hardcopy cable replacement profile :?: , and the DUN profile. I ran into this with a PressPass (http://microsoft.com/presspass/features/2002/nov02/11-12WirelessBluetooth.asp) interview at Microsoft.

Anyway, I think we've beaten this dead horse once too many times. I agree with you that some of this will get fixed as the standard and the standards group evolves. It's just that they had a lot of time before the first products even hit the market to try and work some of these issues out. Frustrating for someone that owns several Bluetooth products and feels