Bluetooth carbon mysteries resolved
Bluetooth carbon mysteries resolved
- Subject: Bluetooth carbon mysteries resolved
- From: "Daniel Birns" <email@hidden>
- Date: Sun, 8 Apr 2007 17:12:17 -0700
Bluetoothers,
I've corresponded about several problems I had with Bluetooth/carbon, and these are now largely resolved, so I thought I'd share these resolutions with this community.
Our application does the following: Creates a discoverable service, does device inquiry to find other devices with that service, accepts inbound and creates outbound connections.
1) mtu: The mtu that I get communicating with my PC (which has the broadcom/widcomm bt stack) is 126. This appears likely to be due to the PC. When I communicate with another mac, I get 666, and the transmissions are about 5-6 X faster.
2) service plist. There appear to be a number of secrets about the mapping between the service plist and the actual service record that bluetooth expects according to the bluetooth specification. Apparently a one-byte unsigned value must be specified with
<dict>
<key>DataElementSize</key>
<integer>1</integer>
<key>DataElementType</key>
<integer>1</integer>
<key>DataElementValue</key>
<integer>3</integer>
</dict>
(in this example the value is 3). The fact that a 1 in the type field indicated unsigned int is not clear, although that happens to be the value in the BT spec. Unfortunately, the size field in the BT spec would be 0, which
means 1 byte. So it's both similar and unsimilar to the spec. The way I proceeded was to use the plist in the RFCOMMService example, and modified it until it met our spec. And I used the Bluetooth Explorer to verify my results.
3) Carbon -- carbon does work for the level we needed, which is pretty low-level. We aren't using any existing services, but instead are using BT as a TCP/IP replacement. Some of the callbacks aren't exactly clear. For example, I use IOBluetoothRegisterForFilteredRFCOMMChannelOpenNotifications to find out when someone connects to my service. The callback has a argument that is of type IOBluetoothObjectRef -- not very enlightening. Fortunately, it's actually a IOBluetoothRFCOMMChannelRef (or at least it works as one).
There's a lot of examples like this where it wasn't really clear what to do. Fortunately, obvious guesses seemed to be true in most cases.
4) Messages about deprecated calls. It turns out you have to put this in your source code:
#define BLUETOOTH_VERSION_USE_CURRENT
Don't know why.
I think that's about it.
--Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden