Bluetooth Everywhere

Ok,

So, unless you’ve lost internet access for the last 6 months (wow, that’s a scary thought) you’ve probably heard that Apple is going to release a tablet computer this year. Now, I don’t plan to spend alot of time on contributing to Apple’s free-PR-scheme, but I do have to say something about it, because of all the hype.

So, I understand the purpose of the iPhone - it’s a big ‘ole iPod screen, with good web browsing, and downloadable apps. Yeah, it what the Apple Newton should have been. There are billions of mobile phones on the planet, so making the iPhone suited a need that already existed.

My concern however is that…

…I don’t need a tablet…

I use computers ALOT, and every computing scenario for me is already covered by:

• servers
• desktops
• laptops
• mobile phones

Watch-based computers never really took off because nobody really needed them. So, whenever Apple presents its new tablet this year, I want to see Steve Jobs convince me that I need a tablet, because right now, I don’t.

Bluetooth 2.1 technology allows two devices near each other to communicate at a maximum speed of 3 Mb per second. In the grand scheme of wireless communication, Bluetooth is roughly two times faster than the data throughput of a 3G wireless phone but still 10 to 20 times slower than today’s Wi-Fi speeds.

More than one billion Bluetooth-enabled devices are currently on the market, and Bluetooth does a good job of transferring files that are smaller than 10 MB in size. However, due to the inherent nature of most wireless communication protocols, Bluetooth devices need to discover other Bluetooth devices, even if both devices are right next to each other. Finding a remote Bluetooth device is great, but what services does that remote Bluetooth device offer? If the remote device is a printer, does it offer the commonly used Basic Printing Profile (BPP) or the more advanced printing service known as the Hard Copy Cable Replacement Profile (HCRP)?

To find the available services on a remote Bluetooth device, you also need to search for a service. Bluetooth device-discovery and service-searching capabilities are great when you are trying to find any remote Bluetooth device in the vicinity that can suit your needs.

But device discovery and service searching are extremely time-consuming and frustrating to use when you’re trying to communicate with a device that’s right in front of you. This article shows you how to get Bluetooth applications to completely bypass the device-discovery and service-searching processes simply by using Near-Field Communication (NFC) technology and JSR 257: Contactless Communication API.

You can also find this article in the list of all articles on this site.

Alright, let’s continue to learn about the various intricacies of the Bluetooth specification by looking at another of one of the more common Bluetooth profiles: DUN.

Profile Name: Dial-up Networking Profile

Abbreviation: DUN

UUID:  0×1103

Description: The Dial-up Networking Profile (DUN) is a profile that largely depends on the functionality of the Serial Port Profile (SPP) in order to operate, as you can see from the image above. This profile is modeled after the connection mechanism that was widely used in the 1990’s for home computers to get access to the internet: the dial-up modem. Please note that even though dial-up modems are not available today, this profile is still widely used by laptops and other mobile devices to access the internet through a Bluetooth-enabled mobile phone.

Common Implementations: laptop computers, desktop computers, mobile phones

Ok, so the Sun SPOT is a really cool device. I thought that I’ve blogged about it before, but no, apparently I haven’t. So anyway, it’s a really cool mobile device platform that allows Java ME developers to create applications that run on embedded systems.

This device has an accelerometer, temperature sensor, a bunch of other cool stuff like a 802.15.4 radio. However, it doesn’t have Bluetooth (and that’s a shame). However, Dave Simmons wrote a nice blog posting on how to get your hands dirty and *MAKE* it Bluetooth-enabled. Be warned, however, that if you don’t feel comfortable with a soldering iron, then stay away.     :-)

Well,

Thanks to everyone who took the time to read my two-part series on how to use a Bluetooth-enabled GPS receiver. Since that time, alot of you tried the examples with the MPowerplayer, and you found out that they changed how it handles JSR-82 API implementations. So, I wrote a quick follow-up article that answers all of your questions that were posted on the java.sun.com site. As always, you can find a link to all Java Bluetooth articles on the main site.

Well, if you’ve heard any of the news, press releases, or blog postings about Bluetooth 3.0, then you should be as excited as I am about this stuff. It’s nicknamed Bluetooth 10x for a reason; we’re talking about sending your data at 24 Mb/s! However, some folks are a little confused about how all this stuff works, so please allow me to explain a few concepts.

First of all, let’s take a look at some wireless standards (you’re probably familiar with the first one):

• 802.11
• 802.15.1
• 802.15.4

So, in the past decade, the IEEE standards body came together, designed, and formed all of the wireless standards listed above. Now, Wi-Fi is a brand name of *an* implementation of 802.11 wireless standard. Wi-Fi is such a common brand name, it is synonymous as the only implementation of the 802.11 standard. But that’s not the case.

The same things goes for Bluetooth. Bluetooth is an implementation of the 802.15.1 wireless standard, but it is not necessarily the only implementation. Likewise, this pattern applies to ZigBee. The SunSpot wireless devices natively communicate over the 802.15.4 wireless protocol, but they do NOT implement the ZigBee protocol stack.

So here’s what you can expect in the new Bluetooth 3.0 devices that will be coming next year. Bluetooth 3.0 devices will be able to discover and search for services for remote Bluetooth 3.0, 2.1, 2.0, 1.1, and 1.0 devices. However, if both devices support Bluetooth 3.0, then when the data payload is being sent, the data will be sent over the 802.11 “channel” and not the 802.15.1 “channel”.

I hope this makes sense.

Now, if you’ve never written an application that uses the Bluetooth protocol with OBEX before, then (in my opinion) the effort can be a little daunting. Of course, The Bluetooth specification gives you plenty of options on how to send data, but the best way to send files between two devices is truly the OBEX protocol in the Bluetooth specification. Below are links to two articles that I wrote for IBM a few years ago, and the code provides some great examples for developers. Additionally, if you’re looking for help in developing a desktop application that uses Bluetooth and OBEX, then the example code in these two articles will be invaluable to you since all the examples were written using the JSR-82 API on the Java SE JVM.

The first article is entitled, “File transfer with JSR-82 and OBEX“, and shows you how to create an OBEX server using Java code. The second article is entitled, Creating the Bluetooth Music Store, and it shows you how to create an OBEX client application. At the end of second article, there’s another example application presented (which extends the basic OBEX client application) which is called the Bluetooth Music Store.

The articles got high ratings by the readers on the IBM site, so I figured that you would find them of interest. Of course, you can find links to all the mobile computing articles in the “articles section” on main JavaBluetooth.com site.

Just in case you didn’t notice, the Bluetooth specification is a huge spec. It’s over 1000 pages and covers alot of topics including advanced frequency hopping, low power states, communication parameters, and a whole bunch of other stuff. So, as I work on “Bluetooth for Java, 2ed”, I thought that it would be a good idea to create a tutorial on what all the profiles are, and what do they do. So let’s get started!

Profile Name: Serial Port Profile

Abbreviation: SPP

UUID: 0×1101

Description: The Serial Port Profile (SPP) is a profile that interacts directly with the RFCOMM layer in the Bluetooth protocol stack, and it’s one of the most commonly used profiles since the inception of Bluetooth. If you have an electronic device has has a serial port, or is capable of processing raw byte streams, then SPP would be a good choice if you wanted to wirelessly-enable that device. On a Bluetooth-enabled computer, this profile is used to create a virtual serial port, so that applications on the PC can communicate to wireless Bluetooth devices as if they were directly connected over an actual serial port. From an application developer’s perspective, using the SPP is very easy to do since there’s no protocol overhead that you have to follow - just send and receive byte streams.

Common Implementations: RS232 to Bluetooth converters, Bluetooth GPS devices, mobile phones, desktop computers

I have great news for those of you who are waiting for the next edition of “Bluetooth for Java”. Chapter 1 is done and complete. The funny this is that I completely gutted the whole chapter! It’s amazing how things change in a matter of a few years. Back in 2002 when I wrote the 1st edition of the book, I needed to write Chapter 1 to explain “what” Bluetooth is and “what” Bluetooth does.

Now, it’s 2009 and there over 1-billion Bluetooth-enabled devices on the planet. There is absolutely no need to try to introduce you to Bluetooth, since almost everyone has a general concept of what it is. So, I’m going to salvage what little I can from Chapter 1, and roll that information into Chapter 2. Now it’s time to tackle Chapter 2!

Ok, let me quote the Bluetooth SIG directly:

The Bluetooth SIG is pleased to announce that the Core Specification Working Group has published the Draft Bluetooth Core Specification Version 3.0 + High Speed (HS) for your review. The following feature enhancements encompass the major improvements incorporated into this Draft Bluetooth Core Specification:

• Generic Alternate MAC/PHY (AMP)
• 802.11 Protocol Adaptation Layer (PAL)
• Generic Test Methodology
• Enhanced Power Control
• HCI Read Encryption Key Size
• Unicast Connectionless Data

This of course is awesome news! Now if all those features look like “mumbo-jumbo” to you, then stay tuned to this blog because I’ll explain why these features are important. You can expect the new specification to be finalized before July. When will Bluetooth 3.0 +HS devices hit the market? My guess is that you’ll see some devices that use the new spec by the end of year.

I’m the type of person who gets enthusiastic about people or companies who decide to be a leader, and not a follower. Some of these companies have an engineer in their corporate offices who makes far-reaching business decisions based upon technical-prowess (that means that they do something because it’s really cool to do) and because of financial sound-ness (that means that they can make some money from it, too). One of these companies in my opinion is Broadcom. Last month, at the 2009 CES show, Broadcom conducted a technology demonstration of the next-generation Bluetooth technology (2.2/3.0 - we don’t know the version number yet). They were able to achieve data rates up to 24 Mb/s, and they achieved this by running Bluetooth data over a WiFi transport! This capability is a part of the Bluetooth AMP technology. So, for 2009 here’s what you can expect the Bluetooth landscape to look like:

• Bluetooth Low Energy 1.0
  • data rate - 1 Mb/s
  • battery life - 1 year
• Bluetooth 2.1 +EDR
  • data rate - 3 Mb/s
  • battery life - days
• Bluetooth 2.2/3.0 (Bluetooth High Speed Technology)
  • Two flavors available:
    • 802.11 / Wifi transport (called 10x technology)
      • data rate - 24 Mb/s
      •  battery life - hours
    • Ultra Wide Band (UWB) transport (called 100x technology)
      • data rate - 200-400 Mb/s
      • battery life - ?

The newest versions of the specifications should be completed in mid-2009. So are you excited?

Boy, it really feels good to be right. So, if you can recall from last week, I told you all that I was going to the M3DD conference. This conference not only met my expectations, but has completely exceeded them! This is definitely a conference that I need to go to every year! Below is a picture of one of the presenters in action at the conference:

So, as you may also recall from last week, it was announced that there was a mystery give-away device that would be awarded at the conference. The *only* clue that they provided was that it was a phone. I not only guessed the manufacturer of the phone, Sony Ericsson, but I also guessed the exact model of the phone, the C905! Isn’t that cool? Now, of course, I’m not an employee of Sun Microsystems, and I had as much information as everyone else did prior to the conference. So how could I have known that the mystery device was exactly going to be a Sony Ericsson C905? Do I have a crystal ball? Can I guess lottery numbers, too?

No.

But here’s the clues that I pieced together. First of all, the number #1 sponsor of the event was Sony Ericsson, so they should have obviously have come up with the give-away device. Secondly, Sony Ericsson is pushing their new Java ME/Flash Lite integration technology, Capuchin, so it would make sense to give away the first phone in the world that would support Capuchin technology, the C905. And if I’m correct, you’ll also see these phones at JavaOne because Capuchin technology is a direct competitor to Java FX Mobile, so Sony Ericsson will probably want to get these devices into the hands of developers ASAP before Java FX Mobile is takes root.

So, as I said before, I was right!

So, as you already know, alot of the mobile and embedded developers will be at the M3DD conference this week in San Jose, CA. Well, it was announced on the Java Mobility podcast that there will be a special device give-away at the conference. Any guesses on who the provider is and what that device will be? So, let’s see how good my intuition is…

