Bluetooth Application Programming? 42
Comatose51 asks: "I've been desperately trying to create an application that uses Bluetooth over the last month. I've been frustrated by the lack of good books and lack of hardware compatible with readily available Bluetooth APIs. While Microsoft added Bluetooth support into Windows XP since SP1, most hardware vendors do not use the Microsoft Bluetooth Stack. Instead, they use other proprietary stacks that costs money to obtain the SDKs and APIs for. I had to buy the Microsoft Bluetooth Mouse to get their Bluetooth Stack and a compliant adapter, which is still many times cheaper than what some companies charge for their APIs and SDKs. Java is the other (potentially better, easier) option but I haven't found any hardware vendors that state that they're Java (JSR-82) compliant. Is there really no easy way of developing Bluetooth applications for Windows? It is sad because Bluetooth holds so much promise. Thanks in advance." Might Bluetooth's problems stem from the fact that there is no consistent development platform for the technology?
BlueTooth is just crappy. (Score:3, Interesting)
I just think BlueTooth could've been great, but its complexity and the lack of certain levels of standards doomed it.
I actually looked at the specs once, thinking maybe it would be interesting. After getting through the actual modulation used, which I didn't care about, I got to the part about establishing connections and stuff. It's horribly complex, and everything seems to be overdone, like someone had a grand vision, but couldn't figure out exactly how to make it work.
My other main problem with it is that it is missing a certain level of standards, which is the set of standards that would define the services a device offers. It does have a mechanism for indicating the type of device to which you are connected, but it seems only enough to pick an icon, not to decide what to actually say.
What it needs is a set of protocols, preferably XML-based, since XML is 31337, that can transfer files, send/receive photos, take pictures, record audio, dial/talk on phone calls, etcetera. These would be organized into a menu on the device, like "Files", "Pictures", "Voice Recorder", "Phone", etcetera, so devices that do some or all of these would simply show a choice (tabs, maybe) for what feature to use.
Any ideas?
Re:BlueTooth is just crappy. (Score:2, Informative)
Re:BlueTooth is just crappy. (Score:2)
Re:BlueTooth is just crappy. (Score:5, Informative)
Apparently the whole idea of bluetooth profiles is lost on you? This is exactly what their for. Devices support different profiles, such as, the virtual serial port profile, audio gateway, headset, file transfer, network access, PIM item transfer, etc. Descovering what a device does is as easy as asking it what profiles it supports.
What it needs is a set of protocols, preferably XML-based, since XML is 31337, that can transfer files, send/receive photos, take pictures, record audio, dial/talk on phone calls, etcetera. These would be organized into a menu on the device, like "Files", "Pictures", "Voice Recorder", "Phone", etcetera, so devices that do some or all of these would simply show a choice (tabs, maybe) for what feature to use.
Bluetooth *already does this*, just replace XML with OBEX and it does everything you just said. It makes me wonder where you got your experience, if any, with using bluetooth devices.
-- iCEBaLM
Windows required? (Score:2)
You might have better luck using Apple's Bluetooth SDK [apple.com] which has been standardized and shipped with the OS since Jaguar.
If it's a special-purpose app, you'll have a better outcome in the long-run by picking a stable API.
All /. agrees , it's dead... (Score:1)
Re:Good one (Score:5, Insightful)
<sarcasm>
...which is why the market is now overflowing with WiFi-enabled mobile phones, WiFi headsets, WiFi-enabled GPS receivers etc. etc.
</sarcasm>
Bluetooth and WiFi are complementary technologies. Bluetooth headsets make perfect sense whereas a WiFi headset would have its battery life measured in minutes. Likewise, using Bluetooth for wireless networking is something you do only when you have no other alternative.
I usually carry the following devices with me:
Re:Good one (Score:2)
Re:Good one (Score:2)
The problem as I understand it is that the WiFi protocol requires much more contineous transmission, i.e. the transmitter must be turned on for much longer periods. This means bigger current-drain and hence lower time of usage for a given output power/battery size combination.
However, I'm no expert either so I may be wrong.
Re:Good one (Score:2, Interesting)
A cell phone transmits up to a distance of a two to three kilometers, maybe more depending on technology, vendor etc.
A Wifi transmitter transmits up to a hundred meters or so.
A bluetooth transmitter transmits up to a distance of 10 meters.
But they're all still RF transmitters.
Which one do _you_ want to fry your brain with? (do you want to take part in the 1-in-9-have-cancer statistic?) Cuz ignore it or not, them brain cells do get fried and _die_.
Re:Good one (Score:2)
Tell me, do these alleged studies compare the different cancer rates for 900MHz, 1800MHz and 1900MHz cell phones? Analog or digital transmission? PCM, CDMA or TDMA? Maximu
Re:Good one (Score:1)
I never said any of those cellphonescausecancer.com or oprah things. Don't put words in my mouth. Thatcher once said she really likes having conversations go down to personal lines and name-calling. It means that the attacker is flat out of arguements. Consider revising the way you conduct a conversation.
I worked on radars, and there is one thing I know quite well - RF heats shit up. The stronger the transmission, the more heat. Strong RF very near tissue most def
Re:Good one (Score:1)
And then, you are mixing up a few things. Heat doesn't cause cancer (k, heat does increase mutation - stop wearing clothes to stop that).
Today, we can tell if certain kinds and intensities of radiation are increasing the risk of cancer: it's if they can ionize. And cell phone radiation does not ionize. So, unless ther
Re:Good one (Score:2)
Re:Good one (Score:1)
Besides, I think this entire offspri
Re:Good one (Score:1)
Do you want a phone and headset combination that only works with an 11b access point around to arbitrate things?
Or a laptop that can't talk to the phone because it's set to the SSID of the LAN instead of the phone's own private LAN?
Exactly *how* are you supposed to configure your headset so it only works with your phone, and not your cubical neigbours? And vice versa - you don't really want your neighbours headset picking up your call.
Yes, you'd need a st
Longtooth (Score:2)
OS X has some great tools (Score:1)
OBEXSample
OBEXSampleSendVCard
RFCOMMClientSa m ple
RFCOMMServerSample
In
BluetoothMonitor
PacketDecoder2
I never looked at these before, so I checked them out. BluetoothMonitor seems to watche Bluetooth traffic (snort without the data). PacketDecoder2 seems to let you snoop on
It will only get worse. (Score:1)
Bluetooth was laid off a long time ago but due to a glitch it was never informed. We fixed the glitch... It will just work itself out.
Why Bluetooth isn't doing well (Score:1)
Why does the average consumer want a wireless keyboard? The wired one is more reliable, cheaper, and means that no batteries and recharging are necessary. *He* (unlike the typical Slashdotter) doesn't constantly plug and unplug cables.
Re:Why Bluetooth isn't doing well (Score:2)
People do appreciate clutter reduction; this is why non-techs like LCD monitors, wireless keyboards and mi
Charging Bluetooth Devices (Score:2)
Device connectivity, mobile connectivity, human co (Score:1)
Will this make cellphone towers and monthly rates obsolete? How about IP Cellphony. I am quite sure everybody has pondered about this very thought. It would mean a truly global interconnected network where mobile wireless networks can provide anytime anywhere networks. So what's the downside? One word, bandwidth. WiFi currently requires the 802.11b standard which runs 11mbps. 802.11
Re:Device connectivity, mobile connectivity, human (Score:2)
It's currently about the same price as a regular Cisco VoIP phone is, but it can move away from the desk (i.e. anywhere in the company, not just in the cube.)
Widcomm... (Score:2, Informative)
Yes, it has lots of problems, and you have to correspond API==SDK (that is, if you develop w 1.4 SDK it can only run in the 1.4 Stack). But it's fairly easy to program, an it has all that metters (RFCOMM and L2CAP)
I guess compatibility is good (never had any problems)
I've never used the WIndows XP one, but I reckon it's more difficult to use.
Java and Bluetooth work well together (Score:2, Informative)
1. It has a list of hardware to get you started in Java Bluetooth development
2. A list of Java Bluetooth SDKs
3. Information on my book, "Bluetooth for Java"
4. A sample chapter from my book
5. All the source code from my book
The folks on Amazon [amazon.com] like my book, so you might want to check it out. You don't have to buy the book, but the early chapters explain all the complexities of Bluetooth, and
Bluetooth Dev kit (Score:2, Informative)
Warning: actual programming experience here (Score:2, Insightful)
So what's my advice? Have a backup plan. Isolate your network communication procedures so you can easily switch to a new protocol/stack when one comes along. My code has been re-used, ported over to
Hear me now.... (Score:2)
Re:Hear me now.... (Score:1)
No, it isn't. But it does have its own protocol stack.
>> They also still want to use non-standard connectors to you have to buy from them and noone else.
Yep, and to compensate for their inability to make overpriced proprietary plugs, they made a hugely diverce protocol stack that is waaay too redundant.
Here's an example:
There are no less than three profiles (aka protocols) to transfer audio - one for a handsfree set (HFP), another for headset(
Re:Hear me now.... (Score:1)