Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming IT Technology

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?
This discussion has been archived. No new comments can be posted.

Bluetooth Application Programming?

Comments Filter:
  • by MooseGuy529 ( 578473 ) <i58ht6b02@[ ]akemail.com ['sne' in gap]> on Wednesday October 29, 2003 @06:32PM (#7342052) Homepage Journal

    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?

    • this is what obex does. obex works over bluetooth, irda, http etc.
    • nono ... why build a special protocol? just make it auto-establish a tcp link with a private ip, and offer services the way you normally would, by attaching services to port numbers ... and use all the normal tools and existing protocols. and no xml. you want to use the bandwidth, not flood it with metadata. sheesh. poor little phone ...
    • by iCEBaLM ( 34905 ) on Wednesday October 29, 2003 @08:01PM (#7342692)
      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.

      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
  • Is it necessary to use Windows for your app, or is it just what's on hand? Is this mass-market or special-purpose?

    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.
  • The stories of Bluetooth's feasibility are long over. Basically, standardization was knocked around for so long, WiFi maes and engulfed it. Market factors like the lack of US demand for linked devices from multiple vendors also spelled the end, much like a www.pizzain30minutesorless.com idea. No lack of shame, since it was the best idea at the time, but the increase in wireless bandwidth just isn't coming up to push XML fast enough for more than trivial apps. But that's only what I've heard, since I neve
  • Bluetooth is dead? Then how am I going to get all these pictures out of my phone? IR? Jeez. Get your hands on a Mac and install the Developer tools. In /Developer/Examples/Bluetooth you'll find:

    OBEXSample
    OBEXSampleSendVCard
    RFCOMMClientSa m ple
    RFCOMMServerSample

    In /Developer/Utilities/Bluetooth you'll find:

    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
  • Not too long and you won't even be able to find a bluetooth mouse.

    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.
  • Bluetooth isn't doing well because there just plain isn't a market for it.

    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.
    • I can think of two reasons for a wireless keyboard:
      1. Cleaning around the computer. No wires makes this so much easier, since you can just move the keyboard out of the way when you're dusting. Basically, less clutter, so easier to deal with.
      2. Sharing a computer. If you're working with someone on something, it's easier to pass a wireless keyboard back and forth than pass a wired keyboard about the place.

      People do appreciate clutter reduction; this is why non-techs like LCD monitors, wireless keyboards and mi

    • Sorta OT, but why don't they make mouspads and wrist pads that recharge Bluetooth mice and keyboards via induction while they're in their correct places? That would give you the juice to sit back with the keyboard in your lap as long as you put it back on the desk when you went to lunch.
  • So where to from here. If bluetooth is dead and WiFi is taking over then why are there no mobile WiFi devices like cellphones?

    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
    • Cisco makes a WiFi IP phone...but, it does have to be within range of a WiFi network, and somewhere on that network, has to be stuff to make VoIP work.

      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)

    by JamesP ( 688957 )
    Try the Widcomm API.

    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.

  • by Anonymous Coward
    Take a look at my site www.javabluetooth.com [javabluetooth.com], it has almost everything that you're looking for. For instance:

    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)

    by mannionh ( 669223 )
    A company called Rococo [rococosoft.com] have a development kit which hides the complexity of bluetooth behind an API, they also have a simulation envirnoment so you can test your apps before deploying them on the target devices. As far as I know theres a free download for linux.
  • I worked on an application for about 4 months, using Bluetooth communication for communication between two Windows PCs (as proof of concept for future devices). The experience was less than stellar. The SDK I used was discontinued while I was coding, but too late to switch to a new one (before funding ran out).

    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
  • Bluetooth IS NOT A WIRELESS TCP/IP Alternative! It's a CABLE replacement technology. That is all. Besides other issues with Bluetooth, I am convinced that companies aren't using it because tehy still want to charge you 50 bucks for about 10 bucks worth of cable. They also still want to use non-standard connectors to you have to buy from them and noone else. BT is just starting to take off now. How many times did someone try to kill USB with Firwire? BT complements WiFi. When WiFi is available, you u
    • >> Bluetooth IS NOT A WIRELESS TCP/IP Alternative!

      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(
      • From having worked with BT, the SDP and device inquiry protocol for BT is really nice. Once you've connected, it can be just another socket, which is how I am using it right now it my program. I personally think it has a lot of potentials. It's very different from WiFi in application because WiFi generally require an AP and BT is really meant for Ad Hoc usuage. I think if they can get the software up to a reasonable stanard, BT should do pretty well.

Thus spake the master programmer: "After three days without programming, life becomes meaningless." -- Geoffrey James, "The Tao of Programming"

Working...