#1. I think that the provider of the give-away will be Sony Ericsson, and
#2. I think that the device will be the C905 phone with Capuchin technology

Stay tuned next week (or come to the conference) to see if I was right!  :-)

Ok don’t laugh, but I kinda did something stupid. I got excited about the new simple pairing feature in Bluetooth 2.1 +EDR, so I rushed out and got one of the first Bluetooth dongles that supported the new spec. I couldn’t wait to receive it. After I opened the package, I realized something. I just got the equivalent of (1) walkie-talkie. The main reason why I got the new dongle was to test out the new simple pairing feature, which would mean that I would (of course) need another Bluetooth device that supported the 2.1 spec.

So, I’ve been on a quest to find a really cool device that supports the 2.1 +EDR spec. So, have you guessed it yet? What’s going to be the first mobile device in 2009 to support Bluetooth 2.1? Is it…

• Apple iPhone? No.
• Blackberry Storm? No.
•  Nokia N97? No.
• Sony Ericsson C905? No.

Its the Palm Pre:

Now before I sing the praises of this device, can I remind us all of a little history? Over 13 years ago, the cellphone market was not the growth sector as it is today, and the mobile and handheld market was really all about PDAs. Toshiba and Sharp introduced one of the first official PDAs in the market, and then Apple stole the show with their PDA, the Apple Newton. All the PDAs on the market had similar capabilities (notetaking, appointment book, calculator, etc) but Apple’s claim-to-fame was the fact that it the best handwriting recognition available. The Netwton became an instant success and completely dominated the market. Unfortunately, Apple didn’t listen to the developer community who wanted better access to the APIs of the system. Apple also ignored the consumers who wanted a smaller form factor and nearly flawless character recognition. So what happened?

A newcomer arose out of nowhere in the PDA market named Palm (at that time it was US Robitics) and introduced a PDA that could comfortably fit in your pocket and could recognize characters 2x faster and more efficient than the big-bad-Newton. Palm also introduced a better synchronization technology that synchronized your desktop and PDA 10-20x faster than anybody else, including Apple. Developers flocked to the Palm platform because it was more open compared to the Newton APIs (even though Palm had the uphill battle of being the new-guy-with-the-new-API).  In a matter of years, Palm became the #1 PDA, and Apple could never catch up because they refused to change.

So what’s the point of all this mobile computing history? I said all this because I think we’re about to see it happen all over again. I like Apple’s products, but as a developer, it can be very frustrating to work with them, especially for the iPhone. The Bluetooth APIs are very restrictive (boo!) and why can’t we do any tethering, Bluetooth or otherwise?. Did you know that you have to own an Apple computer to write code for the iPhone? Consumers want tactile feedback in order to type quickly, but Apple will *never* make a keyboard for the iPhone because they’re too arrogant about their design. Is it too much to ask to get a user replaceable battery?

Now of course, every new smart phone on the market will have the standard touch screen, accelerometer sensor, large display, and GPS chip. The Palm Pre adds the following features, that set it apart from the other contenders:

• Bluetooth 2.1 +EDR (now I have a device to do simple-paring with!)
• Bluetooth tethering (very nice - I have no idea why Apple and RIM refuse to support it)
• A real keyboard (so people can type faster)
• A user replaceable battery
• Wireless power charging!

So, needless to say, I’m excited about this device. I’m anticipating information on the Bluetooth API support (of course).

Ok,

I’ve been to the JavaOne conference before, and I can say that it’s an awesome experience.  Now, of course, at JavaOne there’s so much going on, that’s easy to get lost in the myriad of speakers, topics, and exhibitors. So, since Sun is running the M3DD (Mobile, Media & Embedded Developer Days) conference, then I have my hopes up that it will be as fun and exciting as JavaOne.

Here’ a list of technologies that I want to get smarter on:

• Java FX mobile
• Tru2way
• MIDP 3 (of course!)
• BUG Platform
• Java ME and OSGi
• Java ME widgets
• Java Card 3
• Squawk
• Capuchin

So this should be an exciting conference next month. Hope to see you there!