Bluetooth info and cell-phone:

GetJar: My LATEST find of a cellphone website - seems to have EVERYTHING, from 'devices' to 'forums'! To illustrate the depth-of-knowledge of this website, consider the information conveyed in a page showing not not only whether a certain cellphone contains the (micro-edition) of the Java-runtime, but additionally, which VERSION of it.




Verizon Wireless section (since they are my family's cellphone-choice)

Most of my experience with Verizon's phones has been with LG's phones. My current one is LG's VX-8300, which has bluetooth capability! [Bluetooth was a recent 'study'...I spent some time learning how to program various bluetooth-related areas, in an effort to better understand this interesting technology.]

Inside my phone, there's a 'Software Version' sub-menu item, which shows all sorts of lower-level functionality and the related VERSION-NUMBER of each sub-system. It appears like:


SW Version: [This seems to be their overall 'OS'...that Verizon engineers themselves ?!?!]
T83VZV01
PRL Version [I THINK this relates to their 'Preferred Roaming List' !?!?]
PRL 51284
ERI Version [I THINK this relates to their 'Enhanced Roaming Indicator' !?!?]
ERI 4
[there's more stuff in this list too...TBD.]

Here's a tip: If your cellphone supports 'bluetooth', then you do NOT need a data-cable, to transfer stuff to/from your cellphone and your PC. Instead, just buy a low-cost (about $14 from NewEgg) bluetooth-USB-adapter for your PC, and locate some transfer software compatible with your phone, and you should be able move ring-tones and address-book and pictures and tunes between them. [The 'Bitpim' app works for my Verizon-based CDMA phones (LG-models), so should work for Sprint-based, too. But, I heard rumors that certain phone-manufacturers (e.g. Razor and other phones) may be purposely 'blocked' so that such private transfers will NOT work. So, 'your mileage may vary'.]

If your cellphone isn't CDMA (i.e. if your cell won't work with Bitpim), then there are (probably) other free full-function transfer/sync programs out there. But, as a fallback (if you can't find one), there is an 'ftp' mechanism between a PC and a cellphone (using either bluetooth or a data-cable) that utilizes 'OBEX' (OBject EXchange). Most phones will have their end of OBEX already in them, so all you'd need to do is acquire (or compile/build from source) the PC-side of the ftp/OBEX software. It's all explained here:


Other US cellphone carriers



Let's say you want to write some code to utilize your Bluetooth-adapter.

Bluetooth Profiles/Services (known to the Linux 'sdptool'):
DUN = 1103; (Dial Up Networking)
DID
OPUSH = 1105; (Object Push / Obex Push)
SP = 1101; (Serial Port)
A2SRC A2SNK
AVRCT = 110e; AVRTG
HF = 111e; HFAG
HS = 1108; HSAG
FTP NFTP
FAX PRINT
HCRP HID
"SEMC HLA"
LAN
PANU
NAP
GN
KEYB
CIP CTP
UDIUE UDITE
SR1
APPLE
WIIMOTE
PALMOS
NSYNCML SYNCML SYNCMLSERV ACTIVESYNC HOTSYNC ISYNC

BT_DUN_CHAN=8
BT_PHONE=00:12:56:8F:45:F0
BT_SERIAL_CHAN=16
BT_ADAPT_CIRAGO=00:1B:DC:00:43:DA
BT_ADAPT_ENCORE=00:11:F6:09:E6:BA
BT_ADAPT_TRENDNET=00:18:E7:36:87:05
alias bt-browse='sdptool browse $BT_PHONE'
alias bt-dun-bind='sudo rfcomm bind /dev/rfcomm0 $BT_PHONE $BT_DUN_CHAN'
alias bt-test-connect='rfcomm connect 1 $BT_PHONE $BT_SERIAL_CHAN'

Argh...there's a whole BUNCH of 'bluetooth stack' vendors and issues:

Ok, let's further stipulate that you want to use 'Java APIs', since that would be MY preference. (Hmmm...I thought it would be straight-forward, but it turns out there's not only that myriad of various stacks, but also various APPROACHES to implementing the java package named 'javax.bluetooth'. Most shoe-horned it UNDER the 'JavaME' platform, which was fine for 'mobile-device' platform side. But, if you happened to want to talk from the other side (i.e. the PC-side, aka the JavaSE platform side) well...oops! [I fault Sun for dropping the ball, but in reality, I don't know how it happened.]

Luckily, someone/something called 'BlueCove' finally did something about the problem. So, to solve it, just grab BlueCove's jar (bluecove-2.1.0.jar was 'recent' when I started), and THEN you should be able to compile java code that is NOT DEPENDENT on JavaME. Besides the BlueCove APIs, which I'm using on Windows-Vista, there are at least two other JavaSE-based ones: Avetana and ElectricBlue. (That said: Using these Java-APIs for bluetooth on Linux (the samel Bluecove jar(s)): It behaves slightly differently, when I use it there. I initially developed Java-based bluetooth code on Window-Vista and it works fine there. When I move it to Linux, it compiles fome there, but when I execute it, the remote-device detection reports that no remote devices are paired even tho they are. But everything else works there, including doing the pairing, and service discovery of my cellphone's services works fine, and uniformly on all three bluetooth-adapters. So, barring that one API anomoly/difference, everything else on Linux seems fine.)

The 'sdptool' alone is reason enough to prefer doing the bluetooth stuff on Linux, as it's much better than any other service-discovery-tool I've found on Windows. [Linux's sdptool should be compilable/buildable on Windows, but I haven't found it pre-built for Windows on the Internet, and I couldn't quite get it to build using minGW]

Here are links to the stacks, tools, Java-APIs, and some related forum threads:




Ok, I could throwout my collection of bluetooth-adapters (usb-based), because now Trish's and my Lenovo laptops now have BUILTIN bluetooth chips. But, back around 2007-2009, I VARIOUS vendor's bluetooth-usb-adapters on my PC. I had HOPED that there would be just ONE, COMMON device-driver for them all [similar to what seems to be the case for flash-drives], but alot of my reading about bluetooth seemed to indicate that would NOT be true. (SIGH. It's not true) So, I still see a glitch or two (bugs!) in the various 'drivers' for my collection of bluetooth adapters. Much worse, if you do install the 'driver-CDROM' stuff from one bluetooth-adapter, it can (and probably will) actually prevent that adapter from working, as it collides in some way with one of the other BT-driver sofware, because it never occurred to them to try to serially use BT-adapters from various vendors on the same Windows-Vista-based PC. My collection of BT-adapters includes both Class I (100 meter) and Class-II (10 meter) range of devices, but I have NOT (yet) tested their actual achievable ranges. (That would be an interesting test and I plan to do that sometime.) Here's the list of my current collection of BT-adapters: