11-10-2008 05:42 PM
I have written a midlet to communicate with a custom device that speaks Bluetooth (using JSR 82, not the BlackBerry Bluetooth API) using the Serial Port Profile. The midlet works correctly on other non-RIM handsets. When I run it on my BlackBerry 8820 it successfully opens a connection, input and output streams. Then it attempts a conversation with the device.
The device uses AT commands (non-standard ones we invented) to communicate with the midlet. My program first sends a "tell me your configuration" AT command, and tries to read a response. The device is supposed to respond with "AT+CFR=xxx", and I'm confident it is - like I said, this program works on other devices.
My program then tries to read this response from the input stream - and blocks waiting for it. When I run the midlet with the debugger attached, I see a very interesting item in the log in between two adjacent debug messages of my own. It says
sending get config command (my debug message)
Unknown AT data: CFR=xxx
sent get config command, waiting for reply (my debug message)
That "Unknown AT data: CFR=xxx" message seems to be coming from the BlackBerry's Bluetooth stack. My program never receives that "CFR=xxx" data. It appears as though the Bluetooth stack examines the data coming from my device, recognizes it as an AT command, and then, failing in to make sense of it, drops it on the floor.
I'd like to turn off this behavior, so that the BlackBerry Bluetooth API simply passes through the raw data coming from my device. Is there a Bluetooth property I can set to do this, or some other way to effect it?
11-13-2008 03:09 PM
11-13-2008 04:29 PM
Those error messages should only be generated if the Bluetooth peripheral in question is implementing the Headset or Handsfree Profile.
11-13-2008 05:01 PM
Thanks for your quick reply. Yes, the Bluetooth peripheral in question does implement those profiles. However, my program is opening its connection to an additional non-audio service based upon the Serial Port Profile. It sounds like the BlackBerry software should test whether the service, not the peripheral itself, requires this special treatment. (The other handsets we're using this with work that way.)
Issues of what is correct behavior aside, I'd like to find a workaround. Given the current BlackBerry software, can my peripheral safely pass non-AT data without the handset interpreting or interfering with it? That is, do only strings that look like AT commands get this treatment? Finally, can I programmatically disable this behavior for a given service of a Bluetooth peripheral? (One can always hope.)
11-20-2008 01:25 PM
You could try using the RIM API (net.rim.device.api.bluetooth.*) to connect to the device, rather than JSR 82. I only suggest this because I've managed to communicate with a device that sends AT commands using the RIM interface. I've not tried using JSR 82. So using RIM might be a work around. Just a thought.
11-20-2008 01:45 PM
Thanks, I might try that. Per Brian Zubert's note above, however, the problem seems to be that the BlackBerry's Bluetooth stack, upon observing that my device implements the Hands-Free and Headset profiles, interferes with communication over an unrelated SPP channel. It's not clear that using a different API will let me avoid that, unless that API contains a call to tell the BlackBerry not to behave this way.
Subsequent to posting my first note I changed the device's firmware to omit the "AT" portion of the data it's sending to the BlackBerry, and the data still seems to get dropped on the floor - only now without the helpful "Unknown AT data: CFR=xxx" message that originally tipped me off to the source of the problem.
12-01-2008 12:49 PM
12-01-2008 01:56 PM
My program is definitely connecting to the right port; the log message stating that there's "Unknown AT data: CFR=xxx" includes a string, CFR=xxx, that our device emits. (That is, our device sends "AT+CFR=xxx" to the handset application.) It's not a command that's part of the headset profile, so there's no possible confusion between serial and headset ports.
I should mention that when my program runs, the BlackBerry is also, separately, connected to this hardware as a headset, but that's all set up through the BlackBerry Bluetooth Options in the usual way, externally to my program. Perhaps this is confusing the lower-level Bluetooth drivers. Unfortunately, our tests require that.
I look forward to your advice.